When I started working on OmniProfile, my primary goal was to sharpen my development skills and dive deep into client-side cryptography, containerized deployments, and modern web architecture. I wanted to see if I could build a full-featured "link-in-bio" platform—similar to Linktree—without making the usual industry compromise: collecting and storing users' unencrypted personal data on a central database.

To turn this concept into a functional product, I built out a dual-environment setup with a dedicated testing environment and a production server. Here is an inside look at the technical architecture behind OmniProfile and how it delivers complete end-to-end privacy without sacrificing design flexibility.

The Philosophy: Zero-Knowledge & True E2EE

Most profile platforms store your links, social handles, and contact details in plain text on their servers. OmniProfile flips this model on its head. The core design principle is simple: the server should act purely as a dumb storage locker.

To achieve this, all cryptography happens entirely on the user's local device:

  • Client-Side Key Derivation: Master encryption keys are derived directly on the device using PBKDF2.

  • AES-GCM Encryption: Data is encrypted inside the browser via the native Web Crypto API before it ever crosses the network. The backend only ever receives encrypted blobs.

  • Hierarchical Encrypted Keychain: Each user has a master keychain that securely stores references and unique symmetric keys for their individual cards, ensuring compartmentalized security across all profiles.

The Decryption Trick: Secure Public Sharing via Hash Fragments

One of the most interesting challenges during development was figuring out how to let visitors view a public card without revealing the decryption key to the server.

The solution lies in how web browsers handle URL fragments. When a user shares a profile, OmniProfile generates a URL formatted like this:

omniprofile.me/c/<slug>#k=<key>

Under standard web specifications, browsers never send the #hash portion of a URL to the host server. When someone clicks the link:

  1. The host server receives a request for <slug> and returns only the raw, encrypted payload.

  2. The visitor's browser grabs #k=<key> directly from the address bar.

  3. The page decrypts locally in the visitor's browser in real time.

Users can also assign custom vanity slugs to keep their links clean and branded while keeping the server completely in the dark.

Client-Side Media Handling: Zero-Footprint Avatars

In a zero-knowledge system, hosting raw, unencrypted image files on a server breaks the entire security model. To handle profile pictures and custom backgrounds securely, I shifted image processing completely to the client side.

  • Browser Cropping: When a user uploads an image, Cropper.js crops and compresses it directly in the browser.

  • Base64 Conversion: The compressed image is converted into a Base64 string.

  • Payload Injection: That string is injected directly into the card's JSON object before the entire payload is encrypted and saved to the database.

By bundling media directly into the encrypted payload, no raw image assets ever touch the server disk.

Granular Design Customization

Privacy tools often suffer from clunky user interfaces, so I made sure OmniProfile matched the visual polish expected from modern design software.

  • Global vs. Granular Styling: Users can set a universal theme across an entire card or override individual buttons, links, and accents.

  • Typography & Visual Effects: Features full support for Google Fonts, variable button shapes (pill, rounded, sharp), and CSS text effects like neon glows, drop shadows, and hard outlines.

  • Dynamic Backgrounds: Profiles support solid color palettes, transparent themes, or custom background media.

The Infrastructure & Tech Stack Choices

To build and scale the application properly, I established a clear split between my development testing environment and the live production host.

The Stack

  • Frontend: Built with vanilla JavaScript—no heavy front-end frameworks—keeping the bundle size negligible and client-side decryption instantaneous.

  • Backend: A high-performance Python FastAPI service paired with a PostgreSQL database for storing encrypted state.

  • Authentication: TOTP-based Multi-Factor Authentication (MFA), with secrets encrypted at rest on the server.

  • Networking & Deployment: Both the test and production environments run inside isolated Docker containers. The production server routes traffic through Cloudflare Tunnels, which completely eliminates the need to expose open incoming ports on the host hardware.

Tier Management & Cryptographic Vouchers

To handle feature gating without tracking invasive user metrics, OmniProfile uses a native tier system:

  • Free vs. Pro Slots: Establishes boundaries—such as limits on maximum social links or custom styling elements—on free tier cards.

  • Voucher System: An administrative redemption system allows for instantaneous "Pro" upgrades via cryptographic vouchers, avoiding the need to track user identities across payment gateways.

Key Takeaways

Building OmniProfile across dedicated testing and production environments was a fantastic way to sharpen my engineering skills. It proved that you don't need to sacrifice modern UX, vanity links, or deep visual customization to provide true, uncompromising end-to-end privacy.