Self-Hosting Vaultwarden — It Fits Easily, and You Own the Backups
Vaultwarden — the lightweight Bitwarden-compatible server — is one of the better-fitting self-hosted tools you can put on a small container. Its README describes it as "perfect for self-hosted deployment where running the official resource-heavy service might not be ideal" (Vaultwarden), and it behaves exactly like the workload this platform is built for: one process, mostly idle, storing a small amount of data. The deployment is about ten minutes. The part that deserves your attention is everything after it — there are no volume snapshots here, every port binding is public, and this is the one application where losing your data is genuinely serious. If you aren't going to set up your own backups, don't self-host your password vault.
Why it fits a small container
A password vault is close to the ideal small workload. It stores kilobytes per user, does almost nothing between syncs, and serves one household or one small team. There is no traffic spike coming.
It's also a single process with a single data directory, which matches the deployment model exactly: one container, one volume, one HTTPS endpoint. Nothing to split, nothing to coordinate.
Deploying it
Use the Existing Image path — deploying a public image is the shortest route for a tool you aren't building yourself, and the create form lets you set the volume, port and environment variables up front rather than adding them afterwards and restarting.
Three things to get right:
Bind an HTTPS port, not TCP. This isn't a preference. The README is explicit: "The web-vault requires the use of HTTPS and a secure context for the Web Crypto API. That means it will only work if you enable HTTPS." An HTTPS binding gets a hostname and a valid certificate handled for you, and the edge terminates TLS and forwards plain HTTP to your container — which is also what Vaultwarden's own docs recommend over its built-in TLS. The container listens on port 80 by default, so that's the container port you point the binding at. How ports and URLs work covers the rest.
Mount /data as a volume. That's the directory Vaultwarden's own examples persist. Everything that matters lives there, and anything outside a volume is discarded when the container is recreated — which happens on every deploy and every configuration change.
Turn off open registration. Your app has a public URL from the moment it starts. Anyone who finds it can otherwise create an account on your server. The documented setting: "To disable this, set the SIGNUPS_ALLOWED env variable to false" (Vaultwarden wiki). Note the documented exception — "an existing user who is an organization owner or admin can still invite new users" — which is how you add the people you actually want.
Set it as an environment variable at creation time, before the URL exists.
The backup problem, which is the real work
Say this part plainly: nothing here snapshots your volumes. There is no restore button, no daily image, no support ticket that recovers a deleted volume. If the data goes, it's gone.
For most self-hosted tools that's an annoyance. For a password vault it's the difference between a hobby project and a liability, so plan it before you migrate anything in.
What actually protects you:
- Regular exports. Bitwarden clients can export your vault. Do it on a schedule you'll actually keep, and store the export somewhere else entirely — encrypted, because an export is your passwords in a file.
- Copy the data directory off the platform. You can download files through the panel's file browser without a shell, which is enough for an occasional manual copy. For anything regular, write a job that pushes a copy somewhere off-platform — the general approach to backing up volumes applies unchanged.
- Don't back up into the same volume. A dump written next to the database doubles your growth and counts toward the account disk limit, and a disk overrun stops every app in your account.
One genuine mitigation worth knowing: Bitwarden clients keep a local encrypted copy of your vault, so a server outage doesn't lock you out of the passwords already on your devices. That's a safety net for downtime. It is not a backup strategy, and relying on it means your recovery plan is "hope every device survives".
The admin page
Vaultwarden has an admin backend, and its documentation is unusually clear about the risk.
It's disabled by default, and enabled by setting a token: "To enable the admin page you need to configure an authentication token." The warning is direct — "Keep this token a secret. If you configure this as the ADMIN_TOKEN this will be used as the password to access the admin area of your server!" (Vaultwarden wiki).
Two things follow, both sharper on a platform where your URL is public by default:
Leave it disabled unless you're actively using it. To turn it off, the docs say to ensure neither the ADMIN_TOKEN variable nor an admin_token key in config.json exists. Enable it for the ten minutes you need it, then remove the variable. Changing an environment variable recreates the container, so this is a restart rather than a redeploy.
Hash the token. The docs recommend Argon2id PHC format over plain text specifically to prevent simple readout of the credential — which matters here, because environment variables are stored and shown as plain text in the panel.
The docs also note you should have HTTPS working before enabling the admin page, "to avoid possible MITM attacks". You will, because Vaultwarden won't work without it.
What it costs
Small. A vault server's disk footprint is measured in megabytes, and disk here is measured rather than allocated — you're billed for what the volume actually holds, so there's no size to over-provision.
CPU and RAM are allocations, so pick a modest preset and leave it. The workload is idle almost all the time; billing follows what you allocate, not what you use, which makes the monthly cost predictable to the cent.
Should you actually do this?
Worth being honest about, because "it fits" and "you should" are different claims.
Reasonable if you want your vault under your own control, you'll keep exports, and you're comfortable that an hour of downtime during a deploy is fine because your clients hold a local copy.
Not reasonable if backups are something you'll get to later. This is the single worst application to learn that lesson on, and a hosted password manager is a perfectly respectable choice.
Either way, a self-hosted vault does not need to be reachable by the whole internet — but there's no private option, so every binding is public. Your protection is a strong master password, registration turned off, and the admin page left disabled.
FAQ
Can I self-host Vaultwarden on JustRunMy.App?
Yes. Deploy the public image, bind an HTTPS port to container port 80, and mount /data as a volume.
Does it need HTTPS?
Yes, mandatory. The web vault requires a secure context for the Web Crypto API, so an HTTP-only setup will not work.
Where does the data live?
In the /data directory. Mount it as a volume, or everything is lost the next time the container is recreated.
Are my volumes backed up?
No. There are no snapshots and no restore. Exports and off-platform copies are entirely your responsibility.
How do I stop strangers registering?
Set SIGNUPS_ALLOWED=false. Organization owners and admins can still send invitations to the people you want.
Should I enable the admin page?
Only while you need it. It's off by default, the token is the password to your server's admin area, and the docs recommend storing it as an Argon2id hash rather than plain text.
Wrapping up
Vaultwarden is a rare case where the technical fit is obvious and the decision still isn't. The container is tiny, the deploy is three settings, and it will sit there costing very little for years. What you're taking on isn't operational load, it's responsibility: the data has no safety net but the one you build, and the URL is public from the first second. Get the export habit established in the first week — before you've migrated anything you'd miss — and the rest of this is genuinely easy.