Hetzner Cloud offers direct virtual machines with shared or dedicated resource plans, multiple locations, operating-system choices, networks, firewalls, volumes, backups, snapshots, and other provider-level features. Its server-creation flow lets customers choose type, location, image, IP configuration, SSH key, cloud-init, and name.12 AgentVM can use Hetzner as one provider behind a much narrower agent-facing control plane.3

So this is less a comparison of unrelated clouds and more a question of which layer you want to integrate: the provider directly, or an agent-specific gateway in front of it.

Direct Hetzner gives you provider-native control

Using Hetzner Cloud directly means operating inside Hetzner's projects, API, console, quotas, networking, server types, firewalls, volumes, snapshots, and billing model.12

That is the better choice when your team wants Hetzner-specific capabilities, long-lived infrastructure, custom networking, direct account ownership, or the lowest possible abstraction between your automation and the provider.

AgentVM intentionally hides the provider credential

AgentVM's managed compute path keeps the Hetzner API token on the control-plane side. The user supplies an SSH public key and selects an approved server configuration; AgentVM performs the provider operation and returns the machine lifecycle and connection data.3

This is useful for agents because the credential needed to create arbitrary resources in the provider account does not have to become part of the agent's secret set.

The SSH experience is still provider-backed

Hetzner recommends supplying an SSH key at server creation; its console documentation treats that key as the authentication mechanism for the new server.2 AgentVM follows that model while generating or accepting the user's public key and attaching it during managed provisioning.3

The difference is who performs the provider API call. With direct Hetzner, your account and automation do it. With AgentVM, the control plane does it on behalf of the bounded machine request.

MPP adds a purchasing layer Hetzner does not need to provide

AgentVM exposes a machine-payment protocol surface over selected Hetzner-backed compute resources. A compatible agent can receive a payment challenge and authorize a bounded VM without being issued the underlying Hetzner provider token.4

Hetzner's own API is designed for authenticated project owners managing cloud resources directly.1 That is the right model for normal cloud administration; AgentVM's extra layer is useful only when delegated agent purchasing and bounded resource contracts are requirements.

Choose direct provider access or an agent gateway

Choose Hetzner Cloud directly when you want provider-native control, direct billing, full feature access, and you are comfortable managing projects, credentials, lifecycle automation, and cost policy yourself.

Choose AgentVM when the agent should see a curated machine product instead of a provider account: an SSH-ready Linux server with a maximum lifetime, operator-visible state, provider abstraction, and optional MPP purchasing.