Live Vanta integration is live
Home
OpenClaw environment variables

OpenClaw env guide

OpenClaw Environment Variables: Setup, Secrets, and Best Practices

Use this as the durable reference for setting up OpenClaw env files, keeping secrets out of unsafe places, and giving your team a repeatable workflow.

Start free View the OpenClaw integration

On this page

OpenClaw still depends on ordinary environment configuration: keys, URLs, ports, tokens, feature flags, and credentials that need to exist before the app or container starts. The hard part is not knowing that these values exist. The hard part is keeping them correct across local development, CI, staging, and production without leaking secrets or letting files drift.

This guide covers the practical setup choices that matter most: how to structure an OpenClaw env file, where secrets become risky, how teams should handle local and deploy workflows, and where Ghostable fits.

What OpenClaw environment variables are

OpenClaw environment variables are runtime configuration values that control how OpenClaw connects to services, authenticates requests, stores data, and enables optional behavior. They usually include values such as app URLs, database credentials, API keys, queue settings, object storage details, and integration tokens.

Treat env keys as a contract. Key names should stay consistent across environments; values should change per environment. Pair this with clear naming from the ENV variable naming conventions guide so developers and automation can understand the same file.

A practical .env setup for OpenClaw

The safest setup has two parts: a committed template that documents expected keys, and an uncommitted runtime env file that contains real values.

# .env.openclaw.example
OPENCLAW_APP_URL=https://openclaw.example.com
OPENCLAW_DATABASE_URL=<database-url>
OPENCLAW_REDIS_URL=<redis-url>
OPENCLAW_STORAGE_BUCKET=<bucket-name>
OPENCLAW_API_KEY=<api-key>
OPENCLAW_WEBHOOK_SECRET=<webhook-secret>

Keep the template useful but non-sensitive. The real env file can be generated by Ghostable before OpenClaw starts, written to the path your Docker Compose file or host service already reads, and treated as disposable runtime output. For a step-by-step setup walkthrough, read How to Set Up OpenClaw Environment Variables. For template structure, the same principles from the .env.example guide apply here.

For a deeper walkthrough of file structure, paths, and example values, read the OpenClaw .env file guide.

Where OpenClaw secrets get risky

Secrets usually leak through workflow shortcuts, not because someone set out to be careless. Watch for these patterns:

  • Copying a real .env into a committed example file.
  • Sharing OpenClaw tokens in chat, tickets, docs, or screenshots.
  • Reusing one production value in local, staging, and CI.
  • Letting generated env files become a second source of truth.
  • Giving every developer access to every environment by default.

The fix is boring on purpose: keep secrets out of Git, scope access by environment, rotate values when they are exposed, and make the generated OpenClaw env file replaceable. For a deeper guide to access, rotation, and source-of-truth workflows, read OpenClaw Secrets Management. For a security checklist, read OpenClaw Environment Variables Security.

Local, dev, and team workflows

A single-person OpenClaw install can survive with a hand-edited env file. A team cannot. The workflow needs to answer who changed a value, which environment it changed in, and how OpenClaw picked it up.

Local development

Developers should pull only the development values they need, then write them into a local OpenClaw env file. Local secrets should be easy to refresh and easy to delete.

ghostable env pull --env development --file .env.openclaw

CI and deploys

CI and production runners should use scoped deployment tokens, not a developer account. Generate the env file immediately before startup so OpenClaw receives current values without long-lived files floating around.

ghostable env deploy --token $GHOSTABLE_CI_TOKEN --file .env.openclaw
docker compose --env-file .env.openclaw up -d

Production operations

For production, keep changes reviewable and auditable. If a secret rotates, update the value in one source of truth, regenerate the OpenClaw env file during deploy, and avoid manual edits on the host.

How Ghostable helps OpenClaw teams

Ghostable gives OpenClaw teams a managed place for environment values, permissions, history, and deployment output. The OpenClaw integration is intentionally env-file native: it does not require OpenClaw to know about Ghostable. Ghostable writes the file OpenClaw already expects.

  • Source of truth: store values once instead of maintaining scattered copies.
  • Scoped access: separate development, staging, and production permissions.
  • Deployment tokens: let automation read only the values it needs.
  • Audit history: understand who changed a value and when.
  • Disposable output: regenerate OpenClaw env files instead of hand-editing them.

For the product-specific setup, see the Ghostable + OpenClaw integration page.

FAQ

Where should OpenClaw environment variables live?

Use the environment file or host-level configuration OpenClaw reads at startup, but keep the source of truth in a managed system instead of passing raw .env files around.

Should OpenClaw secrets be committed to Git?

No. Commit templates and documentation only. Real API keys, passwords, tokens, and signing secrets should stay out of Git, tickets, chat, and screenshots.

How does Ghostable fit into an OpenClaw workflow?

Ghostable stores environment values in a shared workspace, tracks changes, controls access, and can write the runtime env file OpenClaw already expects before startup.