Sovereign Hosting for Small FOSS Projects

Sovereign hosting sounds grand, but for a small FOSS project it mostly means this: your project should survive a billing dispute, a provider policy change, a hostile acquisition, or a sudden price increase.

You do not need a private cloud. You need enough independence that moving is annoying rather than existential.

Start with the boring dependencies

Map the things your project relies on:

• Domain registrar
• DNS provider
• VPS or managed host
• Object storage or backups
• Email delivery
• CI/CD runner
• Monitoring
• Secrets storage

If one company controls most of that list, you have a concentration risk. It may be convenient, but convenience is not the same thing as resilience.

Separate domain, DNS, and compute

The fastest way to make hosting portable is to keep your domain and DNS independent from the server provider.

If your VPS account is suspended, you can point DNS elsewhere. If your DNS provider fails, your server still exists. If your registrar has an issue, your live services are not automatically in the same blast radius.

For most FOSS projects, a simple split works:

• Registrar: stable, boring, with good account security
• DNS: provider with API access and exportable zone files
• Compute: VPS or dedicated host that fits the workload

Make backups provider-independent

A backup stored only with the same provider is not a real exit plan.

Use restic, Borg, rclone, or a managed backup system that can write to a second provider. Test restoration before you need it. A tiny SQLite app, a Forgejo instance, or a documentation site can often be restored in under an hour if you have:

• Database dump
• Uploaded files
• Config files
• Secrets
• Deployment notes

The notes matter. Future-you will not remember every flag.

Prefer boring deployment

The more proprietary the deployment layer, the harder migration becomes.

Docker Compose, systemd services, Ansible, Terraform, and documented shell scripts are all boring in a good way. They make it easier to recreate the service on Hetzner, Netcup, Webdock, Mythic Beasts, or any other plain Linux host.

Managed platforms are fine when they are honest about export paths. Just avoid designs where your project only runs because of a provider-specific database, queue, build system, and secret store with no migration story.

Pick jurisdiction intentionally

Jurisdiction is not magic, but it matters.

An Icelandic or Dutch provider may be a better fit for a public-interest archive than a US hyperscale account. A UK provider may be best for a UK community project with local users. A German host may offer the best mix of price, bandwidth, and GDPR comfort.

The point is not that one country is always best. The point is choosing deliberately.

The practical sovereignty checklist

• Can you rebuild the service on a fresh VPS from notes?
• Are backups stored with a second provider?
• Can DNS be moved quickly?
• Are secrets documented without being exposed?
• Is email delivery decoupled from the main server?
• Do you know which data is personal data?
• Can another maintainer understand the setup?

If yes, you are in a good place. If no, fix the weakest item first.

A sane small-project pattern

For many FOSS projects:

• Static site on a VPS or static host
• Forgejo or GitHub mirror for code
• Nightly backups to object storage
• DNS at a separate provider
• Uptime monitoring from outside the host
• A short RUNBOOK.md

That is not glamorous. It is resilient.