Hetzner is cheap and fast
Good CPUs, lots of RAM, sane bandwidth, and pricing that does not punish you for being successful.
Familiar VMs. Less platform theater.
You want your app online. You do not want Kubernetes homework, surprise PaaS bills, or a control plane that turns every deploy into a ceremony. Rent a fast Hetzner box, let devopsellence ship the container, and keep ordinary Linux escape hatches.
Why this exists
Good CPUs, lots of RAM, sane bandwidth, and pricing that does not punish you for being successful.
Build an image, stream it to your VM, run health checks, keep secrets out of git, and inspect the result with normal tools.
The server is still yours. The app is still a container. The logs are still logs. No magic cliff when you outgrow the first box.
Comparison
Option
Best when you want ownership without cosplay SRE.
Great early, until pricing, limits, buildpacks, and platform quirks become the product you manage.
Solid Rails-native deploys. devopsellence aims for agent-friendly workflows, explicit node state, and broader app shapes.
Powerful, real, and usually too much when the actual requirement is one app on one or a few servers.
Workflow
Start solo, point at a server later, dry-run before mutation, deploy when ready. No hosted dependency required for the first useful version.
01
Build your Rails app locally.
02
Configure devopsellence solo.
03
Attach a Hetzner VM when you are ready.
04
Dry-run, deploy, inspect status and logs.
FAQ
No. PaaS is great when its constraints match your app. This is for the moment you want cheaper, clearer, more ordinary infrastructure.
No. Build the app first. Run a devopsellence dry run before any production mutation. Attach Hetzner when the deployment target is real.
You still own the server. That means updates, backups, capacity, and incident response are not outsourced. The win is that the system remains understandable.