Why Hetzner (and not AWS)

The more effort is poured into big cloud alternatives, the better they will be. Consider contributing your experience to open-source projects, writing docs, tutorials etc.

Lots has been written on the topic online. This move is a strategic shift from renting convenience to owning control. It is definitely not for everyone. Use this checklist to determine if it aligns with your business needs:

[ ] You have critical Data Sovereignty needs: Your European customers demand strict GDPR compliance, and you want to eliminate risks associated with US surveillance laws (e.g., CLOUD Act).
[ ] Your cloud bill is a meaningful cost: Your annual bill is significant enough that a 70-90% reduction would materially impact your business, but not so large that you require a global hyperscaler’s scale.
[ ] Your team has strong DevOps/IaC skills: You have, or are willing to invest in, in-house expertise with Linux, and stack like Ansible, Terraform, and open-source monitoring tools.
[ ] You are willing to trade convenience for control: You are ready to give up one-click managed services (like RDS) in exchange for more granular control, transparency, and lower costs.
[ ] Your workload doesn’t rely on niche, proprietary services: Your application is primarily based on standard components (e.g., VMs, PostgreSQL, object storage) that can be replicated outside the AWS ecosystem.

Key Benefits	Risks & Mitigations
💰 Radical Cost Savings (70-90%)	Risk: Hidden Labor Costs (TCO). The savings on infrastructure could be offset by increased engineering time for setup and maintenance. Mitigation: Acknowledge this is an upfront investment. Automate heavily with IaC (Ansible/Terraform) to minimize ongoing operational load.
🇪🇺 True Data Sovereignty	Risk: Provider Instability. Budget providers like Hetzner have a reputation for sudden account terminations or less reliable support. Mitigation: Do not use a single provider. Implement a multi-provider strategy from day one (e.g., Hetzner + OVHcloud).
⚙️ Greater Control & Forced Innovation	Risk: Increased Complexity. You become responsible for the entire stack, including backups, patching, and disaster recovery. Mitigation: Adopt a “compliance-as-code” mindset. Build robust, automated, and tested playbooks for all critical operations.

If you decide to proceed, this is the high-level playbook. The core principle is to build a resilient, auditable, and automated system using (preferably) open-source tools.

1. Foundational Strategy: Multi-Provider by Design

Never depend on a single budget provider. The recommended architecture combines at least two:

Primary Provider: Hetzner (for primary compute and services).
Secondary/Standby Provider: OVHcloud or similar (for backups and failover).
Global Traffic Manager: Cloudflare (for DNS, WAF, and load balancing between providers).

2. The Core Technology Stack

Replace AWS managed services with popular open-source stacks, managed via Infrastructure-as-Code (IaC). Most popular cloud provider services have open source equivalent/alternative.

Component	Purpose	Replaces (in AWS)
Terraform	Provisioning virtual machines and basic network resources.	CloudFormation
Ansible	Configuration, hardening, application deployment, and compliance engine.	Systems Manager
Prometheus & Alertmanager	Metrics collection and alerting.	CloudWatch Metrics
Grafana & Loki	Dashboards and log aggregation.	CloudWatch Logs
PostgreSQL (Self-hosted)	Primary database, managed via Ansible.	RDS / Aurora
Cloudflare	DNS, WAF, CDN, and load balancing.	Route 53, WAF

3. The Compliance-as-Code Engine

This is the key to maintaining ISO 27001 without AWS’s built-in tools.

Structure Ansible Playbooks to Match Controls: Tie every configuration directly to a specific ISO 27001 Annex A control.
- Example: An Ansible task that configures ufw rules is your evidence for control A.13.1.1 (Network Controls).
- Example: A task that installs and configures chrony satisfies A.12.4.4 (Clock Synchronization).
Make Your Code the Audit Trail: Your version-controlled IaC repository becomes a self-documenting, auditable record of your entire security posture, making audits simpler.

4. High Availability and Disaster Recovery (DR) Plan

Application Layer: Run active instances on multiple providers, with something like Cloudflare distributing traffic.
Database Layer:
- Set up a primary PostgreSQL instance on Hetzner.
- Use streaming replication to maintain a hot standby on OVHcloud.
- Have a tested, automated playbook (Ansible) to promote the standby to primary in a disaster scenario.
Backups: Automate encrypted database and asset backups to S3-compatible object storage on your secondary provider (OVHcloud). Regularly test your restore procedures.

While this stack depends again on Cloudflare, there are quite a few alternatives out there, and you do need to draw a line somewhere.

Continue to -> HN: algolia, Q: Hetzner