Running OpenClaw
in Production

Executive Summary

OpenClaw is a self-hosted AI agent platform for people who want their agents, data, credentials, and workflow state on infrastructure they control. The appeal is straightforward: less SaaS lock-in, more customization, and a platform that can use real tools instead of living inside a narrow chatbot box.

The production challenge is equally straightforward. OpenClaw can operate browsers, files, shells, channels, APIs, and long-running workflows. Current OpenClaw documentation frames that as a trusted-operator system: powerful when isolated and supervised, risky when treated like a hostile multi-tenant SaaS platform.

ManagedOpenClaw exists for teams that want a private, dedicated OpenClaw deployment without taking on every deployment, security, backup, update, and cost-control responsibility themselves. We deploy one trust boundary per client, keep remote access conservative, pin and verify releases, and build workflows that use expensive models only when the task calls for them.

Why OpenClaw

Hosted agent platforms are convenient. You sign up, connect a model, add a channel, and start iterating. The tradeoff is that your agent lives inside somebody else's platform economics and security boundary. Pricing can change, integration limits can appear, and data governance depends on a vendor's posture rather than your own.

OpenClaw gives you the other side of that tradeoff. It is open-source, self-hosted, and designed for flexible tool use. Your deployment can run in a client-owned account, a project account we administer, or another agreed environment. The important difference is that the workflow, data, credentials, and operating notes are visible and portable instead of trapped inside a hosted bot builder.

That control is most valuable when the agent touches client data, proprietary processes, internal documents, regulated workflows, or operational systems that you would not casually push through a generic SaaS account.

The Production Gap

A developer install and a production deployment are different things. A developer install optimizes for fast local iteration. A production deployment must define a trust boundary, protect credentials, survive upgrades, recover from mistakes, and keep operating costs predictable.

• Trust boundary. OpenClaw should be treated as a trusted personal or business assistant inside a boundary you control, not as a public multi-tenant service.
• Remote access. The gateway should stay loopback-first whenever possible, with access through SSH, Tailscale, Caddy, or another intentional ingress path.
• Secrets. API keys and OAuth credentials need owner-only permissions, a clear rotation plan, and migration toward OpenClaw SecretRefs where supported.
• Updates. OpenClaw moves quickly. Production systems need pinned versions, release review, pre-update backups, health checks, and a rollback path.
• Costs. Model pricing varies dramatically. A well-designed workflow routes cheap tasks to cheap models and saves premium reasoning for steps where it matters.

Security Baseline

ManagedOpenClaw starts with the assumption that each deployment should be isolated. A client gets a dedicated VPS, a dedicated domain or subdomain, separate credentials, and an access model designed around the specific use case. The baseline includes:

• SSH key-only administration. Password login and direct root login are disabled. Administrative access is granted through named keys that can be revoked.
• Minimal inbound ports. Firewall rules allow only the ingress paths required for SSH, TLS certificate issuance, and the intended user-facing endpoint.
• Gateway authentication preserved. Current OpenClaw requires gateway authentication by default. Managed deployments keep that posture and use long random tokens.
• Allowed origins and proxy rules. Public or semi-public access paths are paired with explicit origins and trusted proxy settings only where needed.
• Container exposure review. Docker port bindings are reviewed so containers do not accidentally expose internal services beyond the intended ingress path.
• Backups before risk. Configuration, memory, sessions, workspace data, and deployment notes are backed up before updates or risky changes.

No serious operator should promise absolute safety for any internet-connected system. The honest goal is smaller attack surface, clear ownership, fast recovery, and controls that fit the data and tools the agent can touch.

Remote Access

OpenClaw's remote-access guidance is conservative for good reason: when an agent can operate tools and read state, the gateway is not just a web app. ManagedOpenClaw uses the least exposed access pattern that still works for the client:

• Local or admin-only use: keep the gateway loopback-only and access it through SSH forwarding or a private network.
• Team use: use a controlled HTTPS ingress, authenticated gateway, explicit origins, and documented user/device access.
• Public-facing workflows: separate the user-facing channel from the operator gateway wherever possible, so customers interact through the agent channel rather than the control surface.

Secrets

OpenClaw supports plaintext configuration in developer contexts, but current documentation recommends SecretRefs for reducing local blast radius where supported. A production deployment should make credential handling visible and boring:

• store provider API keys and OAuth tokens only where the deployment needs them;
• use owner-only file permissions for local secrets;
• record which credentials exist, who owns them, and how to rotate them;
• migrate supported credentials to SecretRefs and run openclaw secrets audit --check as part of operational review.

Infrastructure

