Run the sync server yourself.
The sync server stores sealed boxes, keeps a counter for each vault and checks a signature before it accepts a change. It never holds a key and never sees a name, so running your own copy costs very little.
Pick where it runs and where the objects live. The page writes the configuration, and you paste it where it belongs.
Three places it can live.
The same code serves all three. A Cloudflare Worker asks nothing of you but an account; a binary or a container asks for a machine you already have. Whichever you pick, the vault keys stay on your devices.
Cloudflare Worker
The free plan carries a small server. The index is a D1 database and the objects go to an S3-compatible bucket, so there is nothing to keep running and nothing to pay for a private vault.
A native binary
One process on Linux, macOS or Windows. It serves plain HTTP and expects a proxy in front of it for HTTPS. Boxes are sealed and signed either way, so plain HTTP is not a weakness here.
A container
The same binary with the same settings, passed as environment variables. Use it when the machine already runs containers and you would rather not build from source.
No server at all
Sync is optional. A vault can stay on one device with a local backup and never touch a network. Add a server later without changing anything inside the vault.
Answer four questions, copy the result.
Settings have one shape everywhere: a TOML field, or the same field as an environment variable. The Worker accepts S3 buckets only; a binary and a container also write to plain directories and to a Git repository.
Download and unpack the self-host ZIP. No Rust compiler is needed.
GitHub Releases · self-host ZIP
Configuration updated.
Create the database and bucket before deploying. Replace every placeholder.
Create the storage directories and replace every placeholder before starting.
Copy failed. Select the text and copy it manually.
Copy failed. Select the text and copy it manually.
Secrets stay in Worker secrets, never in the file. The Worker writes to S3-compatible storage only.
The binary serves plain HTTP. Put a proxy in front of it when the machine is reachable from the internet.
The container listens on every interface inside itself, so the published port reaches it.
Pick at least one place for the sealed boxes. The server refuses to start without one.
Values in angle brackets are yours to fill in. Nothing you type here leaves the page: the text is assembled in your browser.
Point your vaults at it.
A new vault uses sync.confidex.me. Changing the address is one setting in the app, and the vault keeps working: the address is not part of the vault and not part of its identity.
- In the app
- Open the vault settings and replace the sync server address with your own. The client adds the API path itself.
- Shared origin
- The app and the API can live on one domain. Route the API prefix to the server and everything else to the app.
- Accounts
- None to create. A vault registers itself by uploading its signed lock, and only the holder of the signing key can replace it.
- Several servers
- One vault speaks to one server at a time. Moving to another one is the same single setting.
What a server owner has to do.
Very little, and none of it involves secrets. The server holds sealed boxes and an index that points at them. A backup is a copy of both.
Backups
Copy the index and the object storage together. Objects are immutable and named by their digest, so a copy made while the server runs stays valid.
Upgrades
Replace the binary or deploy the Worker again. The index schema is applied at startup for a native index and with a schema file for D1.
Access
Storage credentials authorize the server against its own storage. They have nothing to do with vault keys and cannot open a single box.
The license
The server is under the GNU AGPL-3.0. Changes you run for other people stay open; a copy you run for yourself carries no obligation.