Source: https://crabglamp.com/docs/plain-vms/explanation/isolation-and-logging
Last updated: 2026-06-11
Type: explanation

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.).