How to rotate a Hetzner Cloud API token

Open the project in Hetzner Console, generate a second API token with the same permission as the old one, switch your tools to it, check a request, and then delete the old token. The two tokens work in parallel while you switch, so servers and pipelines keep running. Tokens are bound to the project they were created in, so the replacement must come from the same project (Hetzner docs). Hetzner's documentation doesn't say how quickly a deleted token stops working, so the last step includes checking for yourself.

Crunu doesn't generate or delete Hetzner tokens, and it has no Hetzner integration. It finds which Hetzner values a departing person could read, keeps the new token as a new version of the environment, and passes it to the tools that manage your project.

A token is a key to a whole project

A Hetzner Cloud token has very few settings, which is exactly why its reach is wide:

• Project. Each token belongs to one project and works only there. Hetzner advises creating a separate token for each project. Since the token alone decides which project a request runs in, a mix-up between two tokens means changes land in the wrong project.
• Permission. There are two levels (generating a token). Read allows only GET requests. Read & Write allows GET, DELETE, PUT and POST, so it can change or delete anything the API manages in that project.
• No expiry and no second look. The documentation describes no expiry setting, and once you close the window after creating a token, you can't view it again.

With no finer scopes available, your main controls are the project boundary and the number of tokens. Keep production in its own project, give each tool its own token, and use Read for anything that only watches, such as monitoring. A departure or a leak then touches one token in one project.

Reissue without downtime

crunu run --env data-pipeline/production -- sh -c \
  'curl -s https://api.hetzner.cloud/v1/servers -H "Authorization: Bearer $HETZNER_CLOUD_TOKEN"'

The token travels in the Authorization: Bearer header, as in Hetzner's own examples. Running the request through crunu run keeps the value out of your shell history. Keeping one Crunu environment per Hetzner project mirrors the token boundary: the production token never sits next to the token of a staging project, people get access to each separately, and a reissue touches exactly one environment.

When to reissue a Hetzner token

• A departure. Reissue every Read & Write token the person could read, starting with production projects, and end their access to Hetzner Console. In Crunu, removing the person produces a reissue checklist of the values they received, by name.
• A leak. Delete the leaked token first and accept that its tools stop, then generate and deploy the replacement. A Read & Write token can delete servers and volumes, so a short outage is the cheaper side of the trade. Afterwards, check the project for resources you don't recognize.
• A schedule. Since nothing in Hetzner's documentation makes a token expire, nothing forces a reissue. Set your own interval, and use each round to delete tokens nothing uses.

What to rotate when a developer leaves covers the order for a full departure, including access to the servers themselves, and the offboarding checklist builds the list for your stack. Creating and deleting tokens is done in Hetzner Console (deleting a token); Crunu holds the new value and the record of when it changed.