OpenClaw VPS Security Checklist for Startups on Hetzner

What is the safest way to run OpenClaw on Hetzner?

The safest startup baseline is simple: put OpenClaw on a dedicated Hetzner server, allow as little inbound access as possible, keep model keys off the repo, and force risky actions through approvals. That is enough to avoid most early-stage mistakes.

You do not need a perfect enterprise program on day one. You do need a clear boundary between your agent runtime and everything else your team cares about. OpenClaw is explicitly a self-hosted gateway that can connect multiple chat channels and agent workflows (OpenClaw docs). That flexibility is useful. It also means bad defaults spread fast if you are sloppy with access, secrets, or browser sessions.

Quick answer

If your team is about to leave OpenClaw running on Hetzner, do these things first:

1. use one VPS for OpenClaw only
2. allow SSH only, with key auth only
3. keep API keys in server-side environment files or a secret manager
4. isolate browser-heavy runs from general app workloads
5. put exec approvals in front of destructive actions
6. test backup and rollback before you need them

The rest of this article is the checklist behind those six points.

Why startup teams get this wrong

Most startup security failures are not exotic. The pattern is usually boring:

• one founder launches the agent on the same box as other tools
• secrets live in shell history or .env files checked into the wrong repo
• nobody defines who is allowed to approve risky actions
• backups exist in theory but not in a way anyone has actually restored

That is a workable demo setup. It is a bad operating model.

Hetzner gives you useful primitives, but it is still an unmanaged environment. Its firewall is stateful, and inbound traffic that does not match an allow rule is dropped (Hetzner firewall FAQ). That helps. It does not save you from poor process discipline inside the server.

1. Access hardening checklist

Use one server for one job

Do not run OpenClaw on the same machine that already hosts unrelated internal tools, staging apps, and random team scripts. A dedicated box makes incident response much simpler. If something goes wrong, you know which service boundary to inspect first.

For early teams, "dedicated" usually means one small VPS that only runs:

• the OpenClaw runtime
• its local logs
• the minimal process manager and monitoring you need

That is enough.

Lock down SSH before you do anything else

Your first server hardening pass should cover:

• one non-root admin user
• SSH key authentication only
• password login disabled
• a short allowlist of people who can reach the box
• no shared admin account

Hetzner's firewall model is allowlist-first on inbound traffic (Hetzner firewall FAQ). Use that to your advantage. If the server only needs SSH from your team IPs or VPN egress, say so explicitly.

Keep private network traffic private when you have more than one host

If you later split OpenClaw, a model gateway, and supporting services across multiple machines, use Hetzner Networks for east-west traffic rather than bouncing private service calls over the public internet. Hetzner documents Networks as private Layer 3 links between cloud servers (Hetzner Networks FAQ).

If you are still on one box, keep that note in your pocket for later. Do not overbuild too early.

2. Secret and key management checklist

Keep keys off the repo

This sounds obvious until a team is tired and trying to ship. OpenAI's own guidance is plain: do not commit API keys to source control, and do not deploy them in client-side environments; keep them in environment variables or a key management system on the server (OpenAI key safety guide).

That means:

• no live keys in sample config files
• no long-lived keys pasted into Slack
• no "temporary" secrets in GitHub Actions variables nobody rotates

Separate ownership of keys

Do not make one super-key the answer to everything. Split secrets by role where you can:

• model provider keys
• Slack or Telegram channel credentials
• gateway or routing tokens
• deployment credentials

That way a rotation on one surface does not force a weekend outage on every other surface.

Rehearse rotation before production

If your team has never rotated a key in this stack, assume the first attempt will break something. Good rotation practice includes:

1. update the secret in one place
2. restart or reload the process that consumes it
3. verify outbound calls with the new credential
4. revoke the old credential only after the new path is proven

That order saves a lot of pain.

3. Browser and approvals safety checklist

Treat browser automation as a bigger risk surface

Browser-based agent work is where many teams get overconfident. The model is not just generating text. It is acting through authenticated sessions, pages, forms, and file downloads.

If the workflow can log into tools, approve actions, or move data across tabs, the browser lane deserves tighter rules than simple API-only runs.

Put risky actions behind approvals

OpenClaw has native approvals tooling and Slack-native approval flows when Slack interactivity is enabled (OpenClaw approvals docs, OpenClaw Slack docs). Use that. Do not give broad execution rights to every inbound message and promise yourself you will "tighten it later."

At minimum, require approval for:

• shell commands that mutate files
• commands that touch production credentials
• browser actions on billing, admin, or customer systems
• any cross-system action that creates external side effects

Keep approvers small and explicit

A startup does not need a twenty-person approval matrix. It does need named owners. Good defaults are:

• one primary approver
• one backup approver
• a defined escalation path when neither is around

If nobody clearly owns approvals, the system either stalls or becomes informal. Both are bad.

4. Logging, backup, and rollback checklist

Do not confuse "we enabled backups" with "we can recover"

Hetzner's automated backups are useful, but there are sharp edges. Hetzner says backups are created daily, each server gets up to seven backup slots, and attached Volumes are not included in server backups (Hetzner backups and snapshots).

That last part matters. If your OpenClaw logs, memory artifacts, or uploaded files live on an attached Volume, your rollback story may be incomplete.

Decide what actually needs backup

For most OpenClaw setups, back up:

• runtime configuration
• approval policy files
• logs you need for audit or troubleshooting
• any persistent agent memory or workspace data you care about

Do not waste time backing up disposable caches.

Test one rollback path now

Take a snapshot. Restore from it once. Confirm:

• the service starts
• the secrets path still resolves correctly
• approvals still behave as expected
• the team knows what changed

That one rehearsal will tell you more than a month of "looks fine" optimism.

5. Startup-ready launch checklist

Use this as the final pass before you call the system production-ish:

• the server is dedicated to OpenClaw
• inbound access is restricted to SSH and only from trusted sources
• SSH passwords are disabled
• all live provider keys are server-side only
• high-risk actions require approval
• one person owns secret rotation
• one person owns incident response
• backups and one rollback path have been tested
• browser-based tasks are treated as higher-risk than plain API runs

If you cannot check most of those boxes yet, you are still in staging. That is fine. Just call it what it is.

FAQ

Is Hetzner secure enough for OpenClaw?

Yes, for many startup teams. The bigger issue is not the provider brand. It is whether you run OpenClaw with sane access controls, clean secret handling, and approvals where they matter.

Should we use a separate box for browser-based agent work?

Usually yes, once the browser lane becomes important. Browser sessions, downloads, and authenticated actions widen the blast radius compared with API-only runs.

Are Hetzner backups enough on their own?

No. They are useful, but attached Volumes are excluded from server backups, and a backup you have never restored is still an assumption (Hetzner backups and snapshots).

Conclusion

The right startup security model for OpenClaw on Hetzner is not glamorous. It is one clean server, narrow inbound access, server-side secrets, explicit approvals, and a rollback path you have already tested once.

That setup gets you out of the danger zone without turning a young team into a compliance department. If you want less operational drag, the next step is usually not more clever hardening. It is deciding whether you still want to own the whole stack yourself.

Related reading: How to run OpenClaw on a private VPS, Understanding multi-model AI gateways, Managed OpenClaw hosting.