How to Safely Migrate to a Self-Hosted Password Manager

If you have ever tried to export your passwords from LastPass or Google Chrome, opened the resulting file, and felt a cold flash of dread at seeing every credential you own sitting in plain text CSV, you already understand why password manager migration deserves more care than most people give it. That single file is a master key to your entire digital life, and it is exactly the moment when things go wrong.

Self-hosting is having a moment for good reasons. After the 2022 LastPass breach exposed encrypted vaults belonging to millions of users, and again after price hikes pushed many away from commercial suites, tools like Vaultwarden (a lightweight Bitwarden-compatible server) and KeePassXC saw a surge in adoption. The appeal is simple: your vault lives on infrastructure you control, not a target-rich cloud that attackers scan daily. But the migration itself is the vulnerable step. A sloppy transfer can leave decrypted copies scattered across three machines, a backup drive, and your email trash.

This guide walks through a complete self-hosted password manager migration the way I actually did it for my own 300-plus credential vault, including the numbers, the tradeoffs, and the mistakes I made so you can skip them. You will learn how to choose a target, prepare securely, transfer without leaking anything, and lock the whole thing down afterward.

Key Takeaways

Treat the export file as radioactive. A plaintext CSV of your vault should exist for minutes, never hours, and never on cloud sync.

Vaultwarden is the sweet spot for most people who want Bitwarden's polish with self-hosted control on cheap hardware.

Migrate on one clean, offline-capable machine rather than juggling exports across phones and laptops.

Verify the import count matches the export count before you delete anything from the old provider.

Enable 2FA and encrypted backups on day one, because self-hosting moves the security burden onto you.

Keep the old vault for 30 days as a fallback, then wipe it deliberately.

Why Migrate to a Self-Hosted Password Manager at All?

The honest answer is control and cost, not raw security. A well-run commercial service like Bitwarden or 1Password employs full-time security teams you cannot match at home. What self-hosting buys you is ownership: no subscription creep, no forced feature changes, no policy about who can subpoena your encrypted blobs, and no shared cloud that hackers probe around the clock.

There is also the failure-mode difference. When a major provider is breached, attackers walk away with millions of vaults in one haul. Your self-hosted instance on a $6 VPS or a Raspberry Pi at home is simply not worth an attacker's specialized effort unless they already know it exists.

That said, self-hosting is not for everyone. If you would never patch your server, rotate keys, or run backups, you are trading a professional's watch for your own neglect. Be honest about which type you are before you start. If you want a broader security posture first, our guide on browser password manager vs dedicated app is a useful sanity check.

Choosing Your Self-Hosted Password Manager

The three realistic options for most people are Vaultwarden, KeePassXC (with your own sync), and Passbolt. They solve different problems.

Tool	Best for	Sync model	Team support	Setup difficulty	Monthly cost
Vaultwarden	Individuals & small teams wanting Bitwarden apps	Self-hosted server, all official clients	Yes (orgs, sharing)	Low–Medium	$0–$6 (VPS)
KeePassXC	Purists who want offline files	Bring your own (Syncthing, Nextcloud)	Manual only	Low	$0
Passbolt	Developer & ops teams	Self-hosted server	Yes, granular	Medium–High	$0–$10 (VPS)
Bitwarden (official self-host)	Businesses needing support contracts	Self-hosted server	Yes	High (Docker heavy)	$0+ (resource cost)

For 90% of readers, I recommend Vaultwarden. It runs the full Bitwarden client ecosystem (browser extensions, mobile apps, desktop apps) against a tiny Rust server that happily lives inside a single Docker container using around 100 MB of RAM. That means you get polished autofill and passkey support without paying for enterprise infrastructure.

If you plan to sync across devices, spend a moment reading how to protect passkeys from malware that hijacks password managers, because the client is where most real-world attacks land.

Preparing for a Safe Migration

Most migration disasters happen because people export first and think later. Do the prep in order.

1. Pick one clean migration machine

Choose a single computer you trust. Ideally it is your own, fully patched, running current antivirus, and not shared. You will handle the plaintext export here and nowhere else. If you suspect anything odd, scan it first and read our advice on detecting silently installed browser extensions, since a rogue extension can quietly read a password export as you handle it.

2. Disable cloud sync on that machine's Downloads folder

This is the step almost everyone forgets. If your Downloads or Documents folder is synced to iCloud, OneDrive, Dropbox, or Google Drive, your plaintext export will upload to the cloud the instant it lands on disk. Pause syncing before you export.

3. Provision your server

Spin up your Vaultwarden instance before you touch the export. Whether that is a $6/month VPS or a home server, get it running, reachable over HTTPS, and confirm you can log in with a throwaway test account. Never expose a password server over plain HTTP.

4. Plan your backup strategy in advance

Self-hosting means the backup is your job now. Decide where encrypted backups will go before you have data worth losing. The 3-2-1 backup strategy that actually survives ransomware maps directly onto this: three copies, two media types, one offsite.

A Step-by-Step Migration Walkthrough (With Real Numbers)

Here is the exact process I use. To make it concrete, say you have 312 logins, 18 secure notes, 9 credit cards, and 4 identities spread across LastPass. That is 343 items total. Write that number down. It is your verification target.

Set up HTTPS on Vaultwarden. Put it behind Caddy or Nginx with a real certificate. If it says "not secure" in the browser, stop and fix it. Handling passwords over a self-signed or plain connection defeats the point.
Create your real admin account with a long, unique master passphrase (I use five random words plus a symbol, roughly 70 bits of entropy). Do not reuse your old master password.
Pause cloud sync on the migration machine, as covered above.
Export from the old provider. In LastPass this is Advanced Options → Export. You will get a .csv file. Open it once to confirm it decrypted, then close it immediately.
Import into Vaultwarden using the Bitwarden web vault: Tools → Import Data. Select the matching format ("LastPass (csv)"), upload, and confirm.
Verify the counts. Open your vault and compare. Expect 343 items. If you see 341, something failed silently, often malformed notes or attachments. Investigate before proceeding.
Fix attachments manually. CSV exports drop file attachments. Re-upload any documents, recovery codes, or images by hand. In my last migration this was 6 files.
Shred the export file. Do not just drag it to trash. Use a secure delete: on Windows cipher /w:C:\path after deletion, on macOS/Linux shred -u file.csv or overwrite the free space. Empty the trash.
Re-enable cloud sync only after the plaintext file is gone and the trash is emptied.
Install clients everywhere. Point the Bitwarden browser extension and mobile app at your server URL, log in, and test autofill on 3–5 real sites.

Total hands-on time for 343 items: about 40 minutes, plus 15 minutes verifying attachments. The plaintext file existed on disk for under four minutes.

Locking Down Your New Instance

Migration is only half the job. Now you own the security perimeter, so treat the server like the crown jewels it is.

Enable two-factor authentication on your vault login immediately. A TOTP app or hardware key is fine. This is the single highest-value step.
Turn off open signups. In Vaultwarden set SIGNUPS_ALLOWED=false once your accounts exist, so nobody can register on your server.
Restrict the admin panel with an ADMIN_TOKEN and ideally an IP allowlist or VPN-only access.
Automate encrypted backups. Back up the data/ directory nightly to encrypted offsite storage. Test a restore at least once, because an untested backup is a rumor.
Keep the container updated. Subscribe to the project's release notes and patch within a week of security fixes.
Add server-level protection. If your instance shares a box with a web stack, tools like SiteGuard Pro and a firewall layer such as our WordPress IP Blocker Pro help fend off automated scanners probing your host.