Self-hosting on Hetzner means renting a Linux cloud server, locking it down before anything else, then running your apps on infrastructure you control. The order 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
Create a Hetzner Cloud server running Ubuntu LTS with your SSH key, then harden it: disable root and password login, enable the UFW firewall, add Fail2ban and apply updates. Install Coolify with one command, open ports 22, 80, 443 and 8000 (plus 6001 and 6002 while you use the dashboard by IP), deploy your app from Git, attach a domain for free Let's Encrypt SSL, and schedule backups to S3-compatible storage.
I lead open-source and platform deployments at MithTech, a team of Frappe specialists in Bengaluru. Hetzner is where we go when a client wants predictable, self-owned infrastructure without a hyperscaler's bill or its complexity. Honestly, creating the server is the easy ten minutes. What protects you is the dull hardening most tutorials skip.
What does self-hosting on Hetzner involve?
A rented cloud server plus a stack you install and own end to end. Hetzner supplies the compute, network and firewall; you supply the operating-system hygiene, the deployment tooling and the backup discipline. Nothing about your data or apps is tied to a proprietary platform.
The appeal is control with predictable billing. Hetzner runs its own data centres in Nuremberg and Falkenstein (Germany) and Helsinki (Finland), plus cloud locations in Ashburn (Virginia), Hillsboro (Oregon) and Singapore. You get a real Linux machine, not an opaque managed runtime, so you decide the OS, the firewall rules and who holds the SSH keys. Prices vary by server type; check Hetzner's own page for current figures. For a fuller comparison, see our Hetzner vs AWS breakdown.
How do you provision a Hetzner Cloud server?
In the Hetzner Cloud Console a new server is a few clicks: location, image, server type and SSH key. Choose Ubuntu 24.04 LTS or Debian 13 as the image; Coolify's installer handles Ubuntu LTS and Debian directly, and its docs send non-LTS Ubuntu releases to the manual install.
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 means the server never has a root password to guess: key-based login from the first boot.
Pick a region close to your users
Choose by latency and data residency. Many Indian teams compare Singapore, for proximity, against the German and Finnish locations, for EU data residency. Latency to your users matters more than the flag on the data centre.
Choose a server type and image
Pick a shared or dedicated vCPU plan sized to your workload, and Ubuntu 24.04 LTS. Coolify's minimum is 2 cores, 2 GB RAM and 10 GB of disk; for a platform running several apps, give yourself more than that.
Create the server and note its IP
Create the server. Hetzner assigns a public IPv4 and IPv6 address. Copy the IPv4 address: that is where you point SSH and, later, your DNS records.
How do you harden a fresh server before anything else?
Before you install a single app, because a fresh public server starts getting scanned soon after it comes online. 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 takes 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. Day-to-day work should not 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.
Enable the UFW firewall
Set ufw default deny incoming and ufw default allow outgoing, then run ufw allow OpenSSH before ufw enable, so you do not lock yourself out. Add the Coolify ports when you install it.
Add Fail2ban
Install with apt install fail2ban -y. It watches the auth logs and bans IPs after repeated failures; with banaction = ufw, every ban shows up as a normal firewall rule. Keys stop the guessing; Fail2ban stops the noise and the wasted resources.
Enable automatic security updates
Install unattended-upgrades so security patches land without anyone remembering to log in.
Skimmable summary: patch, create a sudo user, turn off root and password SSH login, enable UFW with SSH allowed first, add Fail2ban, and turn on automatic updates, all before installing apps.
How do you install Docker and Coolify?
One command installs Docker and brings up Coolify, an open-source (Apache 2.0), self-hostable platform that turns your hardened server into a push-to-deploy PaaS. The official installer pulls in Docker Engine and its tools, then starts the Coolify stack.
Open the ports Coolify needs
Coolify's firewall guide lists 22 for SSH, 80 and 443 for your apps and certificates, and 8000 for the dashboard by IP, plus 6001 (real-time updates) and 6002 (web terminal) while you reach the dashboard by IP. Add them in UFW and in the Hetzner Cloud Firewall before running the installer.
Run the official install script
As root, or a user with sudo:
It installs Docker, sets up its dependencies and starts Coolify. If you are security-conscious, read a script before piping it to a shell.
Open the dashboard on port 8000
When the script finishes it prints a URL like http://your-server-ip:8000. Open it to reach the registration page.
Create the admin account at once
Whoever registers first becomes the instance admin with root access to the server, so do it straight after the install. Use a strong, unique password and save it to your password manager. (You can also pre-set the root account during install with the ROOT_USERNAME, ROOT_USER_EMAIL and ROOT_USER_PASSWORD variables.)
Once the dashboard runs on a domain through Coolify's proxy, close public access to 8000, 6001 and 6002; they then go through 80 and 443. Docker plus Coolify is one route, and a good default; you can also run plain Docker Compose. To learn the tool in depth first, our guide to self-hosting with Coolify walks through it end to end.
How do you deploy an app and add SSL?
Point Coolify at a source and it builds and runs the container; SSL is automatic once 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 server's public IPv4 address. Coolify requests a free Let's Encrypt certificate, installs it and renews it before expiry, with no manual certbot. Ports 80 and 443 must be open and DNS must have propagated, because Let's Encrypt validates the domain over HTTP first.
How do you set up backups you can actually restore?
On a schedule, to storage that lives somewhere other than the server. Coolify has database backups built in: open a database resource's Backup tab, set a cron-style schedule, and point it at an S3-compatible bucket with the endpoint, bucket name and access keys. Any S3-compatible provider works: AWS S3, Cloudflare R2 or a self-hosted MinIO.
Add server-level protection on top. Hetzner offers automated server backups and manual snapshots that capture the whole machine rather than one database, which helps with fast full-server recovery. Keep both: database dumps for granular restores, and provider snapshots for the whole box.
Then test a restore before you rely on it. If you self-host something business-critical, an ERP for example, a recoverable database is the whole point, which is why our Frappe and ERPNext work treats restore drills as part of go-live.
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 large catalogue of managed services. The trade-off is responsibility: you own the OS hardening, deployment tooling and backups that a managed platform would hide.
| 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 and backups |
| Data residency | Region-dependent | You pick the region |
| Lock-in | Higher | Low: standard Docker and Linux |
For many of our clients, Hetzner plus Coolify is the right middle: simpler to run than a hyperscaler, more capable than a shared host. The deeper comparison is in our Hetzner vs AWS guide.
Should you run the Hetzner server yourself, or have it run for you?
Run it yourself if someone on your team will apply OS and Coolify updates, watch the firewall, and test the restore above on a schedule; Hetzner is then a fair, low-cost home for your apps. Have it run for you if nobody owns that work, because a hardened server stays hardened only while someone keeps patching it.
Do it yourself if
You have someone at home with Linux, SSH, UFW and Docker, a spare server or snapshot to test restores on, and apps that can be offline for a few hours while they fix something.
Have it run for you if
What runs on the server (an ERP, a store, customer chats) cannot be down for a day, nobody wants to be the person who patches it, or those hours cost more than a monthly fee.
Under managed hosting we run one named server in your cloud account or ours, and a Hetzner account in your name works: nightly backups copied off it, one restored on a schedule, every upgrade tried on a copy first, and the keys stay yours. It is a monthly fee for running it plus the server, quoted in writing after a call. To weigh that quote against doing it yourself, use the self-hosting cost comparator; for ERPNext, who runs it after go-live sets out who does each job on each path.
Frequently asked questions
+Is Hetzner good for self-hosting in 2026?
Yes, for teams willing to run their own server. Hetzner Cloud gives you a clean Linux server with usage-based billing and a network-level firewall, in Germany, Finland, the US and Singapore. It pairs well with Docker and Coolify for a push-to-deploy stack. You own OS hardening and backups yourself.
+Which Hetzner region should an Indian business choose?
Choose by latency and data residency. Singapore is the closest Hetzner cloud location to India; the German and Finnish data centres suit teams that need EU data residency. Test latency to your actual users, and factor in any rules on where your data must physically live.
+What operating system should I use on a Hetzner server?
Ubuntu 24.04 LTS or Debian 13. Coolify's automatic installer handles Ubuntu LTS releases and Debian, and its docs send non-LTS Ubuntu to the manual install. Both distributions get long-term security updates.
+Do I need to harden the server before installing anything?
Yes, first. 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. It takes little effort and shrinks the attack surface a lot.
+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. A production ERP has its own worker, scheduler and backup needs beyond a basic deploy; 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 figure depends on the server type, storage, backups and traffic you choose; check Hetzner's own page for current rates. The software in this guide has no licence fee: Coolify is open source (Apache 2.0), and so is ERPNext (GPL-3.0). Your main costs are the infrastructure and the time to run it.
If you would rather have us provision the server, harden it, install Coolify and set up backups that restore, get in touch. Self-hosting done right is mostly the discipline after the first deploy.
Comments & ratings
No comments yet. Start a new discussion.
Manoj · Published on 20 July 2026
Worked with us? Leave a Google review