There is a real movement underway to pull your digital life off other people’s servers. Self-hosting, running your own photo storage, your own password manager, your own VPN, your own comms, has gone from a hobbyist’s weekend project to something privacy people now describe as basic hygiene, right alongside a password manager and encrypted messaging. The tools got good enough that a Raspberry Pi in a closet can quietly replace a stack of monthly subscriptions.

The reason is not just cost. It is trust, and the numbers are ugly. In 2025, 83 percent of companies reported a cloud data breach. The average breach cost $4.4 million, and attackers were exfiltrating data in as little as nine minutes. A single campaign against one connected service swept up more than 700 organizations through stolen access tokens. As one incident responder put it, every “Connect with Google” button is a trust decision you probably never actually evaluated.

So the instinct to take control is sound. But the conclusion a lot of people jump to, self-host everything, is a trap of its own. Self-host badly and you are not more secure; you are less secure, running unpatched software you do not have time to maintain, having become the single point of failure yourself. The real question was never “cloud or self-hosted.” It is “what belongs where.” Here is how to actually decide, service by service.

First, the reframe: what does “hosted” even require you to trust?

This is the question almost everyone skips, and it changes everything. “Hosted” is not one thing. The amount of trust a hosted service demands ranges from “basically none” to “your entire life,” and lumping them together is why people make bad calls in both directions.

Some hosted services are architected so the host cannot betray you even if it wanted to. End-to-end encrypted content the provider cannot read. A no-logs design with nothing to hand over. A no-identifiers architecture that cannot build a profile because it never learns who you are. Signal, Mullvad, and the messenger we ship, SimpleX, live here. When a hosted service is built so that a breach, a subpoena, or a change of ownership exposes nothing useful about you, the fact that someone else runs it barely matters. You are not really trusting them, because you did not give them anything to abuse.

Other hosted services, most mainstream SaaS and anything from an advertising company, can read your data, sell it, hand it over, and get breached with all of it inside. There, “hosted” means total trust, and the breach statistics above are what that trust costs on a long enough timeline.

So before anything else, ask: what can this host actually see and do? If the honest answer is “nothing useful, by design,” hosted is often the right call, self-hosting would add work and risk for little gain. If the answer is “everything,” you have a real decision to make.

The rest of the questions

Once you know what a hosted version would require you to trust, weigh these.

How bad is a breach of this, specifically? Run the worst case. If this service being exposed would be catastrophic, sensitive documents, client data, anything that ruins your week or your life, that pushes toward self-hosting or a genuinely trustless hosted option. If a breach would be a shrug, hosted convenience is fine. Not everything deserves the same paranoia.

Can you actually run it well? This is the honest gut-check most self-hosting enthusiasm skips. Running a service reliably means backups, updates, certificate renewals, monitoring, and fixing it at 11 p.m. when it breaks. It is a discipline, not a one-time setup. A self-hosted box you stood up once and never patched is a liability dressed as sovereignty, and it is worse than a reputable provider whose full-time job is keeping the lights on and the patches current. If you will not maintain it, do not host it.

Who are you actually defending against? Against advertisers and data brokers, a well-run, audited, no-logs hosted service is more than enough. Against a nation-state, or in any situation where the requirement is genuinely “no third party may ever hold this,” you need to either self-host or use an architecture where there is nothing to hold. Match the tool to the adversary, not to the vibe.

What happens if it disappears? A hosted service can vanish in ways you do not control: an outage, a shutdown, an acquisition, a rug-pull, an account locked because an algorithm flagged a family photo, a takedown like the ones that ended entire encrypted-phone networks. Self-hosted, the uptime is your problem, but no one can pull the plug from the outside. If continuity matters more than convenience, that weighs toward owning it.

Does its value come from other people using it? Some things are only useful because everyone else is on them. A secure messenger with no contacts is just a lonely app. Do not self-host the thing whose entire point is reach.

The heuristic, in plain terms

Put it together and it collapses into something you can actually apply.

Use a hosted service when it is trustless by design, or the data is low-stakes, or you genuinely cannot run it well yourself, or its value depends on network effects. When you do, choose the ones that are audited, keep no logs, and sit in a sane jurisdiction, so “hosted” costs you as little trust as possible.

Self-host when the data is sensitive and you can maintain it properly, or when you specifically need no outside party to hold it, or when you want to remove the external kill switch and subpoena and breach risk, or when every hosted option on offer demands more trust than you are willing to give.

And the best-of-both, which is where most serious setups actually land: prefer services built so hosting them carries almost no trust, and self-host the specific pieces that both warrant it and that you can run without becoming the weak link. Just make sure that when you do self-host, the machine underneath is hardened, because moving your data onto a box you neglect is not a win.

This is exactly how we build

We mention this not to pitch but because our whole approach is this framework made concrete. We ship the hosted services that are trustless by design, SimpleX for messaging, Mullvad for VPN, so that using someone else’s infrastructure costs you almost nothing. And we make self-hosting practical for the things that deserve it: your own mesh network with a control plane you run rather than a company’s, your own communications server, device management with no central server to breach, a private app store and update pipeline that answer to you. We wrote a whole piece on why a hosted management console’s reach-back is a liability, and this is the general version of that lesson.

We are not selling you “the cloud,” and we are not telling you to go self-host your entire life on hardware you will not patch. We are helping you put each service where it belongs, and giving you a device hardened enough to be a trustworthy foundation whichever way you choose for any given tool.

The mistake is not picking hosted, and it is not picking self-hosted. The mistake is not choosing at all, defaulting to whatever is easiest without ever asking what you are trusting, or self-hosting on principle without the capacity to do it safely. The skill, and it is the whole game, is matching each service to your threat model and your honest ability to run it. Get that boundary right and you get the benefits of both without the worst of either.

If you want help drawing that line for your actual situation, which services to trust to a good host and which to bring in-house, and a device solid enough to anchor either, that is what we do. Email hello@spicycorp.com, or book a call.