How to Configure a Managed LLM Gateway on Hetzner
A practical guide to configuring a managed-style LLM gateway on Hetzner with provider routing, health checks, private networking, and clearer operating boundaries.
How do you run a managed-style LLM gateway on Hetzner?
Run the gateway on a dedicated Hetzner host, keep provider routing in one place, put supporting services on private networking when the stack grows, and make the gateway the single layer that owns model access for the rest of OpenClaw. That gives you the feel of a managed control plane while still using infrastructure you control.
Hetzner gives you the basic building blocks for that model: cloud servers, private Networks, Load Balancers, and backups (Hetzner server overview, Networks overview, Load Balancers overview).
Quick answer
The shortest reliable pattern is:
- one dedicated gateway node to start
- one private config and secret path
- one routing policy for all providers
- one health check and restart path
- one plan to add a second node when the gateway becomes critical
Do not spread model access logic across every app and channel first. Centralize it early.
What “managed” means here
In this context, managed does not mean "the provider runs everything for you." It means the rest of your stack treats the gateway as the control layer for:
- provider selection
- fallback
- key ownership
- logging
- cost policy
That separation is what makes the system easier to operate.
Step 1: Use a dedicated host
Do not run the gateway as a side process on a random mixed-use machine.
Give it:
- one dedicated Hetzner server
- one clear OS baseline
- one clear restart path
- one clear backup path
This is the same deployment discipline OpenClaw recommends more broadly for Linux server setups (OpenClaw Linux server docs).
Step 2: Keep routing policy centralized
The gateway should decide:
- which provider is primary
- which provider is fallback
- which workloads have cost ceilings
- which requests should fail closed
The application layer should not need to know all of that. If it does, you have not really built a gateway. You have built a provider sprawl problem.
Step 3: Use private networking as the stack grows
Once you split components across more than one node, move internal traffic onto Hetzner Networks instead of bouncing it over public addresses (Hetzner Networks overview).
That keeps:
- gateway-to-supporting-service traffic private
- topology cleaner
- future scaling less awkward
Step 4: Add health checks and an honest restart path
A managed-style gateway needs a boring operational baseline:
- one health endpoint
- one process manager
- one documented restart command
- one way to tell if the provider path is unhealthy even when the process is alive
Health checks catch node failure. They do not automatically catch provider misrouting.
Step 5: Keep keys and config out of repo sprawl
Store provider keys and gateway secrets server-side. Do not duplicate them across personal machines or half-forgotten config files. The gateway is supposed to simplify model access, not make key management harder.
If you later move to a more formal secret manager, the gateway should still be the only part of the runtime that needs to care.
When to add a second node
Stay on one node while:
- traffic is light
- the runtime is still evolving
- you are still learning the failure modes
Add a second node when:
- the gateway becomes production-critical
- more than one team depends on it
- maintenance windows start feeling risky
That is usually the point where you also consider a Hetzner Load Balancer in front of the nodes (Load Balancers overview).
FAQ
Can one gateway serve multiple OpenClaw workflows?
Yes. That is one of the main reasons to centralize it.
Should I start with a load balancer?
Not necessarily. One clean node is fine at first. Add the balancer when the gateway becomes an important shared dependency.
Is this different from a general reverse proxy?
Yes. A reverse proxy moves traffic. A managed-style LLM gateway also owns provider policy, fallback, and key handling.
Sources and notes
- Hetzner server overview
- Hetzner Networks overview
- Hetzner Load Balancers overview
- OpenClaw Linux server docs
- OpenClaw gateway protocol
Related reading: How to Configure Multi-Model Gateway Failover on Hetzner, Understanding Multi-Model AI Gateways, Pricing.
AI クラウドをデプロイする準備はできましたか?
専用の AI インフラストラクチャを 3 分で起動できます。複雑なセットアップは不要です。
Not sure which path fits your deployment? Talk to us
関連記事
同じエージェント、インフラ、デプロイ領域の続きの記事です。