I self-host Vaultwarden for password management and NetBird for private remote access. I prefer a hybrid approach. Running those services myself does not mean I want to run every service myself.
Self-hosting gives me control over how an application is deployed, who can reach it, and how it fits into the rest of my environment. That control matters. So do privacy, flexibility, and avoiding a subscription model that doesn’t fit my needs.
The easier-to-overlook part comes afterward. When something breaks, I am the last stop. Updates, certificates, backups, access problems, and recovery still need an owner. Choosing self-hosting means accepting that work, even when the software is free.
When choosing between self-hosting and software as a service, consider both sides: the control you gain and the operating responsibility you can sustain.
Self-hosted vs SaaS: which should you choose?
Self-host when control over deployment, data handling, or configuration is worth the maintenance and recovery work you can reliably own. Choose SaaS when the provider’s service, controls, and support fit your requirements better than operating the application yourself. A hybrid approach lets you decide service by service rather than forcing every workload into the same model.
By hybrid, I mean a deliberate mix of self-managed applications and provider-operated services. That does not necessarily mean formal hybrid-cloud architecture.
Start with who operates the application
A server’s location does not tell you who is responsible for the software running on it.
My NetBird control plane runs on a rented VPS outside my home environment. I buy infrastructure but still operate the NetBird application. It is self-hosted on someone else’s infrastructure, not a provider-operated NetBird service.
Microsoft’s shared-responsibility guidance distinguishes infrastructure as a service, platform as a service, and SaaS, with different divisions of operating responsibility.[1] Customers remain responsible for data, identities, and configuration.[1]
I would use the following table as a starting point for a conversation, then verify the actual service agreement.
Managed hosting can sit between these arrangements. The label alone does not show whether someone else patches the application, restores its database, or just keeps the virtual machine running.
Privacy and security need more than a hosting label
I value keeping sensitive services under my control. Self-hosting lets me make deployment and access decisions directly instead of accepting every choice built into a hosted plan.
That is a useful capability, not an automatic security guarantee.
I still need to consider how the application encrypts information, who can administer it, which interfaces are exposed, how quickly vulnerabilities are addressed, and what happens if an endpoint is compromised. A private service with neglected updates can be a poor security decision. A SaaS account with excessive permissions can be one too.
I also distinguish data location from data access. Running an application on a rented server does not remove the infrastructure provider from the trust model. Backups, logs, integrations, and client devices deserve attention alongside the main application.
I prefer to choose the controls I need and make sure someone can operate them. “Self-hosted” and “cloud-hosted” are not substitutes for that assessment. Warden: control comes with a recovery obligation
Password management makes the trade-off concrete. I use Vaultwarden, an unofficial Bitwarden-compatible server implementation that is separate from the official Bitwarden project and its hosted service.[2]
The appeal is control over deployment. The responsibility is to keep an important service usable and recoverable.
For a password manager, I look beyond whether the container starts. I want to know whether the backup contains the required state, whether the restore procedure works, and how essential recovery information can be reached if the normal access path is unavailable.
Vaultwarden’s backup guidance illustrates why application knowledge matters. In its common SQLite configuration, most important state is in the database, but file attachments are stored separately.[3] The guide also addresses configuration and signing keys, consistent database backups, and periodic restore checks.[3]
Backing up the wrong scope can leave a service partly recoverable. Making another copy without protecting it properly can create a different security problem.
Another dependency is worth challenging: the instructions or credentials needed to recover a system should not be reachable only through the failed system. I plan a securely protected recovery path that does not require the normal vault service to be working first.
That is a design requirement, not a reason everyone should abandon self-hosted password management. It is also a fair reason for someone to choose a managed password service. The decision depends on the operating commitment they can make.
NetBird: a different cost model, not an escape from maintenance
I chose self-hosted NetBird for my primary private-access approach. User requirements and recurring per-user costs factored into that decision. Tailscale remains a credible managed option; choosing another for my environment is not a verdict against the product.
On October 24, 2026, Tailscale’s pricing page listed up to six users on its Personal plan, with paid plans using per-user pricing.[5] Plan eligibility, features, and the actual number of people needing access belong in the comparison.
A self-hosted alternative changes that comparison, but the infrastructure and operating effort do not disappear. NetBird’s quickstart requires a server, domain configuration, and supporting software.[4] Its cloud-versus-self-hosted guidance explicitly assigns installation, maintenance, data protection, and security work to the self-hosted operator.[8]
In my design, the control plane sits outside the local compute environment. Local routing peers provide the path into private services. That separates some responsibilities and failure boundaries. It does not make the home network reachable if the local path is unavailable.
I still must maintain the server and application, manage users and policies, check certificate renewal, and validate access after changes. NetBird’s backup guide treats both deployment configuration and persistent management state as recovery requirements.[6]
I would compare the hosted subscription against that complete arrangement, not against a zero-dollar software download. I would also check the edition: NetBird distinguishes its open-source core from commercial self-hosted features, including active-active management and signal high availability.[7]
I want the comparison to explain which responsibilities and costs change, rather than stopping at the subscription I might avoid.
Redundancy must address a specific failure
Redundancy is important, especially for the services used to reach or recover other services. It also needs a precise claim.
In a controlled test of my NetBird routing design, I stopped the primary routing service and confirmed private services remained reachable through the standby routing peer. That demonstrated an alternate routing path for the condition tested.
It did not prove control-plane failover, recovery from a lost VPS, or continued access through a home internet or power outage. Those are different failures with different dependencies.
I would apply the same scrutiny to any service. Two application instances may still depend on one database. Two local machines may share one power source. Two access methods may depend on the same identity provider. A second copy helps only if it addresses the failure you need to survive. It answers another question: how to recover state after it is lost or damaged. They do not automatically provide uninterrupted service. Replication can preserve availability while also carrying an unwanted change to another copy.
Human dependency matters, too. If I am the only person who understands the system, a second server does not create a second operator. Documentation, a usable recovery procedure, and appropriate support coverage must be part of the decision.
For the foundations behind this approach, see Practical Home-Lab Automation: Start Small and Build for Reliability.
A hybrid approach makes room for services worth paying for
I do not need every service to follow the same hosting model to maintain a coherent environment.
Hosted email, public DNS, or an independent notification service can be sensible choices when the provider’s capabilities fit the requirement, and I don’t want to own that operating burden. These are examples to evaluate, not a rule that those services must always be SaaS.
The same reasoning applies to a business team. It may want direct control over one application while paying for managed collaboration elsewhere. A workload with unusual integration or data-handling requirements may justify self-management. Another may be better served by a provider with an operating team and support commitments the organization cannot replicate internally.
SaaS still requires diligence. I check administrative controls, recovery options, export formats, support response, and the consequences of a service or account becoming unavailable. A subscription doesn’t prove every requirement has been met.
I also examine the connections between the two sides. A self-hosted application might depend on hosted email for recovery messages. A SaaS application might depend on an identity service I operate. Those relationships can be useful, but they should not be surprises during an outage.
The approach is like the one in Before You Add AI, Decide What Actually Needs to Change: understand the requirement before treating a particular technology as the answer.
Compare the cost of operating the service
A subscription bill is visible. Time spent investigating failed updates is easier to omit.
For self-hosting, I include infrastructure, backup storage, any paid licenses or support, routine maintenance, and the recovery effort the service requires. Shared hardware isn’t free just because I already own it, but I shouldn’t charge every application its full cost either.
For SaaS, I include the plan needed, user growth, required integrations, administration, any additional protection, and the work of moving away later. Comparing a fully protected self-hosted service with a SaaS plan that lacks required features is misleading. So is comparing an unsupported self-hosted installation with a subscription that includes support. Learning also has value. Time spent experimenting may be time I deliberately want to spend. That does not mean I can promise the same attention to a service others rely on. I distinguish the hobby’s value from the obligation to operate the service.
Write one decision card for each important service
Before committing, I answer these questions about the actual workload.
If the required capability is missing, a low price does not fix it. If nobody can maintain the service, controlling its configuration doesn’t close that gap.
Choose the responsibility you can sustain
I prefer a hybrid approach because different services require different commitments.
Vaultwarden and NetBird are examples of work I have chosen to own. That makes updates, access, protection, and recovery part of the decision, not chores to consider after installation.
For another service, paying a provider may be the more useful choice. I want to explain that choice in terms of the requirement, the responsibility transferred, and the responsibility that remains mine.
The goal is an environment where I can operate, not the highest possible count of applications I host myself.
Sources
[1] Microsoft Learn — Shared responsibility in the cloud
https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility
[2] Vaultwarden — Vaultwarden project repository
https://github.com/dani-garcia/vaultwarden
[3] Vaultwarden Wiki — Backing up your vault
https://github.com/dani-garcia/vaultwarden/wiki/Backing-up-your-vault
[4] NetBird Docs — Self-Hosting Quickstart Guide (5 min)
https://docs.netbird.io/selfhosted/selfhosted-quickstart
[5] Tailscale — Tailscale pricing
https://tailscale.com/pricing
[6] NetBird Docs — Back Up and Restore Your Self-Hosted NetBird Installation
https://docs.netbird.io/selfhosted/maintenance/backup
[7] NetBird Docs — NetBird Enterprise Commercial License
https://docs.netbird.io/selfhosted/enterprise
[8] NetBird Docs — Self-hosted vs. Cloud-hosted NetBird
https://docs.netbird.io/about-netbird/self-hosted-vs-cloud
Related reading
More articles are taking shape.