Working on Hetzner: Cloud Servers, Account Security, Billing and Traffic Allowances

Hetzner is known for very competitive pricing on cloud and dedicated servers, and for the strict account verification that comes with it. This guide covers the products, the security settings worth enabling in the Cloud Console, how billing and traffic allowances work, and the SMTP policy. For a first server setup with firewalls and snapshots, see our Hetzner Cloud getting-started guide, and for the sign-up checks, see Hetzner account verification explained.

What you can build on Hetzner #

Developers use Hetzner for inexpensive isolated environments; businesses run production web workloads and self-hosted tools; server hosting and web hosting are the classic use cases, with Arm servers popular for price-to-performance.

Securing a Hetzner account #

1. Enable two-factor authentication on the account and on any additional Cloud Console users.
2. Use SSH keys for server access and add them at server creation so password login is never enabled.
3. Attach Hetzner Firewalls to servers and allow only the ports you need; restrict SSH to known addresses where practical.
4. Invite team members to a project with appropriate roles instead of sharing credentials.
5. Review account activity and API tokens regularly, and give each token the narrowest permissions.

Management essentials #

• Projects in the Cloud Console separate environments or clients, each with its own members and API tokens.
• Labels on servers and volumes help with filtering and cost review.
• Backups and snapshots: automated backups cost a percentage of the server price; snapshots are billed by size. Test a restore.
• API and CLI: the Hetzner Cloud API and hcloud CLI cover everything the console does, and a Terraform provider is available.

How Hetzner billing works #

• Hourly billing capped at the monthly price. If you delete a cloud server before the end of the billing month you pay only the hourly rate; otherwise the bill never exceeds the monthly cap.
• Existing means billed. A server is billed while it exists, even if it is powered off. Delete servers you do not need.
• No minimum contract for cloud servers.
• Traffic allowances: cloud servers include a monthly traffic allowance that varies by location and plan. At the time of writing, servers in EU locations include a large allowance (20 TB for CPX plans), while Singapore and US locations include less (from 0.5 TB to 5 TB depending on plan). Additional traffic is billed per terabyte.
• Add-ons: backups, snapshots, floating IPs and extra IPv6 addresses have their own pricing.
• Promotional credit: new accounts may receive a small trial credit under Hetzner’s current terms; verify current promotions on Hetzner’s site.

Cost habits: delete rather than power off, pick a location whose traffic allowance fits your workload, watch snapshot storage, and review the invoice monthly.

Email from a Hetzner server: the port policy #

Hetzner blocks outbound ports 25 and 465 by default on all cloud servers. After the first month and payment of the first invoice, you can submit a request with a justification to have them unblocked. Port 587 is not blocked, so an external SMTP relay or transactional email service that supports submission on 587 works from day one. Our guide to SMTP port 25 on cloud servers compares this with other providers.

Cloud Console and Robot #

Hetzner runs two interfaces: the Cloud Console for cloud servers, volumes, networks, firewalls and load balancers, and Robot for dedicated servers, Storage Boxes and their rescue and reinstall tools. Both sit under the same customer account and invoice, but permissions, API tokens and project structure are managed separately, so document which team members need access to which.

How teams use Hetzner #

Developers use cloud servers for inexpensive isolated environments and self-hosted tools such as Git servers and CI runners. Startups run production web workloads on dedicated vCPU servers behind a Load Balancer, with volumes for data and Storage Boxes for backups. Server hosting is the classic use case: game servers, mail relays (once port access is granted), and containers on Arm servers for price-to-performance. Web hosting customers run control panels on cloud or dedicated servers. Agencies have clients own their accounts and invite the agency to a project, which keeps billing and ownership with the client and makes hand-over a membership change.

A first-week checklist #

1. Complete verification honestly and enable two-factor authentication.
2. Create a project per environment or client and add SSH keys to it.
3. Create a Firewall allowing only the ports the application needs and attach it at server creation.
4. Pick the location whose traffic allowance fits your workload.
5. Enable backups or schedule snapshots for stateful servers, and test a restore.
6. Plan email sending through port 587 or an API provider until an unblock is granted.
7. Review the first invoice against the usage page.

Official references #

The Hetzner documentation covers cloud servers, billing, traffic and the email port policy. Our Hetzner platform overview summarizes the platform and how to sign up officially.

Frequently asked questions #

Can I send email from my Hetzner server?

Ports 25 and 465 are blocked by default; port 587 is open, so an authenticated relay works immediately. After a month and a paid invoice you can request an unblock with justification.

How do I manage my Hetzner account?

Through the Cloud Console for cloud products and Robot for dedicated servers, or the API and hcloud CLI for automation.

Is a powered-off server free?

No. Billing continues while the server exists. Delete it to stop charges.