All by hand
- You harden the box yourself and want nobody else’s setup on it.
Attach a Hetzner server. Do not invent the base setup again.
Hetzner is often the right hardware. What is missing is everything after: Docker, database, reverse proxy, certificate, firewall, backup, then CI. SSH is enough for us to join.
- You keep root. We set up what deployments need.
- Production and staging can sit on separate boxes, same pipeline
Console only, or SSH plus setup
Hetzner, attached
- The machine is ordered. The base setup should not be invented a second time.
Docker
Databases
Reverse proxy
SSL
Backups
Firewall
- Coming soon
Kubernetes
- Coming soon
Monitoring
Hetzner is there in minutes. The rest of the day is Docker, certificates, firewall, backup — and the same list on the second server. Automating here does not mean rebuilding Hetzner. It means attaching the server so the pipeline knows it.
Setting a server up yourself or connecting it to the platform
This lays out the work that sits between an ordered server and a working deployment.
| Criterion |
With the Application Platform
|
Setting the server up yourself
|
|---|---|---|
| Server baseline | Fully covered: Docker, databases, reverse proxy, SSL, firewall and backups are configured | Not offered: Every step individually, usually from a personal checklist or notes |
| Attaching deployments | Fully covered: The server is connected to the project’s GitLab CI pipeline | Partly covered: Build and maintain your own script or deployment tool |
| Certificates and renewal | Fully covered: SSL is part of the setup, domains are managed in the project | Partly covered: Expiring certificates often surface only through an error message |
| Backups | Fully covered: Created as part of the setup | Partly covered: Usually deferred and rarely tested |
| Credentials and environment variables | Fully covered: Managed centrally in the project, with permissions per role | Not offered: Spread across files on the server and local notes |
| Traceable environments | Fully covered: Environments and deployments live as configuration in the Git history | Not offered: State lives in the machine rather than in a repository |
| Adding a second server | Fully covered: The same flow, regardless of how many servers or which provider | Not offered: Repeating the manual work, with small unexplained differences |
| Separating environments | Fully covered: Staging and production as distinct environments in the project | Partly covered: Often one server for everything, because a second means more work |
| Team access control | Fully covered: Roles and project membership govern who reaches the server | Not offered: SSH keys get handed out and rarely removed again |
| Full control of the machine | Fully covered: SSH access stays with you, you can always intervene yourself | Fully covered: Equally complete, with nothing imposed from outside |
Green means covered, amber partly, grey not available. The right column describes no vendor but the usual manual work on a freshly ordered server.
As of 9 September 2026. Based on the publicly documented feature scope of the providers named. Details can change; the provider’s current documentation takes precedence. Logos are trademarks of their owners and are used only to identify the product.
What Hetzner already gives you
- Price and location Hetzner often remains the right hardware. The platform does not replace the hoster; it attaches to the server.
Pricing model
You pay for the server at Hetzner. The platform is a separate line.
Connecting a Hetzner server
Four steps from an ordered machine to a first deployment.
-
Provision the server
Create the server at your provider. All the connection needs is reachable SSH access.
-
Store the access
Add the server in the platform’s server section. The platform validates the access and starts configuring.
-
Let the baseline run
Docker, databases, reverse proxy, SSL, firewall and backups get set up and prepared for deployments.
-
Connect a project
Select the server when creating or editing a project. From then on the pipeline deploys there.
Frequently asked questions
Is there a walkthrough for connecting a server?
Yes, the documentation includes a Hetzner tutorial covering each step to a fully configured server. Other providers follow a comparable flow over SSH. If you would rather not manage a server, the same documentation describes managed servers.
Is there a partnership with Hetzner?
No. Hetzner is an independent company with no business relationship to the platform. The connection relies on ordinary SSH access, just like with any other host. Your contract, billing and availability stay between you and your provider.
Does this work with other providers too?
Yes. What matters is a reachable server with SSH access, not the provider's name. Machines at other hosts or in your own data centre connect the same way. Alternatively, use a managed server from the platform.
Do I keep my SSH access?
It stays. You can connect to the machine at any time and see what is running. The platform deploys to it but does not take access away from you. Roles and project membership decide who sees the server and who can trigger deployments.
Can I attach a server that is already in use?
Technically yes, but proceed carefully. The platform establishes a defined baseline, which can conflict with existing ports, proxy configuration or services. A fresh machine is the simpler start for a clean setup.
Connect your server
Register for free, add a server over SSH and see how far the setup gets without any input from you.