Most OpenClaw deployments do not need an expensive server. The right starting point depends on channels, workspace size, concurrency, file processing, browser automation, and whether local models or only API-hosted models are being used.

We currently treat Hetzner, DigitalOcean, AWS Lightsail, and Oracle Cloud as practical starting options. Hetzner is often cost-effective. DigitalOcean and Lightsail are easier for teams that value mainstream dashboards and account administration. Oracle Always Free can be compelling, but capacity availability and idle-resource reclamation make it a poor foundation for every production promise.

Ongoing Operations

Deployment is not the end of the work. A production agent needs a routine:

• Release tracking. Watch OpenClaw releases, pin known-good versions, and avoid surprise upgrades.
• Pre-update backup. Snapshot config and data before changes so rollback is realistic.
• Health checks. Verify gateway availability, disk space, logs, backups, and model-provider connectivity.
• Security checks. Run openclaw security audit --deep, remote-access review, and secrets audits where available.
• Cost checks. Review provider dashboards and set alert thresholds for model spend spikes.
• Restore tests. Backups only matter if they restore. Managed plans include periodic restore verification.

Cost Model

ManagedOpenClaw has two practical cost buckets: the service fee for deployment, implementation, and care, plus the underlying cloud and model usage required to run the agent. The billing path is scoped per engagement. Many deployments run in our Hetzner account because that is operationally simple; client-owned accounts are available when procurement, compliance, or offboarding needs make that preferable.

Current Reference Costs

Model Price Reality

Provider prices now span a wide range. As of this update, Gemini 2.5 Flash-Lite is priced far below premium reasoning models, Gemini 2.5 Flash sits in the middle for fast general work, Claude Sonnet/Opus and GPT-5-class models cost materially more, and output tokens usually cost more than input tokens. That means workflow design matters as much as vendor selection.

Our default pattern is to classify tasks by risk and reasoning depth: cheap model for extraction, routing, summaries, and repetitive replies; stronger model for tool planning, high-stakes reasoning, sensitive customer responses, or steps where mistakes are expensive.

Service Fees

• Managed Deployment: $199 one-time for the infrastructure and OpenClaw production baseline.
• Template Agents: $499 one-time for a tailored workflow built from a proven pattern.
• Custom Workflows: from $1,200 for bespoke tools, integrations, prompts, and implementation.
• Managed care: from $49/mo for support, with Ops + Security and Custom Care options for ongoing operations.

These public provider numbers are useful for sizing expectations, not a promise about the final billing flow. The proposal or written agreement controls whether provider charges are paid directly by the client, included in a managed hosting arrangement, or handled another way.

DIY Developer Install vs. ManagedOpenClaw

Control and Portability

ManagedOpenClaw is not a multi-tenant SaaS platform. Each client gets a dedicated deployment boundary. The hosting account can be ours, yours, or another agreed environment, but the important deliverables are portable: the agent configuration, workflow decisions, custom prompts, documentation, and project handoff.

If you stop working with us, the system should not disappear behind a mystery platform. Depending on where it is hosted, continued operation may require migration, account transfer, or a new support arrangement. The OpenClaw software remains open-source, and the deployment notes explain how the system is configured.

For Agencies

Marketing agencies, consultants, and implementation shops often want to sell AI agent outcomes without building an internal DevOps practice. ManagedOpenClaw supports that pattern with isolated client deployments, documented handoff, and recurring care options.

The important architecture decision is isolation. Each agency client should have its own deployment boundary, subdomain, credentials, backups, and operational notes. That keeps client data separate and makes incident response, billing, and offboarding cleaner.

Sources and Current References

This white paper was updated using public provider documentation and pricing pages available in early June 2026. Provider prices can change; verify them before quoting a client proposal.

• OpenClaw v2026.6.1 release
• OpenClaw gateway security, remote access, and secrets documentation
• Hetzner cloud price adjustment
• DigitalOcean Droplet pricing
• AWS Lightsail bundle pricing
• Oracle Cloud Always Free resources
• Google Gemini API pricing
• Anthropic Claude pricing
• OpenAI model comparison and API pricing
• Tailwind CSS Play CDN guidance

Conclusion

OpenClaw is a strong choice when control, customization, and data locality matter. It is not a magic shortcut around production operations. The teams that get the most out of it treat the agent as a powerful trusted operator, isolate it carefully, watch costs, and maintain the boring operational systems around it.

ManagedOpenClaw handles that layer so businesses can focus on what the agent actually does: answer customers, search internal knowledge, support operations, draft work, move data, and save human time without giving up control of the system.