Every Plain VM runs on its own dedicated Hetzner server. The platform's only presence is during provisioning and during lifecycle changes — once the VM is up, the platform does not have a back door into the OS.
The isolation boundary
- Compute — one Hetzner server per Plain VM. No shared CPU, no shared RAM, no shared disk.
- Network — public IPv4 plus IPv6. A per-VM Hetzner Cloud Firewall sits at the edge; only explicitly listed inbound rules pass. Default is TCP/22 only.
- Filesystem — entirely on the VM's local disk. No shared volume with other VMs or with the platform.
- Cloud-init — the platform writes a one-shot cloud-init document at provisioning that sets the hostname, attaches Vault SSH keys, optionally sets a one-time password on the image's default user, and exits. Nothing else runs from the platform side.
What the platform logs
- Lifecycle events — destroying or transferring a VM records an immutable audit event that persists after the VM is gone. (Provisioning is recorded as a timestamp on the VM rather than an audit event.)
- Plain VM usage — tracked as per-day usage records. Stopped time bills the same as running because Hetzner charges either way.
- Firewall rule changes — applied directly to the Hetzner firewall via
PUT /api/plain-vms/[id]/firewall. The current ruleset is visible in the dashboard's Firewall section; the platform does not record per-edit lifecycle snapshots at v1 (the change history lives in Hetzner Cloud Console).
What the platform does not log
- SSH session contents. The platform has no SSH session inspection. Whatever you do in the SSH shell is between you and the VM.
- In-VM file activity. There is no agent running inside the VM at v1.
- Outbound network traffic. The VM can reach the open internet; the platform does not inspect that traffic.
Vault key attribution
The Vault stores public keys per account. When a VM is provisioned with one or more Vault keys, those keys are written into the VM at boot. Deleting a Vault key from your account does not remove it from VMs that already received it — there is no v1 mechanism to push key changes onto a live VM. To revoke access on a running VM, SSH in and edit ~/.ssh/authorized_keys directly.
What is not done at v1
- Customer-supplied disk encryption keys. Hetzner volume encryption uses Hetzner's keys.
- Network egress policy. There is no v1 mechanism for egress allowlists per VM.
- In-VM observability. No platform-installed agent; if you want metrics, install your own (Prometheus node_exporter, Datadog, etc.).