Home Projects Roadmap Blog GitHub Contact
Projects / Homelab & Infrastructure / OpenClaw on Proxmox
Active Identity · Zero-trust · AI infrastructure

OpenClaw on Proxmox

Deployed a self-hosted AI gateway, exposed it through a friendly HTTPS address, and secured it with Authentik — without ever leaving the gateway directly reachable from the LAN.

ProxmoxAuthentikNginxZero-trustCodex

Objective

Deploy OpenClaw in the Proxmox environment, expose it through a friendly HTTPS address, and protect it with Authentik without leaving the OpenClaw gateway directly reachable from the LAN. Also written up as a three-part blog series.

Current status

The core deployment and security migration are complete. OpenClaw is reachable through Authentik behind a public HTTPS address. Shared gateway-token authentication has been removed in favour of trusted-proxy identity headers.

One remaining operational issue: one-time device approval for new browsers. An Android pairing request was identified, but the final approval attempt was interrupted by an OpenClaw CLI scope mismatch.

Architecture

Browser → Nginx Proxy Manager → Authentik → OpenClaw
ComponentRole
OpenClawApplication gateway (AI tooling)
AuthentikLogin, TOTP and trusted identity, hosted on Proxmox
Nginx Proxy ManagerPublic HTTPS reverse proxy, hosted on Proxmox
Public addressFriendly HTTPS domain, user-facing endpoint

Completed work

  • Deployed OpenClaw in the Proxmox environment.
  • Configured a public HTTPS route with a friendly domain name.
  • Preserved WebSocket support through the full proxy chain.
  • Added OpenClaw to Authentik's embedded outpost.
  • Corrected Authentik's browser-facing URL from HTTP to HTTPS.
  • Migrated OpenClaw from a shared gateway token to trusted-proxy authentication.
  • Restricted trusted identity to a single verified Authentik account.
  • Restricted the backend port so ordinary LAN clients can't bypass Authentik.
  • Verified that direct LAN access times out while the Authentik path stays healthy.
  • Updated the OpenClaw maintenance process so upgrades preserve the trusted-proxy setup.
  • Retained rollback copies during every proxy and authentication change.

Security decisions

  • Authentik is the single authentication boundary — nothing bypasses it.
  • OpenClaw trusts identity headers only when they come from the Authentik host.
  • The backend port is not intended for direct user access under any circumstance.
  • TOTP remains the active MFA method while Duo Push is being configured.
  • Device tokens and secrets are never stored in the documentation.

Open items and risks

  • Approve the intended Android browser without approving an unknown device.
  • Confirm whether OpenClaw requires device approval for every new browser under trusted-proxy mode.
  • Verify the maintenance job after the next OpenClaw upgrade.
  • Document a tested rollback and recovery path for Authentik or proxy outages.
  • Consider monitoring certificate expiry and gateway health.

Next actions

  1. Generate a fresh Android pairing request and keep the page open.
  2. Approve only the matching request ID using an operator-scoped OpenClaw device.
  3. Confirm the Android browser reconnects through Authentik.
  4. Test a second clean browser profile to document a repeatable onboarding process.
  5. Add a short recovery runbook for proxy, identity and gateway failures.

Related

Authentik Identity Platform Duo Push MFA Proxmox Platform Blog series: OpenClaw on Proxmox