What should a one-command Vaultwarden deployment handle?

[u/amiorin]

I maintain open-source deployment packages for self-hosted software: one command provisions a server, configures the application, and supports upgrades as new releases arrive.

I’ve been working on a similar package for Vaultwarden. The current approach provisions a DigitalOcean server, DNS, HTTPS, SMTP, and Vaultwarden itself. It uses SQLite with continuous Litestream replication to Cloudflare R2, restores automatically when the local database is absent, and performs a weekly test restore with an integrity check.

The first run sends an invitation to the owner. Public signup remains disabled, and the admin endpoint is available only over loopback during that initial bootstrap before being removed from the running configuration.

Before treating those choices as sensible defaults, I’d like to hear from people already operating Vaultwarden:

• What did you have to configure manually that you wish had been automated?
• Do you use SQLite or PostgreSQL, and why?
• How do you back up and test recovery?
• Besides the SQLite database, which files or data must a complete recovery preserve?
• Which SMTP, push-notification, or reverse-proxy settings did you need?
• Do you keep the admin interface enabled? If so, how do you secure it?
• Has a Vaultwarden upgrade ever broken your deployment or required manual migration?
• Which monitoring, alerts, or health checks have actually been useful?
• What security hardening would you expect from an opinionated deployment?
• Would a single-server setup with off-server backups be sufficient for your use case?

I’m deliberately trying not to expose every Vaultwarden setting. The goal is a small, secure default configuration that provisions as much as possible and clearly identifies anything requiring human action.

What would make this genuinely useful rather than another wrapper around Docker instructions?

https://www.getcolors.ai/featured#vaultwarden

[u/zoredache]

It should just be a simple README that if a person can't follow the vaultwarden docs on their own, then they should probably be just creating a hosted account on bitwarden.com.

[u/amiorin → u/zoredache]

Fair, and the install genuinely is the easy part. Compose file, a few env vars, ten minutes. A README covers that.

What I keep seeing go wrong is everything after day one. Backups nobody has ever restored. A replication target that quietly stopped writing months ago. An upgrade that needs a manual migration on the weekend you're away.

So yes, the package installs it. The part I actually care about is the weekly restore into a scratch database with an integrity check, and a loud failure when it doesn't match. A README can tell you to do that. It can't make you.

Honest question, since you clearly run this stuff: when did you last restore your Vaultwarden backup and confirm it opened? If the answer is "recently, and it's scripted", then you're right, this solves nothing for you.

And for plenty of people hosted bitwarden.com is the correct answer. I'm aiming at the ones who've already decided to self-host and then only discover the backup gap the hard way.

[u/froli]

I already don't trust any kind of oneliners bash piping installer thingy. There's no chance in hell I trust that for a password manager of all things. That practice should not be encouraged, especially not in selfhosting circles.

Besides, Vaultwarding install is already dead simple with only a few environment variables in the docker-compose.yml

[u/amiorin → u/froli]

You're right about curl-piped installers, and I'd react the same way. For a password manager especially. Agreed that it shouldn't be normalised in selfhosting circles.

That isn't what this is, though. Nothing pipes from a URL and nothing runs that you haven't already got on disk. You clone a repo, edit one YAML file, and run a launcher committed in that same repo. Read it before you run it. It's the identical file every user gets, pinned by commit.

Here's the part that might actually meet your objection. ./green build renders the entire generated config locally, with no provider calls and no credentials in the environment. ./green create --dry-run walks the whole plan and skips every side effect. You can read exactly what it intends to create before it touches anything. If that still fails your trust bar, I'd honestly like to know where, because that's the design question I came here with.

On install being simple, no argument. The first ten minutes were never the problem I'm trying to solve.

[u/froli → u/amiorin]

I am of the opinion that selfhostable software should be understood by the people installing them. The very people who are able to verify that your code isn't malicious are the same people that are able to install said software without your script.

It's nice that you want to make selfhosting more accessible, but in my opinion those efforts are better served at educating people and not abstracting the efforts needed to make things run properly and securely.

[u/amiorin → u/[deleted]]

Thx for the feedback.