Connect a Hostinger-Hosted OpenClaw to Sesame

Hostinger’s one-click OpenClaw runs inside a managed Docker container, which changes where every command from the main OpenClaw guide runs. This page is that guide adapted to the template, validated end-to-end on a fresh Hostinger container. Two facts about the template drive the order of operations:

All commands run in the container shell, not the VPS host shell. The host has no openclaw, no /entrypoint.sh, and nothing you install there reaches the app.
Changing any env var in the Hostinger panel recreates the container, wiping everything installed inside it. Only the /data mount survives.

Therefore: if you’re doing the optional panel change in step 2, do it before any container work — a later recreate quietly reverts the container to stock (your install and entrypoint edit are gone, and OpenClaw boots unwrapped; see the last Troubleshooting row).

This guide uses the cloud broker at getsesame.dev. Read the main OpenClaw guide first for the concepts (secrets, injection, approvals) — this page covers only what Hostinger changes.

1. Dashboard prep

You, in the browser — in getsesame.dev (Secrets → Add), add one secret per provider your agent will call, e.g. OpenAI (api.openai.com, Bearer) and Stripe (api.stripe.com, Bearer). The presets fill the injection mode. Secrets live in your Sesame account, not on the box — they survive anything Hostinger does.

2. Panel prep (optional — only if going keyless on the LLM)

This step is not required for a working setup — the full path below works with the panel env untouched. Do it only if you want OpenClaw’s stored provider key replaced with a dummy.

You, in the browser — in Hostinger’s hPanel, replace the provider key field (e.g. OPENAI_API_KEY) with sesame-managed-placeholder. This recreates the container — that’s expected. Wait for the app to come back up before continuing, and do it before any container work.

OpenClaw keeps the provider enabled as long as a value is present; on the full path the broker strips the placeholder and injects your real key on the wire.

3. Enter the container shell

Hostinger’s browser terminal drops you inside the container as root. From the VPS host shell instead: docker exec -it openclaw-<suffix>-openclaw-1 bash (find the name with docker ps). The OpenClaw chat UI is never a setup shell. Verify before anything else:

which openclaw && tail -1 /entrypoint.sh

openclaw’s path plus an exec runuser -u node -- line → you’re inside. openclaw: command not found → you’re still on the host.

Enter the shell first, then run commands. Don’t paste a block that starts with docker exec -it ... bash followed by more lines — the later lines race the shell startup and execute on the host. One command at a time until your prompt is root@<hex-id>.If you’re an agent running this onboarding: confirm the container shell with the check above, and stop and hand off to the user at every 👤 dashboard pause — the CLI commands block and wait; don’t assume they succeeded.

4. Install the Sesame CLI

As root, in the container shell:

curl -fsSL https://getsesame.dev/install.sh | sh
mkdir -p /run/user/1000 && chown node:node /run/user/1000 && chmod 700 /run/user/1000

The second line creates the per-user runtime directory the CLI expects: containers have no systemd/logind to make it, and the node user can’t create it itself (/run is root-owned) — without it, sesame login crashes with PermissionError: '/run/user/1000'. That’s the only fix a fresh template container needs. (Any other PermissionError on an older or modified container: see Troubleshooting row 1.)

5. Register as the app user

runuser -u node -- sesame login

You, in the browser: login prints a claim URL and blocks — open it, sign in to getsesame.dev, approve the device, wait for Agent approved.

Why runuser -u node --? The gateway and its exec tool run as the node user (uid 1000, HOME=/data), and Sesame reads its device identity from the home of whoever runs it — it lands in /data/.config/sesame and /data/.local/share/sesame/keys, owned by node. Register as root and the identity is invisible to the agent — it fails on first use. Create the identity as the user that will consume it.

Don’t “simplify” the runuser away — a restart won’t save you here. This template’s boot script re-chowns /data on every start, which heals ownership mistakes: OpenClaw’s own commands (openclaw models auth login, openclaw onboard) write to the fixed path /data/.openclaw/, so running them as root merely mis-owns the files and a panel restart repairs it. Sesame is different: its state path is derived from $HOME — run sesame login as root and the identity lands in /root/, a location the node-run sesame launch never reads. No restart moves files; the wrapped boot fails with “No device identity” and loops. Ownership problems heal on restart; location problems don’t.

