Services for Alternative Clouds and Multi-Cloud

Alternative Cloud Platforms: Hetzner and DigitalOcean in Production

We work with alternative cloud platforms—DigitalOcean, Hetzner Cloud, OVH, Selectel—and build multi‑cloud architectures without vendor lock‑in. When data is not tied to RF jurisdiction, the choice of providers expands. Hetzner is a special case: its VDS costs 3–5 times lower than comparable AWS or GCP configurations, making it the primary choice when infrastructure margin is critical. DigitalOcean steadily holds developer audiences for price predictability and managed services.

Some cloud platforms stand out for production workloads. Based on our experience, Hetzner and DigitalOcean cover most scenarios: Hetzner for compute‑heavy tasks where the price of RAM and CPU cores matters; DigitalOcean for managed services (Kubernetes, PostgreSQL, Redis) when a dedicated DevOps is not available. Both providers support Terraform, have mature APIs and stable SLAs. Below is a breakdown of key solutions.

Reach out to evaluate your current cloud bill and migration feasibility.

Hetzner: How to Maximize Value from Affordable Hardware

Hetzner Cloud is a German provider with data centers in Nuremberg, Falkenstein, and Finland. CX21 (2 vCPU, 4 GB RAM) costs about €3.49 per month. A dedicated server AX41 with Ryzen 5 3600 and 64 GB RAM is affordable. This changes architectural decisions.

The Terraform provider hetznercloud/hcloud is mature and stable. Basic cluster configuration with three control‑plane nodes and autoscaling worker pool:

resource "hcloud_server" "control_plane" { count = 3 name = "k8s-cp-${count.index}" image = "ubuntu-22.04" server_type = "cx31" location = "nbg1" ssh_keys = [hcloud_ssh_key.default.id] network { network_id = hcloud_network.k8s.id ip = "10.0.1.${count.index + 10}" } } resource "hcloud_load_balancer" "k8s_api" { name = "k8s-api-lb" load_balancer_type = "lb11" location = "nbg1" } 

According to Hetzner Cloud documentation, managed load balancers (lb11) provide TCP/HTTP balancing at a very low cost. For K8s API server, optimal: three control‑plane nodes, Hetzner LB in front.

Kubernetes on Hetzner without managed service — Managed K8s is still in beta, so most teams deploy via k3s or kubeadm. k3s is preferred: control‑plane lives in 512 MB, built‑in Traefik, SQLite or external etcd.

CSI for persistent volumes—hcloud-csi-driver. It creates Hetzner Volumes (network disks) as PersistentVolume. Default StorageClass is hcloud-volumes. RWO, not RWX—if ReadWriteMany needed, use NFS or object storage.

Network: Private Network is mandatory for production. Public IPs are on each server by default, but traffic between servers inside Private Network is free and unlimited. Traffic via public interface has quotas and tariffs. Pod‑to‑pod via Flannel or Calico should go through private network, otherwise active inter‑node communication (Kafka, Cassandra) will surprise with bills.

Hetzner Object Storage is S3‑compatible. Endpoint: https://fsn1.your-objectstorage.com. Cost per GB is 60–70% lower than AWS S3 Standard. Velero backup with Hetzner S3 as backend:

# values.yaml for Velero configuration: provider: aws backupStorageLocation: bucket: k8s-backups config: region: fsn1 s3Url: https://fsn1.your-objectstorage.com s3ForcePathStyle: "true" 

How to avoid vendor lock‑in when working with alternative clouds?

Multi‑cloud strategy is not about “running everything everywhere simultaneously.” It’s about specific decisions: prod in Hetzner, CDN and DNS via Cloudflare, backups in S3 of another provider, CI/CD on dedicated runners in DigitalOcean.

Terraform workspace approach with reusable modules keeps infrastructure portable:

• infrastructure/modules/k8s-cluster/
• infrastructure/modules/postgres/
• infrastructure/modules/object-storage/
• infrastructure/environments/prod-hetzner/
• infrastructure/environments/staging-do/

One k8s-cluster module with abstract interface (input: node_count, node_size, region) and two implementations for different providers. terraform workspace select prod-hetzner && terraform apply — production, terraform workspace select staging-do && terraform apply — staging on DigitalOcean.

State locking is critical: without it, parallel terraform apply from two engineers corrupts state — you’ll see an error like Error acquiring the state lock and must run terraform force-unlock with manual consistency check.

Crossplane is an alternative to Terraform for managing cloud resources from Kubernetes. Providers for Hetzner and DigitalOcean are available. XRD describes abstractions like “cluster” or “database”, concrete implementation in Composition. For teams already living in Kubernetes, an interesting option: kubectl apply -f postgres-claim.yaml creates managed PostgreSQL at the provider.

DigitalOcean: Managed Services Without Headache

DigitalOcean positions itself as “the cloud for developers”—and that’s not marketing. DOKS (DigitalOcean Kubernetes Service) spins up in 5 minutes via UI or Terraform, DigitalOcean Managed PostgreSQL and Redis in another 10 minutes. For small production services without dedicated DevOps—a reasonable compromise.

doctl is a CLI that is actually used alongside kubectl:

doctl kubernetes cluster create prod \ --region fra1 \ --node-pool "name=workers;size=s-4vcpu-8gb;count=3;auto-scale=true;min-nodes=2;max-nodes=8" \ --version 1.29 

DOKS supports cluster-autoscaler out of the box. Container Registry is integrated via doctl registry kubernetes-manifest | kubectl apply -f -.

Weak point of DigitalOcean—instance sizes. The most powerful Droplet without dedicated CPU is 32 vCPU, 192 GB RAM. For GPU tasks or heavy compute, another provider is needed. For typical web+API stack, it’s more than enough.

Comparison of key characteristics:

# /etc/wireguard/wg0.conf on cloud side [Interface] PrivateKey = <cloud-private-key> Address = 10.100.0.1/24 ListenPort = 51820 [Peer] PublicKey = <onprem-public-key> AllowedIPs = 10.100.0.2/32, 192.168.1.0/24 Endpoint = <onprem-ip>:51820 PersistentKeepalive = 25