September 20, 2026
Hetzner Cloud Console walkthrough for .NET developers: project, API token, firewall, and what to do during a Hetzner outage
The Hetzner Cloud Console is where a Hetzner Cloud Server actually gets created and where its API token comes from — worth a five-minute tour even though DotDeployer handles almost everything on top of it afterward.
Projects
Everything in the Cloud Console lives inside a project — a container for servers, networks, firewalls, and API tokens, with its own billing line. A personal account might have exactly one project; a team might split dev and production into separate projects so a token scoped to one can’t touch the other. DotDeployer connects to a single project at a time via its API token, so if you run more than one project, each needs its own DotDeployer provider connection.
Creating the API token
Security → API Tokens → Generate API Token, inside the project you want DotDeployer to manage. Give it Read & Write permission (DotDeployer needs to create and destroy servers, not just list them) and copy the token immediately — Hetzner shows it exactly once. This is the token you paste into DotDeployer’s Settings → Providers → Hetzner screen; see Connect Hetzner for the full click-by-click version, and the Hetzner tutorial for a walkthrough with screenshots.
Servers
The Servers tab lists every Cloud Server in the project, with its type, location, and IP. Once DotDeployer provisions a server, it shows up here too — the console is a legitimate way to double-check a server’s status, look at its graphs (CPU, network, disk), or open its Console tab for an in-browser VNC session if SSH is somehow unreachable. DotDeployer never needs you to touch this tab day to day, but it’s there when you want to look at the box directly instead of through DotDeployer’s own UI.
Firewalls
Hetzner’s Firewalls tab manages rules at the cloud network layer, before traffic even reaches
the server’s own ufw rules — a second layer, not a replacement. DotDeployer’s own server
bootstrap configures ufw for 22/80/443 on the box itself; a Hetzner-level firewall is optional
extra hardening for anyone who wants the block enforced before it reaches the server at all, most
relevant for the database-port-to-one-IP case covered in
the SQL Server on Linux article.
What to do during a Hetzner outage
status.hetzner.com is Hetzner’s public status page — it lists active incidents by affected product and datacenter location, scheduled maintenance windows, and a subscribe option for email alerts on specific products. Check it first before assuming your own app is the problem; a Hetzner-side incident affecting Cloud Servers or networking in your server’s location explains a sudden outage far more often than anything in your own deploy.
If an outage is confirmed and ongoing, there’s genuinely little to do on the server itself — restarting a service that can’t reach the network because the network is down doesn’t help. What actually matters is knowing quickly: DotDeployer’s health checks catch a server that’s stopped responding and its notification/alerting surfaces that to you (in-app and by email) instead of you finding out from a customer report. Once Hetzner resolves the incident, DotDeployer’s own rollback and restart tooling gets the app back to a known-good state without you having to SSH in and guess what state things were left in.
One API token, then DotDeployer takes it from here
Connect your Hetzner account once, and DotDeployer provisions the server, deploys your ASP.NET Core or Blazor app from GitHub, and alerts you the moment a health check fails.