Choose your integration path

Quick path: sesame request

The agent calls Sesame as a shell tool when told to. No proxy, no restart, nothing changed about OpenClaw. Right for trying Sesame out.

Full path: transparent egress

Every outbound call intercepted at the wire — enforced, not opt-in, and covers the LLM key too. One entrypoint edit + a restart.

Quick path: `sesame request`

No proxy needed — skip proxyd entirely. Test as the same user the agent runs as:

runuser -u node -- sesame request GET https://api.stripe.com/v1/balance

You, in the browser: the request pauses; approve it in the dashboard’s Approvals tab. The broker injects the real key server-side and the balance prints in your terminal.

Then have the agent do the same. In the OpenClaw chat:

When you need to call the Stripe API, run sesame request GET https://api.stripe.com/v1/balance in the shell — you don’t have a Stripe key; auth is handled externally. What’s my account balance?

No gateway restart at any point: the agent spawns fresh shells per command, so they see the CLI and identity immediately.

The trade-off: this mode is opt-in. The agent uses Sesame because it’s told to — nothing at the network layer forces it, and direct HTTP calls (including its LLM traffic) bypass the broker entirely. For enforcement, use the full path.

Full path: transparent egress

On a normal host this is sesame launch -- openclaw gateway run (main guide, step 5). On Hostinger you don’t type that — the template’s supervisor already starts the gateway, so the wrapper goes where the gateway is actually started: the container’s entrypoint.

Install the edge proxy

runuser -u node -- sesame proxyd install

Wrap the entrypoint

One sed, as root in the container shell:

sed -i 's|exec runuser -u node -- "\$@"|mkdir -p /run/user/1000 \&\& chown node:node /run/user/1000\nexec runuser -u node -- /usr/local/bin/sesame launch -- "$@"|' /entrypoint.sh
tail -3 /entrypoint.sh   # verify: the mkdir line + exec ... sesame launch -- "$@"

Two details are load-bearing: the mkdir is baked in because /run is a tmpfs that empties on every boot, and the absolute path /usr/local/bin/sesame is used because the boot-time PATH differs from your interactive shell’s.

Restart the app

Hostinger panel restart button, or kill 1 in the container shell, or docker restart <container> from the host — all equivalent. The gateway reboots through sesame launch: proxy env and CA are set at process birth, which is why a restart is required here and nowhere else.

The template’s boot logs always show a failed openclaw plugins install oxylabs-ai-studio-openclaw (“plugin already exists”). That error is pre-existing and harmless — it appears on every boot of the stock template and is unrelated to the entrypoint edit. What you don’t want to see is runuser: failed to execute lines (Troubleshooting, row 4).

Prove it, then set the model-host policy

Send a chat message → the model call pauses → You, in the browser: approve it at getsesame.dev. The reply arrives with your real key injected server-side. Then immediately set an auto-approve policy on your model host — model calls fire on every turn, and per-call approvals make chat unusable. Keep per-call approval on side-effecting hosts like Stripe.

The mental model: OpenClaw never learns Sesame exists. There is no fallback setting to configure — it keeps sending the same key material as before. The edge proxy intercepts the call, and the broker swaps in the real key on the wire. The provider sees a valid request; OpenClaw sees a normal response.

Verify

Registration and reachability, from the container shell:

runuser -u node -- sesame status   # expect: your agent listed, active, "Tokens: present"

To prove the full path’s env injection directly, check the gateway process’s environment — with one gotcha:

/proc/<pid>/environ is not readable via docker exec — even as root (Docker drops CAP_SYS_PTRACE, so the read fails with Permission denied). Don’t conclude the injection failed. Read it as the process’s own user, or from the VPS host:

# Inside the container, as the process's own user:
docker exec -u node <container> sh -c 'tr "\0" "\n" < /proc/<gateway-pid>/environ | grep -E "HTTPS_PROXY|NODE_EXTRA_CA_CERTS"'

# Or from the VPS host, using the host PID from `docker top <container>`:
tr '\0' '\n' < /proc/<host-pid>/environ | grep -E 'HTTPS_PROXY|NODE_EXTRA_CA_CERTS'

Both proxy and CA variables present → the gateway was born under sesame launch.

