블로그로 돌아가기

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.

작성자 Sophie Hart2026년 5월 25일4 분 읽기

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:

  1. one dedicated gateway node to start
  2. one private config and secret path
  3. one routing policy for all providers
  4. one health check and restart path
  5. 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

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

계속 읽기

같은 에이전트, 인프라, 배포 주제에서 이어서 볼 만한 글입니다.