Blog post
Making my self-hosted infrastructure a little more European
How I replaced several non-EU services with EU-based providers or self-hosted alternatives, while keeping the compute I already run at home.
Intro
I've been moving external services, especially those based outside the EU, to EU-based providers or services I host myself. The goal is to reduce my dependence on non-EU providers, gain more control over my infrastructure, and keep services and data closer to home where possible. I don't necessarily want to eliminate external services altogether, but rather choose European or self-hosted alternatives where it makes sense.
Luckily, I already host a lot at home on my Proxmox server. Compute capacity wasn't a problem I needed to solve, and I didn't need to rent a new cloud server just to make this change. Most of the work involved replacing a handful of supporting services: DNS, authentication, serverless workloads, and object storage.
DNS: Cloudflare to deSEC
I moved my hosted DNS from Cloudflare to deSEC. deSEC is operated by a German nonprofit and offers the features I need, including DNSSEC and a REST API.
deSEC has an integration for Caddy, so I could keep the certificate workflow I was already using while changing DNS providers. In my experience, DNS changes take a little longer to propagate with deSEC than with Cloudflare. This was easy to accommodate by adding a propagation delay to my Caddy configuration (shown below), giving DNS records more time to propagate before Caddy checks them.
(desec) {
tls {
dns desec {
token {env.DESEC_API_TOKEN}
}
propagation_delay 5m
}
}
DNS is one of those foundational services I didn't want to self-host, mainly because of the high availability and reliability requirements.
Authentication: Cloudflare Access to Authelia
I previously used Cloudflare Access as an authentication layer in front of some applications. Authelia isn't a direct drop-in replacement for that setup, so I had to change how authentication works in my infrastructure.
Instead of protecting applications at the proxy level, I configured them to use Authelia as their OpenID Connect (OIDC) provider. The applications are now publicly reachable, but users must authenticate through Authelia to access protected functionality.
Authelia also supports proxy-level authentication through Caddy's forward_auth directive, but I chose OIDC because it allows authentication to be handled directly by the applications.
This gives me more control over authentication, though it also means I'm responsible for operating Authelia and ensuring that each application correctly enforces authentication on its protected endpoints.
Workloads: Cloudflare Workers to containers
I also used Cloudflare Workers for a few workloads. I'm gradually moving these to container images built locally and deployed on Kubernetes instead.
This is a different operating model: instead of deploying code to a hosted serverless platform, I build an image and run it on infrastructure I control. Since I already have enough compute capacity at home, I can make that change without adding another cloud compute bill.
Object storage: Backblaze to Scaleway
I previously used Backblaze for off-site backups, but I've switched to Scaleway Object Storage, an EU-based alternative.
My backups are encrypted, while primary application data remains on my Proxmox server, stored on ZFS. Scaleway serves only as the off-site backup destination, ensuring I still have a separate copy of my data outside my home infrastructure.
This allows me to keep my existing storage setup while moving my off-site backups to a European provider.
Email is still in progress
Outgoing email is one part I haven't moved yet. I currently use SMTP2GO as my relay and plan to switch to Scaleway Transactional Email (TEM).
However, TEM doesn't yet support all the features I rely on, so I'm sticking with SMTP2GO for now. I'd rather keep a service