If you did the optional step 2, also confirm the panel’s env fields hold only sesame-managed-placeholder values — the real keys exist only in Sesame’s vault.

Troubleshooting

Error	Cause → Fix
`PermissionError: [Errno 13] Permission denied: '/data/.config/sesame'`	Root-owned state dirs on the data mount (not present on a fresh template) → `mkdir -p /data/.config /data/.local && chown -R node:node /data/.config /data/.local`, then retry `login`.
`FileNotFoundError: '/run/user/1000/sesame'` then `PermissionError: '/run/user/1000'`	The runtime dir from step 4 is missing — `/run` is a tmpfs, so a container restart empties it. Re-run step 4’s `mkdir`/`chown`/`chmod` line. (The full path’s entrypoint edit re-creates it automatically on every boot, so this only bites quick-path users after a restart.)
`EADDRINUSE: address already in use` when starting the gateway by hand	Never run `openclaw gateway run` or `sesame launch -- openclaw gateway run` manually — the template supervises the gateway and the port is already bound. Use the entrypoint sed + restart.
Crash loop: `runuser: failed to execute /usr/local/bin/sesame: No such file or directory`	The entrypoint edit is present but the install isn’t — in practice the paste race: the sed ran in the container while the install landed on the VPS host. (A panel recreate does not cause this — it also reverts the entrypoint, so a recreated container boots clean; see the last row.) Recover without entering the crash-looping container: install on the VPS host (`curl -fsSL https://getsesame.dev/install.sh \| sh`), then copy both pieces — `docker cp /usr/local/lib/sesame <container>:/usr/local/lib/` and `docker cp /usr/local/bin/sesame <container>:/usr/local/bin/` (that’s the symlink into the lib directory; it resolves once the directory exists) — then `docker restart <container>`. Copying only one piece keeps the loop going: the symlink alone is a dangling 1.5 kB link (“Successfully copied 1.54kB” is the tell), and the lib directory alone leaves `/usr/local/bin/sesame` missing.
`openclaw: command not found`	You’re on the VPS host shell, not in the container — see step 3.
Everything gone after a container recreate	`/data` survives (device identity and login included — no re-approval needed), but the CLI install and the entrypoint edit are gone. Redo step 4’s install line and the sed, then restart. Secrets and policies live in your Sesame account and always survive.
ChatGPT/OAuth sign-in ends at `This site can't be reached — localhost:1455`	Expected on a VPS: the OAuth flow redirects to a callback server inside the container, but your browser’s “localhost” is your own machine. The sign-in itself succeeded — copy the entire failed URL from the browser’s address bar and paste it back into the terminal prompt (it accepts the redirect URL or authorization code), then restart the app from the panel.
Crash loop: `Could not obtain valid token. Try sesame refresh or sesame login.`	The broker no longer accepts this device (typically revoked/deleted in the dashboard) and the wrapper fails closed at boot. Recover: revert the entrypoint edit (swap the `sesame launch` line back to `exec runuser -u node -- "$@"` via `docker cp` from the host), restart, then `runuser -u node -- sesame login --new` → approve the new device → re-apply the sed → restart.

Get Started

CLI Reference

Agent Skills

Connect an Agent

Security & Privacy

Integrations

Connect a Hostinger-Hosted OpenClaw to Sesame

1. Dashboard prep

2. Panel prep (optional — only if going keyless on the LLM)

3. Enter the container shell

4. Install the Sesame CLI

5. Register as the app user

Choose your integration path

Quick path: sesame request

Full path: transparent egress

Quick path: `sesame request`

Full path: transparent egress

Verify

Troubleshooting

​1. Dashboard prep

​2. Panel prep (optional — only if going keyless on the LLM)

​3. Enter the container shell

​4. Install the Sesame CLI

​5. Register as the app user

​Choose your integration path

Quick path: sesame request

Full path: transparent egress

​Quick path: sesame request

​Full path: transparent egress

​Verify

​Troubleshooting

1. Dashboard prep

2. Panel prep (optional — only if going keyless on the LLM)

3. Enter the container shell

4. Install the Sesame CLI

5. Register as the app user

Choose your integration path

Quick path: `sesame request`

Full path: transparent egress

Verify

Troubleshooting