Self-hosting on Hetzner means renting a Linux cloud server, locking it down before anything else, then running your apps on infrastructure you fully control. The workflow is: create the server, harden SSH and the firewall, install Docker and Coolify, deploy your app with automatic SSL, and schedule backups you have actually tested.
Short answer
To self-host on Hetzner, create a Hetzner Cloud server running Ubuntu LTS, add your SSH key, and harden it — disable root and password login, enable a UFW firewall, add Fail2ban, and apply updates. Then install Coolify with one command, open ports 22, 80, 443, and 8000, deploy your app from Git, attach a domain for free Let's Encrypt SSL, and schedule backups to S3-compatible storage.
I run open-source implementations at Mith Tech in Bengaluru, and Hetzner is the box I reach for when a client wants predictable, self-owned infrastructure without a hyperscaler's bill or its complexity. Honestly, provisioning the server is the easy ten minutes — the part that actually protects you is the boring hardening most tutorials skip past.
What does self-hosting on Hetzner actually involve?
Self-hosting on Hetzner combines a rented cloud server with a stack you install and own end to end. Hetzner supplies the raw compute, network, and firewall; you supply the operating-system hygiene, the deployment tooling, and the backup discipline. Nothing about your data or apps is locked to a proprietary platform.
The appeal is control with predictable economics. Hetzner runs its own data centres in Nuremberg and Falkenstein in Germany and in Helsinki, Finland, plus cloud regions in Ashburn (Virginia), Hillsboro (Oregon), and Singapore. You get a real Linux machine, not an opaque managed runtime, which means you decide the OS, the firewall rules, and who holds the SSH keys. Pricing is usage-based and varies by server type — check Hetzner's official page for current figures. For a fuller platform comparison, see our Hetzner vs AWS breakdown.
Skimmable summary: Hetzner rents you a clean Linux server; you own the OS, security, deployment, and backups on top of it.
How do you provision a Hetzner Cloud server?
Provisioning starts in the Hetzner Cloud Console, where a new server is a few clicks: pick a location, an image, a server type, and an SSH key. Choose Ubuntu 24.04 LTS or Debian 13 as the image, since the Coolify installer supports Ubuntu LTS releases cleanly and non-LTS builds need manual steps.
Create a project and add your SSH key
In the Cloud Console, create a project, then add your public SSH key under Security. Adding the key at creation time means the server never has a root password to guess — key-based login from the very first boot.
Pick a region close to your users
Select a location by latency and data residency. Indian SMBs often compare Singapore for proximity against the German and Finnish regions for EU data residency. Latency to your users matters more than the flag on the data centre.
Choose a server type and image
Select a shared or dedicated vCPU plan sized to your workload and pick Ubuntu 24.04 LTS. For a real platform running several apps, give yourself more than the bare minimum RAM — a single app is fine on a small box, but headroom prevents pain later.
Create the server and note its IP
Create the server. Within a minute Hetzner assigns a public IPv4 and IPv6 address. Copy the IPv4 address — that is where you point SSH and, later, your DNS records.
Turn on the Hetzner Cloud Firewall too
Hetzner offers a network-level cloud firewall that sits in front of the server, independent of the OS firewall. Attach one and allow only the ports you need. Two layers — cloud firewall plus UFW on the host — is defence in depth, not overkill.
Skimmable summary: Create a project, attach your SSH key up front, choose an Ubuntu LTS image in a region near your users, and note the public IPv4 address.
How do you harden a fresh server before anything else?
Hardening happens before you install a single app, because a fresh public server is scanned within minutes of coming online. The core moves are: log in with your key, create a non-root sudo user, disable root and password logins in SSH, enable a firewall that allows SSH first, add Fail2ban, and apply all pending updates.
Update the system
Connect with ssh root@your-server-ip, then run apt update && apt upgrade -y. Patching first closes known holes before the box is exposed to real traffic.
Create a non-root sudo user
Add a user with adduser manoj and grant sudo with usermod -aG sudo manoj. Copy your SSH key to it with rsync --archive --chown=manoj:manoj ~/.ssh /home/manoj. Daily work should never happen as root.
Lock down SSH
Edit /etc/ssh/sshd_config and set PermitRootLogin no, PasswordAuthentication no, and PermitEmptyPasswords no. Restart with systemctl restart ssh. Key-only login removes password guessing as an attack path entirely.
Enable the UFW firewall
Set defaults with ufw default deny incoming and ufw default allow outgoing, then — crucially — ufw allow OpenSSH before you run ufw enable, so you do not lock yourself out. Add ports 80, 443, and 8000 when you install Coolify.
Add Fail2ban
Install with apt install fail2ban -y. It watches auth logs and bans IPs after repeated failures, with banaction = ufw so every ban appears as a normal firewall rule. Keys stop guessing; Fail2ban stops the noise and resource drain.
Enable automatic security updates
Install unattended-upgrades so security patches land without you remembering to log in. A server that patches itself is one fewer thing to forget.
Allow SSH before enabling the firewall
The single most common self-inflicted lockout is enabling UFW with a default-deny policy and no SSH rule in place. Always run ufw allow OpenSSH first. If you are on the default port 22, that is what OpenSSH maps to.
Skimmable summary: Patch, create a sudo user, disable root and password SSH login, enable UFW allowing SSH first, add Fail2ban, and turn on automatic updates — all before installing apps.
How do you install Docker and Coolify?
Installation is one command that installs Docker and brings up Coolify, an open-source, self-hostable platform that turns your hardened server into a push-to-deploy PaaS. The official installer pulls in Docker Engine and supporting tools, then starts the Coolify stack, typically in a few minutes on Ubuntu LTS or Debian.
Open the ports Coolify needs
Coolify requires four ports reachable from the internet: 22 for SSH, 80 and 443 for your apps and SSL, and 8000 for the setup dashboard. Add them in UFW and in your Hetzner Cloud Firewall before running the installer.
Run the official install script
Execute the installer as root:
curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash
It installs Docker, configures dependencies, and starts Coolify. Review any script before piping it to a shell if you are security-conscious.
Open the dashboard on port 8000
When the script finishes it prints a URL like http://your-server-ip:8000. Open it in a browser to reach the registration page.
Create the admin account
The first account you register becomes the root admin. Use a strong, unique password and save it to your password manager immediately — this dashboard controls every app it deploys.
Docker plus Coolify is one route, and a good default; you can also run plain Docker Compose or a full PaaS layer depending on how much automation you want. If you would rather understand the tool in depth first, our guide to self-hosting with Coolify walks through it end to end.
Skimmable summary: Open ports 22, 80, 443, and 8000, run one install script as root, then create your admin account at port 8000 on the printed URL.
How do you deploy an app and add SSL?
Deployment points Coolify at a source and lets it build and run the container, while SSL becomes automatic the moment you attach a domain. Create a project, add a resource from a Git repository or a one-click service, and Coolify detects the framework, builds the image, and starts the container with live logs.
For SSL, set the app's domain (for example https://app.yourdomain.com) in its settings, then create a DNS A record pointing that hostname at your Hetzner server's public IPv4 address. Coolify requests a free Let's Encrypt certificate, installs it, and renews it before expiry — no manual certbot. The one prerequisite is that ports 80 and 443 are open and DNS has propagated, because Let's Encrypt validates the domain over HTTP first.
Wire Git for push-to-deploy
Connect GitHub, GitLab, Bitbucket, or Gitea so every push to your chosen branch triggers a fresh deployment. That push-to-deploy loop is what makes a self-hosted box feel like a managed platform, minus the lock-in.
Skimmable summary: Add a resource from Git or a template, let Coolify build and run it, set the domain, add a DNS A record to your server IP, and Coolify auto-issues free SSL.
How do you set up backups you can actually restore?
Backups belong on a schedule, targeting storage that lives somewhere other than the server itself. Coolify has database backups built in: open a database resource's Backup tab, enable a cron-style schedule, and point it at an S3-compatible bucket by supplying the endpoint, bucket, and access keys. Any S3-compatible provider works — AWS S3, Cloudflare R2, or a self-hosted MinIO.
Layer server-level protection on top. Hetzner offers automated server backups and manual snapshots at the infrastructure level, which capture the whole machine rather than a single database — useful for fast full-server recovery. Keep the two together: application-level database dumps for granular restores, plus provider snapshots for the whole box. Then do the one step everyone skips.
Test a restore before you rely on it. An untested backup is a hope, not a safety net. If you self-host something business-critical — an ERP, say — a recoverable database is the entire point, which is why our ERPNext deployments treat restore drills as part of go-live, not an afterthought.
Skimmable summary: Schedule Coolify database backups to S3-compatible storage, add Hetzner server snapshots for full-machine recovery, and always test a restore before you depend on it.
Hetzner vs the hyperscalers: is it the right fit?
Hetzner suits teams that want a real Linux server, predictable usage-based billing, and their own security posture, rather than a sprawling managed-service catalogue. The trade-off is responsibility: you own the OS hardening, deployment tooling, and backups that a fully managed platform would otherwise abstract away.
| Concern | Hyperscaler (managed) | Self-hosting on Hetzner |
|---|---|---|
| Server access | Often abstracted | Full root Linux server |
| Pricing model | Many metered services | Usage-based, fewer line items |
| Ops responsibility | Vendor handles more | You own hardening + backups |
| Data residency | Region-dependent | You pick the region |
| Lock-in | Higher | Low — standard Docker + Linux |
For most Indian SMBs I work with, Hetzner plus Coolify hits a sweet spot: cheaper and simpler than a hyperscaler, more capable and durable than a shared host. If you need the deeper cost-and-capability comparison, our Hetzner vs AWS guide lays it out qualitatively.
Skimmable summary: Hetzner trades managed-service breadth for a real server, predictable billing, and region control — at the cost of owning your own security and backups.
Frequently asked questions
Is Hetzner good for self-hosting in 2026?
Yes. Hetzner Cloud gives you a clean Linux server with usage-based billing and its own network-level firewall, across regions in Germany, Finland, the US, and Singapore. It pairs well with Docker and Coolify for a push-to-deploy stack. The trade-off is that you own OS hardening and backups yourself, rather than leaning on a managed platform.
Which Hetzner region should an Indian business choose?
Choose by latency and data residency. Singapore is the closest Hetzner cloud region to India for lower latency, while the German and Finnish data centres suit teams that need EU data residency. Test latency to your actual users rather than assuming the nearest region always wins, and factor in any compliance rules on where data must physically live.
What operating system should I use on a Hetzner server?
Ubuntu 24.04 LTS or Debian 13 are the safe defaults. The Coolify installer supports Ubuntu LTS releases cleanly, and both distributions receive long-term security updates. Avoid non-LTS Ubuntu builds for a production server, since the automatic installer expects LTS versions and non-LTS releases require manual installation steps.
Do I need to harden the server before installing anything?
Yes, and it should be your first task. A fresh public server is scanned within minutes. Disable root and password SSH login in favour of keys, enable a UFW firewall that allows SSH before you turn it on, add Fail2ban, and apply all updates. Hardening before deployment shrinks the attack surface dramatically for very little effort.
Can I run ERPNext or other apps on a Hetzner server?
Yes. A Hetzner server runs any containerised workload, and many teams self-host Frappe-based stacks like ERPNext this way. That said, a production ERP has specific worker, scheduler, and backup needs that go beyond a basic deploy. For a reliable topology, our Frappe and ERPNext team can advise on sizing and recovery.
How much does self-hosting on Hetzner cost?
Hetzner Cloud is billed by usage, and the exact figure depends on the server type, storage, backups, and traffic you choose — pricing varies by plan, so check Hetzner's official page for current rates. Beyond the server itself, the software here is free: Coolify is open source, and ERPNext is free and open source under GPLv3. Your main cost is the infrastructure.
About the author
I'm Manoj, an ERPNext implementation consultant at Mith Tech, an independent open-source implementation studio in Bengaluru. I help Indian SMBs deploy and run open-source software — ERPNext, automation tools, and self-hosted infrastructure — on systems they actually own. I write these guides from real implementation work, not vendor brochures.
Want a hardened Hetzner server set up properly, without the guesswork?
If you would rather have someone provision the server, harden it, install Coolify, and wire up dependable backups for you, get in touch — self-hosting done right is mostly the discipline that happens after the first deploy.