Self-Hosted Apps
Self-Hosting Trades a Subscription for a Responsibility.
Running Vaultwarden and a few Docker apps on your own server is very doable. It works out when someone actually owns the updates, the accounts, and the restore plan.
Control pays off when someone does the upkeep. It does not make maintenance disappear, and it does not make your passwords safer by itself.
The Honest Test
Be Honest About Who Maintains This
Self-hosting works when the project has real docs, you have decided who can sign in, and you know which data would hurt to lose. A password manager holding your credentials is not a weekend experiment you abandon.
The Project Has Real Docs
There is a maintained Linux or container install you can follow, and a changelog worth reading before each upgrade.
You Will Actually Maintain It
Updates, failed jobs, disk alerts. Someone has to notice, and for a password manager that someone had better be reliable.
You Know Who Signs In
Registration stays closed unless you truly want public accounts, and admin access is a short, deliberate list.
Public or Private
Map the Front Door, the Jobs, and the Data
Even a small app has an entry point, background work, and data that must survive. Make each one explicit before you choose a plan.
- 01
The Front Door
Expose only the HTTPS endpoint each app needs. Vaultwarden's login page is public by design; the admin panel does not have to be.
- 02
The Quiet Background Work
Sync jobs, OCR queues, scheduled imports. They fail silently unless something logs them where you look.
- 03
The Data That Must Survive
Databases, uploads, and encryption keys are the app. Know where they live and back them up together, at a point the app considers consistent.
What You Get
Install Each App the Way Its Docs Intend
Follow each project's own install docs instead of bending it around a hosting panel. Those docs remain the authority on how the app handles security and data; we supply the server underneath.
- Install it the way the project intendsFull root access
- Docker Compose, a system package, a bare binary. Whatever the docs recommend works, because nothing on our side is in the way.
- Size for your actual mixPremium, Ultra, Max plans with current vCPU, RAM, NVMe, and monthly transfer limits
- A bookmark manager idles; Paperless-ngx chews CPU during OCR runs. Add up your real apps rather than sizing for a category.
- Layer our backups under yoursDaily backups
- Daily provider backups are a safety net. Only an app-aware backup proves the database, files, and keys restore together.
Users and Upstreams
Put the Server Near the People Who Sign In
Your daily login and sync matter more than the map does. So does the outbound side: feeds, mail delivery, and package registries can route differently from Tokyo and Singapore.
Current mainland-China paths: China Telecom: CTGNet (formerly China Telecom CN2 GIA, AS23764 / AS4809); China Unicom: CUP (China Unicom Premium, AS9929 / AS10099); China Mobile: CMIN2 (China Mobile International N2, AS58807).
- 01Test both locations from wherever you and your users actually sign in each day.
- 02Check the outbound side too. RSS feeds, mail delivery, and container registries each take their own path.
- 03Then do a real login and a real sync. A Looking Glass cannot see application or database delay.
Looking Glass output is a snapshot of the path at the moment you ran the test; day-to-day latency and app performance can differ. Read the network and locations pages for route terminology and facility context.
Sizing It
Add Up What Your Apps Actually Do
Vaultwarden barely registers on a CPU chart. Paperless-ngx running OCR over a scan backlog is another story. Size for the heaviest thing you run, plus the upgrade you have not done yet.
The Jobs You Forget About
Indexing, OCR, scheduled imports. Watch a full cycle of them, because that is when the CPU bill comes due.
Data Accumulates
Uploads, attachments, and container images grow quietly. So do the old images you never pruned.
Room to Upgrade
Leave NVMe space for image pulls, migrations, and a rollback copy. Upgrades fail hardest on a full disk.
Premium
- 2 vCPU (AMD Ryzen 9950X)
- 4 GB RAM
- 40 GB NVMe
- 1 TB/mo transfer
Ultra
- 2 vCPU (AMD Ryzen 9950X)
- 8 GB RAM
- 80 GB NVMe
- 2 TB/mo transfer
Max
- 4 vCPU (AMD Ryzen 9950X)
- 16 GB RAM
- 160 GB NVMe
- 4 TB/mo transfer
Privacy and Upkeep
Control Does Not Equal Privacy
Your data is only as safe as the app, its configuration, and every copy of it. Owning the server changes where those risks live; it does not remove them.
Riven Cloud supplies an unmanaged Linux KVM VPS with full root access. Everything inside it, from the firewall to the backups, is yours to operate.
- Read the project's security notes and release history before you trust it with anything sensitive.
- A weak admin password or an exposed backup can leak everything even though you control the server. Most self-hosting incidents come down to configuration, not hosting.
Further reading
Worked Examples to Start From
Questions
Self-Hosted Apps FAQ
Does self-hosting make an application private?+
No, and this matters most for password managers. Privacy still depends on the app itself, its configuration, encryption choices, and every backup copy. Read the project's security docs; owning the server only moves the risk to your side.
Is application installation or maintenance included?+
No. The plan is unmanaged, so the host, the apps, updates, and backups are yours to run. If you would rather we install software or maintain the system, that service is $100 per hour.
Where can I find deployment examples?+
Start with the self-hosted app guide, then the per-app tutorials. Each covers setup, security, and a tested restore rather than stopping at docker compose up.
Still Want to Run It Yourself?
Then add up what your apps really need: background jobs, memory, the data that must survive, and space to upgrade. Compare that with the current plans.