SealKeep lets you build custom data apps - contacts, password managers, patient forms, anything - where your data is locked in your browser before it ever reaches the server. No code required.
Most apps store your data on a server where people with server access could read it. SealKeep works differently: your app locks your records on your device before sending them. The server stores locked data, not plain records.
If someone steals a copy of the database, they should only see locked data. They still would not have your records in plain text.
Your data is locked in your app before upload. Each record is locked separately.
Your sign-in setup is designed to make password guessing much harder for attackers.
Get 10 one-time backup codes at setup. Each one independently unlocks your data if you forget your password.
In web mode, protection depends on the app code delivered to your browser and your own device security.
From creating an account to managing encrypted records - here's everything you need.
Register with an email address and a password. Your records are unlocked on your device. The server does not store your password in plain text.
After registering, you're taken straight to the recovery code setup - it's required before you can do anything else.
Enter your email and a strong password (8+ characters)
SealKeep generates 10 one-time backup codes and shows them on screen. Each code can help you recover access if you lose your password. Store them like you'd store a spare house key: somewhere safe and offline.
If you forget your password and lose all your recovery codes, your data is gone forever. There's no "forgot password" email that can recover encrypted data.
10 one-time recovery codes - write these down and keep them safe
The App Builder lets you create any kind of data tracker - a password manager, a contact list, a patient intake form, an invoice log - by clicking, not coding. Add fields, choose types, set layouts, and hit Save.
Every time you open the Builder, you unlock it with your password. This ensures your key is only in memory when you're actively using it.
Builder - fields defined for a Password Manager app
Open your app, enter a record, and click Save. Everything you type is scrambled in the browser before it's sent. When you open the app next time, your records are fetched as scrambled data and unscrambled locally for display.
Edit, delete, tag, and search your records. You can also add rich-text notes with formatting - bold, italics, lists, and tables.
Both entries visible - all data decrypted locally for display
You can invite another SealKeep user to access one of your apps - they'll be able to read and add records without ever knowing your password. Access can be revoked at any time with a single click.
How it works: When you invite someone, SealKeep creates a digital envelope addressed specifically to their account. Only they can open it with their own password - you never share credentials. When you revoke access, the envelope is destroyed and the app's encryption key is rotated automatically.
To remove someone's access, click Revoke next to their name. Their access ends immediately and the app's key is rotated so old data remains secure.
Shared Access panel - invite collaborators with a private invite flow
SealKeep has a powerful search system that works without exposing your private data. Search by text, by specific fields, by tags, or by date - or combine them all at once.
Type a term in the search bar and SealKeep searches your unlocked records in your app. The server returns locked records for your account.
Full-text search - searches all decrypted field values
Select a field from the dropdown to narrow results. Fields marked as "searchable" use a private fingerprint so the server can match records without seeing the real value.
If you mark a field as Searchable in the Builder, a private fingerprint of that value is stored next to the locked record. This allows fast exact-match lookups without storing the plain value.
Field search - matched via fingerprint, no plaintext sent to server
Tag your records with labels like "Prospect", "Active", or "Archived". Tags are stored as private fingerprints on the server, so filtering works without storing plain labels.
Use the date picker to show records created today, this week, or within any custom date range. Combine tags, field filters, and date filters in any combination.
Date range filter - narrow records to a specific period
Two-factor authentication (2FA) means that even if someone steals your password, they still can't log in - they'd also need your phone. SealKeep supports standard authenticator apps like Google Authenticator, Authy, and 1Password.
If you lose your authenticator app, use a backup code to regain access. You can also reset your password via the Forgot Password link on the login page, which lets you set a new password and re-enter with a backup code.
Scan this QR code with any authenticator app
Login prompts for a 6-digit code after password
Lost your phone? Use one of the backup codes to get in
SealKeep lets you download a backup of your app data at any time. Record contents in that backup stay in locked form. If something goes wrong, restore from backup and continue where you left off.
Every field type stores its value as locked data. Pick the type that matches what you're collecting - the app handles the rest.
Short text - names, titles, single-line values
Email address - format is checked automatically
Phone number
Numeric - quantities, prices, ages
Date picker - calendar pop-up
Dropdown - one choice from a list you define
Radio buttons - all choices visible at once
Multi-select checkboxes - pick several options
Rich text editor - bold, italic, lists, tables
Label chips - type to add, click to remove
File upload - file bytes are encrypted inside the record
Invoice rows - description, qty, price, tax, total
Each field can be sized independently: Full (entire row), Half, One-third, or Two-thirds. On mobile, all fields automatically expand to full width so nothing gets squished.
Fields can be hidden in the list view, the form, or both. Use this to keep internal notes or sensitive values out of sight without removing them from the record.
SealKeep uses several layers of protection. Here's what each one does and why it matters.
When you unlock, your records are opened in your app memory on your device. The server stores locked records.
Good password handling and login protections make account guessing attacks harder.
Before a record is sent to the server, your app locks it. Each record is locked separately so plain content is not stored on the server.
If locked data is changed in transit or storage, record opening can fail instead of silently showing bad data.
Each recovery code can restore access if you lose your password. Using a code removes it from the list so it cannot be reused.
Codes are shown once. Save them offline.
When you invite a collaborator, SealKeep grants access without sharing your password. They sign in with their own account.
Revoking access removes their access and refreshes app access state for safety.
Tag labels are represented by private fingerprints on the server so filtering can work without storing plain tag text.
This lets you filter by tag while keeping labels private in normal use.
Optional TOTP (time-based one-time password) support means even a stolen password can't be used to log in alone. The 6-digit code changes every 30 seconds and is generated by an app on your phone.
Backup codes let you regain access if you lose your authenticator. Password reset works without breaking any of your encrypted data.
The login endpoint limits repeated failed attempts and temporarily blocks abusive traffic. This helps slow down automated password-guessing attacks.
Authentication uses HttpOnly session cookies, which means JavaScript on
the page cannot read the session token. This protects against a common attack called
cross-site scripting (XSS).
CSRF tokens protect all state-changing requests (POST, PUT, DELETE) from being triggered by malicious third-party websites.
Here's every piece of data stored in the database and whether anyone with a copy of that database could read your information.
| What's stored | What it is | Readable without your key? |
|---|---|---|
users.password_hash |
A protected form of your sign-in secret | Not plain password |
users.encryption_salt |
A helper value used for account unlocking | Visible - not harmful alone |
users.recovery_blobs_json |
Encrypted copies of your data key, one per recovery code | 🔒 Encrypted |
records.payload |
Your actual record content in locked form | 🔒 Encrypted |
records.meta_json |
Internal record metadata (e.g. migration state) | 🔒 Encrypted payload only |
app_schemas.fields & app_schemas.title |
Your app's field definitions and title | 🔒 Encrypted |
user_tags.tag_hmac |
Private fingerprint of each tag label | 🔒 Not reversible |
user_tags.tag_enc |
Encrypted tag label text | 🔒 Encrypted |
app_key_grants.* |
Shared access grant data for collaborators | 🔒 Encrypted per-recipient |
users.public_key |
Collaborator's public key (used for sharing) | Public - intentionally visible |
users.encrypted_private_key |
Collaborator's private key, encrypted with their password | 🔒 Encrypted |
users.totp_secret |
Two-factor authentication secret data for account login checks | 🔒 Encrypted |
| Activity metadata | Timing, counts, and usage patterns needed to run the service | Visible to server |
Hosted web mode still requires trusting the app code delivered to your browser. For stronger assurance, use standalone mode and verified releases.
Design a form in the Builder, then compile it into a single file that users run on their own computer. No cloud account and no cloud server required. The developer never sees user data - not even with a copy of the database file.
One-click build from the Builder - choose your platform
Linux, macOS (Intel + Apple Silicon), Windows - all from a single build command.
Schema, UI, and server all in one binary. Only data.sqlite is created at runtime.
The developer can't read user records from a database copy alone because records are stored in locked form.
Ship a new binary with an updated schema. Existing records open fine - the key doesn't change.
Clone, run, register, and start building your first encrypted app.