Leaving AWS for Hetzner: What Actually Changes

Decide whether you want to own the operations

Your AWS bill can pay for managed operations as well as compute, while your engineering hours go into configuring the surrounding infrastructure. Moving to Hetzner can reduce infrastructure spending, but running the replacement database yourself creates recurring work. We recommend the move for a portable application with predictable demand and someone explicitly responsible for recovery.

The strongest candidate is an application you already understand well enough to rebuild from source and restore from backup. Start with Ubuntu 24.04 LTS on a single VPS if the business can tolerate the outage required to replace that server. If nobody can handle an incident while the main maintainer is unavailable, solve that staffing problem before moving more responsibility onto your team.

Compare against the AWS setup you actually operate. Moving a self-managed application and database from an EC2 instance changes less than replacing a managed database and redundant application deployment with a single machine. Our comparison of VPS, cloud and dedicated hosting helps separate the hosting model from the provider name.

Map the services your application actually depends on

Before choosing a server, trace a request from the public endpoint through every service it touches. Repeat that exercise for background jobs and deployments. A portable application binary does not make the surrounding system portable.

Keeping a useful managed service is a valid outcome. Retaining object storage may be straightforward, while keeping a database across providers can put network latency on every query. Verify connectivity and transfer costs before accepting that split, and avoid making a previously private database publicly reachable just to finish the migration.

Record the exact behavior you need from anything you replace. A scheduled script does not automatically reproduce queue retries, and copying environment variables does not reproduce workload identity. Mark every dependency as move, retain or redesign, with a named owner for anything in the last category.

Compare the complete bill with the complete workload

Compare your current recurring bill with a destination that includes the supporting services you will actually use. Include off-server backups and external monitoring, then account for transfer charges on services that remain elsewhere. Check whether existing AWS commitments continue after the workloads leave.

• Recurring infrastructure: the VPS and any additional storage, plus managed services you retain.
• Migration overhead: overlapping environments and data transfer, including another transfer if rehearsal fails.
• Routine labor: operating system maintenance and database administration, with time reserved for recovery drills.
• Incident exposure: the business cost of waiting for someone to diagnose and rebuild a failed server.

Use your application's resource history to choose the initial machine. Leave room for backup activity and temporary disk growth during a deployment, then verify behavior under representative traffic. A smaller infrastructure bill is not useful if ordinary maintenance repeatedly exhausts the server.

Read the Hetzner review when evaluating the provider itself. Make the migration decision separately, based on the work your team is accepting. Provider selection cannot resolve an application architecture that depends heavily on services you have no replacement for.

Build an operating baseline before copying production data

Create the Ubuntu 24.04 LTS destination from a documented configuration. Use a dedicated deployment account and keep database listeners private. Establish an update routine with a maintenance window for changes that require restarting the machine.

Configure the provider firewall deliberately, allowing administrative access before restricting inbound traffic. Hetzner documents default inbound blocking and default outbound allowance when no rules are configured in its Cloud Firewall overview. Check the rules attached to the actual server, then verify access from outside it.

Make process startup and deployment repeatable, including what happens after a reboot. Run availability monitoring outside the VPS so a dead machine can still generate an alert. Follow the minimum monitoring setup for a small server fleet before sending production traffic to the destination.

We recommend Claude Code for bounded operational work such as reviewing configuration changes and investigating redacted logs. Give it narrowly scoped access, and require explicit approval before production mutations or database promotion. The production guardrails for AI agents should be in place before the agent receives credentials; assistance does not replace an incident owner.

Choose the recovery capability you will maintain

Write down how long the application may be unavailable and how much recent data the business can afford to lose. Those requirements determine whether a single VPS is acceptable and what backup method you need. A backup file alone does not tell you how long recovery will take.

Amazon RDS provides automated backup and restore facilities, although you still need to configure them and understand their behavior. Moving PostgreSQL onto your VPS makes you responsible for replacing the capabilities you rely on, including point-in-time recovery if required. Review the RDS backup and restore documentation against your current configuration before deciding what can disappear.

Provider snapshots are useful recovery aids, but they are not a complete database backup design. Hetzner states that server backups and snapshots exclude attached Volumes in its backup and snapshot documentation. If your database lives on an attached Volume, taking a server snapshot does not capture those database files.

Keep recoverable database backups outside the application server, with credentials that limit what a compromised application can delete. Restore into an isolated environment and open the application against the restored data. Use the Postgres backup and restore drill procedure to turn that requirement into a repeatable task.

A single VPS puts the application and any local database in the same failure domain. Backups help you recover after failure; they do not keep requests running during it. If your recovery window cannot accommodate rebuilding the machine, retain a suitable managed setup or design redundancy before migrating.

Rehearse the move with an isolated copy

Deploy the application to the destination using the same artifact you intend to run in production. Load a protected copy of the required data, with outgoing email and payment actions disabled. Keep scheduled jobs and queue consumers stopped so the rehearsal cannot process production work.

For PostgreSQL, choose a migration method based on the maintenance window you can tolerate. A dump and restore is relatively easy to reason about when that window covers the full transfer, while replication requires a separate synchronization and promotion plan. The PostgreSQL pg_dump documentation explains that a dump is consistent during concurrent use, but it does not continuously capture subsequent changes or include cluster-wide roles.

Check required extensions and recreate application roles with the intended privileges. Exercise a representative authenticated workflow that writes data, then reads it back after an application restart. Verify uploaded files separately if they live outside PostgreSQL.

Record how long the full rehearsal takes, including validation before opening traffic. Verify outbound integrations from the new server because destination allowlists and source addresses can change. If the rehearsal exceeds your acceptable outage, change the migration method before scheduling production.

Cut over with a single writable source of truth

For a maintenance-window migration, reduce relevant DNS cache lifetimes early enough for existing entries to expire. Put the old application into maintenance mode and stop every writer, including background consumers. Decide how incoming webhooks will be retained or retried while writes are unavailable.

Create the final database export after writes have stopped, then restore it to the destination. Synchronize any mutable files that live outside the database and repeat the rehearsed validation. Keep public writes disabled until the destination passes those checks.

Switch the public endpoint and enable writers only at the destination. Keep the old endpoint in maintenance mode or make it forward to the new application, because cached DNS can still send traffic there. Start destination consumers only after confirming their old counterparts remain stopped.

Before new writes begin, rollback can mean reopening the unchanged source. After the destination accepts writes, switching DNS back to the old database would abandon those changes. Your rollback plan must then stop writes again and reconcile the authoritative data, or repair the destination while it remains authoritative.

Create the migration decision record before provisioning

Open a migration ticket for a well-understood application and fill in the decisions below. Use the current bill and deployment configuration as evidence. Leave unknowns visible, with an owner responsible for resolving each one.

• Scope: which components move, which remain managed, and which require application changes.
• Recovery: the acceptable outage and data loss, plus the person responsible for restoring service.
• Economics: the expected recurring obligations and temporary migration overhead, including engineering time.
• Acceptance: the workflows the rehearsal must pass and the condition that cancels the cutover.
• Rollback: the action before destination writes begin and the data reconciliation process afterward.
• Retirement: when the old resources can be removed and what evidence must be preserved first.

Provision the rehearsal VPS once that record supports a clear decision. Authorize production cutover only after the rehearsal meets the stated recovery and application requirements. After cutover, confirm destination backups can be restored before retiring the source, then review remaining AWS resources and billing obligations so abandoned infrastructure does not continue consuming the savings.