How to Set Up AI Agents on Hetzner

Updated May 2026
To run an AI agent on Hetzner, create a shared vCPU Ubuntu server in Hetzner Cloud, add your SSH key, harden it with a firewall and a non-root user, install your runtime, deploy your agent with its API key as an environment variable, and run it as a systemd service with backups enabled. Hetzner gives you the most memory and CPU per dollar of any mainstream host.

Hetzner is the value champion of agent hosting. Its shared vCPU plans pack more memory and processing power into each dollar than almost any rival, which makes it the natural choice for anyone watching costs. The control panel is clean, servers spin up in seconds, and the same machine that costs a few dollars a month can run one agent or several. This guide takes you from a new account to a running, self-healing agent.

Step 1: Create a Hetzner Cloud Account and Project

Sign up for Hetzner Cloud, which is the part of Hetzner built for on-demand virtual servers, and create a new project to hold your agent's resources. Projects keep your servers, keys, and firewalls organized, which is helpful once you run more than one thing. With the project open you are ready to add the pieces your agent needs.

Step 2: Add Your SSH Key

Add your SSH public key to the project so it can be installed on new servers automatically. Key-based login is more secure than a password and lets you connect without typing one each time. If you do not have a key pair yet, generate one on your own computer and keep the private half safe, since it is what authenticates you to the server.

Step 3: Create a Server

Create a new server using a current Ubuntu image and a shared vCPU plan, which offers the best value and ample power for an API-driven agent. Choose a location close to your model provider and data sources to keep the agent loop responsive, and select the SSH key you added so you can log in right away. The smallest shared plan is a fine starting point and can be resized later if needed.

Step 4: Connect and Harden

Connect to the server over SSH and update its packages to a current state. Then spend a few minutes on security: enable a firewall that allows only SSH and any port your agent truly needs, and create a non-root user for daily work instead of operating as root. Hetzner also offers a cloud firewall you can configure in the panel, which adds a second layer in front of the server. These steps make the machine reasonably safe before any code goes on it.

Step 5: Install Your Runtime and Dependencies

Install the language runtime your agent uses along with its libraries and any tools it calls. Keep the install lean and focused on what the agent needs so the server stays simple to maintain. As on any host, packaging the agent in a container is a solid alternative that bundles the runtime with the code and makes the setup easy to reproduce elsewhere.

Step 6: Deploy the Agent and Set Secrets

Upload your agent code to the server and provide its configuration through environment variables rather than writing secrets into the code. Store the model API key and any other credentials this way, scoped to the least privilege the agent requires. Keeping keys out of your codebase protects you if the code is ever backed up, copied, or shared.

Step 7: Run the Agent as a Service

Register the agent with systemd so the system manages it as a background service. A short definition starts the agent on boot and restarts it if it crashes, so it keeps running through reboots and transient failures without you having to step in. This converts a manual script into a dependable worker that looks after itself.

Step 8: Enable Backups

Turn on Hetzner's automated backups or take periodic snapshots so a recent copy of the server exists if hardware fails or something goes wrong. The cost is small relative to the value of not losing your agent's state and configuration. With backups in place and the agent running as a service, you have a setup that is both cheap and genuinely reliable.

Key Takeaway

A small shared vCPU Hetzner server, hardened and running your agent as a systemd service with backups on, delivers the best value reliable hosting you can get for an AI agent.

Getting the Most From Hetzner's Value

Hetzner's low prices mean you can afford more headroom than you might on a pricier host, so it is worth choosing a plan with a little extra memory if your agent runs a browser or processes documents, since the cost difference is small. The same value also makes consolidation attractive: a single modestly sized Hetzner server can comfortably run several agents plus a database and a queue, which is cheaper and simpler than spreading the work across many tiny machines elsewhere.

If you later outgrow a shared vCPU plan, Hetzner offers dedicated vCPU instances and full dedicated servers that continue the same value story at higher tiers, so you can scale up without leaving the provider. That smooth ladder, from a few-dollar shared server to a powerful dedicated machine, is part of why Hetzner is such a frequent recommendation for cost-conscious builders who still want room to grow.

Hetzner Cloud Versus Hetzner Dedicated

Hetzner sells two distinct products, and knowing the difference helps you pick the right starting point. Hetzner Cloud offers on-demand virtual servers that you create and destroy in seconds, billed by the hour up to a monthly cap, which is ideal for an agent because you can start tiny and resize freely. Hetzner also rents full dedicated servers and auction machines, which are physical computers with far more power for steady, heavy workloads, billed monthly and provisioned in a longer setup window.

For a first agent, Hetzner Cloud is almost always the right choice. It is flexible, cheap, and quick, and a small cloud server handles an API-driven agent with ease. The dedicated and auction machines become attractive later, when you are running many agents or a genuinely heavy pipeline and want maximum hardware per dollar. Because both live under the same account, moving from a cloud server to a dedicated machine as you scale is straightforward, letting you begin with the simplest option and graduate only when your workload clearly calls for it.

Locations, Backups, and Snapshots

Hetzner operates data centers in several locations across Europe and the United States, and choosing one near your model provider and your users keeps the agent loop fast. The selection is simple at server-creation time, and for most agents any well-connected location works, so pick the closest to where your traffic and model calls originate. If data residency matters for your workload, the location choice is also where you satisfy it.

For protecting your work, Hetzner gives you two complementary tools. Backups are automated periodic copies of the whole server that you enable for a small percentage of the server cost, ideal for set-and-forget protection. Snapshots are manual point-in-time images you take before a risky change, so you can roll back if something goes wrong, and they double as a way to clone a configured server onto a new machine. Using backups for ongoing safety and snapshots around major changes gives you a dependable safety net at very little cost, which fits the value-minded spirit of hosting on Hetzner in the first place.

Networking and Firewalls on Hetzner

Hetzner Cloud gives you networking tools that add security and flexibility at no extra cost, and they are worth using from the start. The cloud firewall is configured in the control panel and sits in front of your server, letting you allow only the traffic you intend, typically SSH from your own address and whatever single port your agent might need. Because it lives outside the server itself, it protects the machine even before the operating system firewall comes into play, giving you two layers with very little effort.

For setups with more than one server, private networks let your machines talk to each other over an internal connection that is not exposed to the public internet. This is useful once you separate, say, an agent from a database it relies on, since the two can communicate privately while only the pieces that must be reachable face outward. Keeping internal traffic on a private network is both safer and, on platforms that charge for public transfer, cheaper. Even if you start with a single server, knowing these tools are there means you can grow into a small multi-server setup securely without changing providers or rethinking your whole approach.