Infrastructure in Hetzner Cloud: what breaks with manual setup
Manual server setup almost always starts the same way: a machine is spun up, configured in place, and edits are made directly on the running node.
A couple of months later, the staging and production environments diverge in package versions, service parameters, and open ports — the third stand can no longer be brought up from the documentation, and replacing a failed node turns into a nighttime reconstruction from memory.
This is not a one-off mistake but configuration drift: it repeats with every release and makes the state of the environment unpredictable.
Failures caused by fragmented configurations accumulate unnoticed.
Backups are created on schedule, but restoration from them has never been tested; the network scheme was assembled haphazardly: the private network is not connected to the load balancer, firewall rules are open wider than necessary, certificates are renewed manually.
When a node fails, it turns out that the dependency on a single machine was not obvious — the queue, the task scheduler, and the entry point for clients all rest on it.
The cost of such a failure is not minutes but hours of downtime and the last day's data, with nothing to restore it from: while the engineer re-establishes access, customers are already seeing the error on their screens.
Next, we break down how this is closed.
In Hetzner Cloud, cloud infrastructure setup is done not by hand but by description: the environment is brought up in a single run, networks, access, and copies are created from a single template, and restoration is tested before anything breaks.
What managed infrastructure delivers: the effect on timelines and reliability
Managed infrastructure changes not an individual metric but the behavior of the system under load and at the moment of failure.
Environment descriptions are stored in a repository, any edit passes review and is reproduced identically across all environments — on Hetzner Cloud this is assembled from images and templates without manual tweaks on servers. Three measurable consequences follow from this.
The speed of delivering changes is set by a single scenario from branch to production environment.
Previously, a release required manual steps and approval windows; now a change goes through automated checks and deployment: a typical release fits into tens of minutes, and rolling back to the previous version takes single-digit minutes, because the artifact is already built and tested.
Service recovery time is determined not by how fast the on-call engineer is, but by how quickly the node is reproduced.
Unhealthy nodes are replaced automatically based on health checks, and data is brought up from fresh copies — the service returns to operation within minutes and without manual configuration reconstruction.
The third effect is a reduction in the class of failures caused by configuration. No manual edits remain on production servers, and divergences between environments are visible at the review stage rather than in production.
Scaling boundaries and resource limits are also described in advance, so growth in load does not turn into an outage.
Hetzner Cloud: deployment modes and when each is appropriate
A virtual machine, a physical server, and a hybrid scheme solve different tasks: the choice is determined by the load profile and the required predictability of response, not by the convenience of the control panel.
Below are the placement options in Hetzner Cloud and the boundaries beyond which an option stops being suitable.
| Option | When it fits | Limitations |
|---|---|---|
| Virtual machines, shared cores | Web services, APIs, queues, test environments | Response depends on host neighbors, peaks are not guaranteed |
| Virtual machines, dedicated cores | Databases, caches, services with steady response time | More expensive per core, lower memory ceiling than a physical server |
| Physical dedicated server | Heavy DBMS, data processing, dense disk I/O | Scaling is not instant, redundancy is designed in advance |
| Hybrid: machines in a private network with a load balancer | Production environment where the application and database are separated by role | More complex scheme, requires connectivity control and a single entry point |
Scope of responsibility: where the provider ends and we begin
The provider is responsible for the physical layer — sites, hardware, channels, network availability. Our scope is everything above that: images and their versioning, private network layout, firewall rules, access keys, snapshots, backup rotation, service roles.
If the hardware degrades, that is the provider's domain; if a service does not come up after an update, that is ours to sort out. We record the division in the regulation so that no "gray" zones remain.
How we choose the mode
We take a load profile: the number of concurrent connections, target response, seasonal peaks, sensitivity to disk writes. Then we deploy a test environment and look at actual metrics under load rather than calculated ones.
We keep the architecture portable — services in containers, configuration in the infrastructure description, state on a separate volume.
Then changing the placement option is a matter of transferring configuration rather than rebuilding the service, and rolling back to the previous scheme takes minutes.
Implementation stages: from audit to handover to operations
The work proceeds in iterations, and each stage is closed with an artifact that can be verified before moving to the next. The order is not accidental: networks and access are configured before services, because reworking boundaries after launch is the most expensive.
-
Infrastructure audit. Inventory: which nodes and volumes are in use, where certificates expire, who holds which access keys. The output is a map of the current state and a prioritized list of risks.
-
Deployment scheme. Target topology: number of nodes, role distribution, failure boundaries, what goes into the private network. We agree on this before creating resources in Hetzner Cloud — edits on the scheme are cheaper than a rebuild.
-
Configuring networks and access. Private networks, firewall rules, a bastion for administrative access, a role model. Secrets live in a vault, not in the repository; access is granted on a least-privilege basis.
-
Infrastructure as code. Resources are described declaratively, state is kept in a secured vault, changes pass review. The environment is reproduced from scratch, and manual edits in the panel are excluded.
-
Fault tolerance testing. We shut down nodes one by one, break connectivity between zones, and restore services from backups on a separate environment. We record not the fact that it "came up" but the time and number of manual actions required to reach a working state.
-
Handover to operations. We hand over access, the scheme, update and recovery regulations, and walk through them with your team. After that comes support on our side or independent management: no dependency on us remains.
What stays with you: configurations, regulations, and documentation
Infrastructure without documents quickly turns into a black box: the servers run, but bringing up a similar environment nearby, adding a node, or rolling back a change without the person who set it up is no longer possible.
That is why we hand over not "access as it happens to be" but a complete set of artifacts into your repository — with them, your team runs the project independently.
- Configuration files — declarative descriptions of servers, the private network, load balancers, the firewall, and storage volumes. The environment is brought up from them repeatably, not "by hand from memory."
- Infrastructure diagrams — connections between subnets, entry points, queues, and storages, with external dependencies and critical paths marked separately.
- Backup regulation — what is copied, at what frequency, where the copies are stored, how long they are retained, and how restoration is verified on a test environment.
- Access policies — roles, keys, separation of read and write permissions, the procedure for granting and revoking access when an employee leaves.
- Team instructions — deploying a release, rolling back to a previous version, adding a server, reading logs, typical emergency scenarios.
- Monitoring and alerts — the list of metrics, trigger thresholds, who receives a notification, and what to do for each signal.
- Handover map — the list of accounts, service accounts, and secret storage locations, indicating the owner after handover.
The handover is not "here is a folder with files": we walk through the set with your team, demonstrate bringing up the environment from scratch, and answer questions on each artifact. Describe your task — we will come back with an estimate and a handover plan.
Case study: migrating a service to the cloud and metrics before and after
Infrastructure before the work
The service ran on a single virtual machine: application, database, and queue handler on one host, deployment by hand according to instructions, backup as a nightly dump that had never been tested for restoration.
A disk failure meant 4-6 hours of downtime: they looked for the image, brought up the environment from memory, and edited configs live. Releases went out once every two weeks, because every window was preceded by manual testing on a copy of the database.
What was changed and what the result was
The infrastructure was described as code — the environment is recreated from the repository, and manual edits on servers are excluded.
We migrated to Hetzner Cloud, splitting the network: the database in a private segment, accessible only from the application, with a load balancer facing outward with health checks and automatic node replacement.
Static content was moved to object storage, and for disks we enabled snapshots and copy lifecycle rules so that old versions do not pile up indefinitely.
Recovery from a node failure shrank from 4-6 hours to 10-15 minutes, the production stand deploys in 20 minutes instead of half a day, releases moved to a daily rhythm, and rolling back to the previous image takes minutes.
Downtime during planned maintenance is a few minutes thanks to deployment without stopping the service.
We can break down a similar scenario for your service too: we will show where bottlenecks cause downtime and what a migration delivers.
How cloud virtual machines differ from a dedicated server
The difference shows up not in power but in how resources are allocated. On a dedicated server, all cores, disks, and network bandwidth belong to you entirely — there are no neighbors, so latency and throughput are predictable from request to request.
A cloud virtual machine runs on a shared physical host: resources are allocated from a pool, but the configuration can be changed without reinstalling the OS and without downtime.
| Option | When it fits | Limitations |
|---|---|---|
| Dedicated server | Constant high load, databases, isolation requirements | Expansion takes days: ordering, commissioning; hardware failure means downtime until replacement |
| Cloud virtual machines | Variable traffic, seasonal peaks, fast test environments | Host co-tenancy, limits on disk operations, dependence on the provider's site |
| Hybrid scheme | Data and heavy services on hardware, frontend and handlers in the cloud | More complex network and monitoring, requires a unified access and addressing scheme |
Scaling under load is the main dividing line. A dedicated server is scaled up discretely and slowly: by the time a new machine arrives and is configured, the peak has already passed.
Cloud virtual machines scale under load within minutes — in Hetzner Cloud a group of nodes is added based on metrics, and the extra ones are shut down when traffic subsides.
We make the choice of placement mode based on the load profile, not on habit. We look at daily and weekly peaks, the share of the constant baseline, data isolation requirements, and how painful downtime is.
If the graph is steady and hits a ceiling, we calculate dedicated hardware; if the load is bursty or quick experiments are needed, the cloud; if both fit, we assemble a hybrid and separate services by environment.
Common technical questions: access and fault tolerance
Technical doubts usually concern not the site itself but the boundaries of the work: whether migration can be done in parts, who receives access, what happens if a zone fails, and how to move back. Below are answers to the four questions most often raised in a technical meeting.
We build infrastructure on Hetzner Cloud and describe it with configuration in the repository: private networks, volume snapshots, nodes in different availability zones within a region. This is the technical foundation for fault tolerance and predictable recovery.
Can migration to the cloud be partial?
Yes, we migrate service by service. First, what benefits from the cloud moves over: the web layer, queues, background jobs; heavy databases can stay with you and be connected via a private network. Each step is rolled back separately, and full downtime is not required.
What access do your engineers receive?
Separate accounts with roles, login via SSH keys, access to the environment on demand and for the duration of the work. All changes are logged: who, when, and what was edited. After handover, we revoke personal access, leaving service accounts and your administrators.
How are backups and fault tolerance arranged?
We take volume snapshots and database exports on schedule and store copies in another region — a site failure does not affect them. Nodes live in different zones, the load balancer checks health and diverts traffic away from a failed one. Once a month we deploy a copy on a stand and make sure the service comes up with intact data.
Can we move back later, or to another site?
Yes. The configuration is described declaratively and lives in your repository, and data and images are exported using standard tools. The reverse migration follows the same plan as the forward one — no lock-in to us or to the site remains.
How to start the move to the cloud: let's discuss your task
We structure the first conversation as a breakdown of the current environment, so that the infrastructure assessment is a calculation rather than a guess.
The more specific the answers, the more precise the work plan and the fewer surprises during migration preparation — from server sizes to the order of traffic switching.
- What runs now: the list of services and environments, what is critical for the business, what we migrate in waves, and what is cheaper to rewrite.
- Load profile: peak values, seasonality, requirements for response time and availability.
- Where the data lives: databases, file storages, backups — and which of these stays in place.
- Domains, certificates, DNS zones, and external integrations: their migration produces the most sensitive failures.
- Access requirements: who gets onto the servers and how, whether a closed environment without public addresses is needed.
- What is already automated — build, deployment, configuration management — and what we describe from scratch.
- Timeline constraints and maintenance windows: when downtime is acceptable and for how long.
Based on these answers, we assemble the target infrastructure scheme on Hetzner Cloud, break the work into stages with rollback points, and record what needs to be prepared on your side. Describe your task — we will come back with an estimate, a scheme, and a plan.