If 2026 ends up being the year AI agents stop being mostly demos and start becoming real operator tooling, OpenClaw deserves to be in that conversation.I do not mean that in a buzzword sense.
I mean it in a practical, engineering sense: OpenClaw is trying to collapse messaging, tools, automation, memory, and day-to-day operator workflows into a single usable system.NVIDIA has already started moving in a similar direction with NemoClaw, and Jensen Huang (CEO of NVIDIA) even went as far as saying that: “OpenClaw is the number one, most popular open-source project in the history of humanity.” If you want the source for that line, here is the video.Still, this post is not about hype.
It is about practice.More specifically, it is about how I set up OpenClaw for my own use, what went smoothly, what went less smoothly, and what I learned over roughly the last month of using it in a remote-first configuration rather than the simpler single-machine model.By “remote-first,” I mean the assistant runs entirely on a remote host and is accessed over the network, rather than sharing a machine with the user.
Why I did not want the default local model
Running OpenClaw locally is straightforward.But I did not want an assistant that only existed on whichever machine happened to be open in front of me.
I wanted something I could reach from anywhere, with strong access control in front of it, and with a clean enough isolation boundary that I would not have to pretend the host and the assistant runtime were the same trust zone.That decision sounds simple.
In practice, it changes the shape of the whole deployment, because a lot of modern AI tooling still quietly assumes a local-first setup.
Why I used my home lab instead of a VPS
First of all, this deployment reflects a more pragmatic choice: I already have a home lab.So for me, using existing hardware was simply more cost-effective than spinning up a VPS and paying every month to have an "isolated machine" just for my assistant.
If the compute, storage, and network footprint already exist in infrastructure I control, then reusing that footprint is the rational option.But cost was only part of the decision.A home-lab deployment also gave me a few properties that mattered for this kind of system:
more direct control over the host, network, and isolation model
easier experimentation with runtime boundaries and forwarding paths
no need to adapt the design to a generic VPS provider image or policy set
a cleaner place to connect the system to other self-hosted tools and services later
There is also a broader reason I think this use case matters.
Not everyone wants an operational AI system running on rented third-party infrastructure by default.Some individual practitioners already have capable self-hosted environments, so a VPS is not the obvious economic choice.
And in some enterprise contexts, the objection is not cost at all — it is governance.Depending on the environment, teams may care about things like:
where conversational and operational data transits
whether internal tooling should sit on externally rented infrastructure
how tightly the host can be integrated with existing network controls
what level of control they retain over isolation, logging, and exposure
That does not make VPS is a bad choice.
For many people, it is the fastest and simplest path.
But it is not the only serious path, and in some environments it may not even be a possible choice.That is part of why I think this deployment is worth documenting.
It shows what OpenClaw looks like when you treat it less like a disposable app and more like a piece of operational infrastructure you want to place deliberately.
The deployment: Docker Compose, persistent state, and a shared workspace
I am running OpenClaw in Docker, and the core structure is presented in the Compose file below.
version: "3.9"
services:
openclaw:
image: ${OPENCLAW_IMAGE:-ghcr.io/openclaw/openclaw:latest}
container_name: openclaw
environment:
HOME: /home/node
TERM: xterm-256color
# Required (recommended to set)
OPENCLAW_GATEWAY_TOKEN: ${OPENCLAW_GATEWAY_TOKEN}
# Optional
OPENCLAW_ALLOW_INSECURE_PRIVATE_WS: ${OPENCLAW_ALLOW_INSECURE_PRIVATE_WS:-}
CLAUDE_AI_SESSION_KEY: ${CLAUDE_AI_SESSION_KEY:-}
CLAUDE_WEB_SESSION_KEY: ${CLAUDE_WEB_SESSION_KEY:-}
CLAUDE_WEB_COOKIE: ${CLAUDE_WEB_COOKIE:-}
volumes:
- openclaw-data:/home/node
- openclaw-shared:/mnt/shared
# Sandbox isolation (optional) - only enable if you know you want allow OpenClaw to control the local Docker engine
# - /var/run/docker.sock:/var/run/docker.sock
init: true
restart: unless-stopped
command:
[
"node",
"dist/index.js",
"gateway",
"--bind",
"${OPENCLAW_GATEWAY_BIND:-lan}",
"--port",
"18789"
]
# No published ports: access via Cloudflare Tunnel only
networks:
- openclaw_net
healthcheck:
test:
[
"CMD",
"node",
"-e",
"const http=require('http');const req=http.get('http://127.0.0.1:18789/healthz',r=>process.exit(r.statusCode===200?0:1));req.on('error',()=>process.exit(1));"
]
interval: 30s
timeout: 5s
retries: 10
start_period: 60s
cloudflared:
image: cloudflare/cloudflared:latest
container_name: openclaw-cloudflare-tunnel
# Easiest: share the gateway network namespace and point ingress to 127.0.0.1:18789
network_mode: "service:openclaw"
depends_on:
- openclaw
command: tunnel --no-autoupdate run --token ${CLOUDFLARE_TUNNEL_TOKEN} --no-tls-verify
restart: unless-stopped
networks:
openclaw_net:
driver: bridge
internal: false
attachable: false
volumes:
openclaw-data:
external: true
openclaw-shared:
external: true
There are two design choices here that matter a lot.
openclaw-data: persist the assistant
The openclaw-data volume is what keeps OpenClaw from becoming disposable every time the container is recreated.Mounted at /home/node, it persists the assistant’s working state across restarts and image updates. In practice, that means the workspace, local notes, memory files, config-related state, and other user-space data survive even if the container itself does not.That persistence matters because OpenClaw is not just a stateless web service.
It is much closer to an operational environment.
If you want continuity, durable memory, editable workspace files, and an agent that can accumulate context over time, you need durable storage under its home directory.
openclaw-shared: a bridge between the assistant and my own files
The second volume, openclaw-shared, is equally important for a different reason.I use it as a direct shared area between OpenClaw and me.
That is where I can mount or expose files that I want us to work on together rather than treating the assistant as a sealed appliance.In my case, this works cleanly because I use a NAS.
That means the same underlying storage can be mounted both in the OpenClaw environment and on my local machine, so the “shared” part is literal rather than conceptual.
If someone is wondering how the assistant and I can both work against the same files from different places, that is the answer.For me, the clearest example is Obsidian.
That shared mount lets OpenClaw and me collaborate on knowledge management in a very literal sense:
draft and refine notes
organize research material
maintain paper lists
connect the assistant’s memory and my own knowledge base more directly
This is one of the reasons the home-lab model works so well for this use case
It makes the assistant feel less like a remote chatbot endpoint and more like a real participant in a working environment.
Securely exposing OpenClaw
The easiest part of this whole setup was putting OpenClaw behind Cloudflare Tunnel and Cloudflare Access.
That combination gave me most of what I wanted immediately:
remote access from anywhere
no need to expose a raw service port directly to the internet
identity-aware authentication in front of the application
a cleaner security posture than just publishing a dashboard and hoping for the best
In other words, secure exposure was not the hard problem.
Cloudflare solved that part elegantly.
Why I like this deployment
There is nothing exotic about this deployment, and that is a good thing.What I like about it is that it is explicit about the parts that actually matter:
OpenClaw runs in a contained runtime
state is persisted by design
shared data is mounted deliberately
no service port is published directly
Cloudflare handles external exposure instead of raw host publishing
health is checked locally from inside the service boundary
That gives a solid operational baseline.
Onboarding with openclaw onboard
OpenClaw uses the onboard command to perform the initial system setup.Rather than configuring each part manually, this command handles the main pieces of configuration in one place. That typically includes:
selecting and configuring a model provider (API keys or auth)
initializing the workspace and local state
configuring the Gateway (bind address, port, authentication)
optionally enabling channels such as Telegram or others
In a simple local setup, this is usually done once through the interactive CLI:
openclaw onboard
The command prompts for the required inputs and writes the resulting configuration locally (typically under ~/.openclaw/), so that the runtime can start with everything in place.
Why I used the interactive flow
Although OpenClaw supports a non-interactive mode, I ended up using the interactive onboarding process.The main reason was authentication.
OAuth-based authentication cannot be fully preconfigured through environment variables in the same way as API keys, so using the wizard is the most straightforward approach in that case.I specifically wanted the ChatGPT OAuth path because that usage is covered by my ChatGPT subscription.
Using a direct API key would have meant treating the setup as separately billed infrastructure, which was not what I wanted.That flow is inherently interactive. During onboarding, OpenClaw opens a browser-based login flow and expects a callback URL to be copied back into the CLI to complete authentication.This is also the officially supported path for Codex subscription access:
openclaw onboard --auth-choice openai-codex
The setup was straightforward:
copy the URL OpenClaw provides
open it in my local browser
complete the sign-in flow
copy the callback URL back into OpenClaw
Once that was done, the OpenAI OAuth setup succeeded, and the runtime was able to use openai-codex/gpt-5.4 through OAuth-backed access.
Channel setup
Different channels can be configured directly during onboarding.
I've chosen Telegram and Discord as channels.The setup itself is straightforward and documented here (so I will not repeat it here). The important part is that messaging becomes part of the initial configuration rather than something added later.Once configured:
messages sent via Telegram are handled as inputs to the assistant
responses are routed back through the same channel
the system can be interacted with without using the web interface
In a remote-first setup, this provides a lightweight way to interact with the system without opening a full authenticated session each time.A brief note on WhatsApp.You may also see references to WhatsApp integrations. Unlike Telegram, which provides a stable and well-supported bot API, WhatsApp has stricter rules around automation. Some integrations rely on unofficial methods. In those cases, accounts can be flagged or banned for violating the platform’s terms of service.Using the official WhatsApp Business API avoids that issue, but it introduces additional setup complexity and operational constraints. For my use case, Telegram was the simpler and more predictable option.
Hidden issue after onboarding: the tool profile trap
This was one point of friction during the setup.In my deployment, the gateway was not functioning as a simple messaging relay sitting in front of some other richer execution environment.
It was effectively the operational runtime.
There was no separately deployed CLI-side container handling the heavier execution path.That meant the running instance itself needed to do real work:
execute commands
access files
browse the web
handle configuration tasks
generally behave like an actual operational agent rather than a glorified chat surface
By default, the active tool profile behaved more like a messaging-oriented profile.
That probably makes sense in more classic split deployments.
In this setup, though, it made the system look strangely incomplete.The fix was to manually switch the tool profile to full in the raw configuration view.
The Agents panel simply didn't work for this specific change.
The controls looked like they should have been sufficient, but the only consistently effective path I found was editing the raw configuration directly.
After reloading the configuration, everything worked like a charm.
Operating OpenClaw: where it becomes genuinely useful
Once the remote-first plumbing was working, the part that started to matter most was not the deployment diagram itself.
It was the day-to-day operational experience.
That is where OpenClaw stopped feeling like an interesting setup exercise and started feeling like something I could actually use.The key word here is skill.Skill is a reusable operating procedure for the agent: a packaged workflow that can include instructions, conventions, references, and task-specific context so the assistant handles a recurring job in a more consistent way.In other words, instead of re-explaining the same process every time, you teach the system how you want a certain class of work to be done and let that pattern persist.
That can be something small and practical, like formatting or drafting rules, or something more operational, like how a recurring research or writing workflow should run.That matters because it turns the system from a generic assistant into something that can be shaped around your own operating habits.
The skills I have been using most
What made the setup click for me was the combination of a persistent workspace and a few practical skills that map well to how I already work.The most useful ones so far have been the ones tied to research work, writing workflows, plus routine operational support.
In practice, that means things like:
working with my Obsidian knowledge base through the shared mount
drafting and refining notes or post ideas in place rather than copying content back and forth
using focused skills for recurring workflows instead of re-explaining the same task every time
keeping lightweight local memory and operational context inside the OpenClaw workspace
That is where the system starts to compound value. Instead of redoing work, it begins to reuse structure.
I could gradually shape it around repeatable workflows and let those workflows persist.
Cron jobs made the system feel more like infrastructure
Another part that made a real difference was cron.This is where OpenClaw started feeling less like something I "used when prompted" and more like something that could quietly keep part of my workflow alive in the background.
Once scheduled jobs are in place, the system stops being purely reactive.
It begins to behave more like operational infrastructure.That matters because a lot of the useful work is not interactive.
Some tasks need to happen on time, some need to happen repeatedly, and some are simply the kind of maintenance work that is too easy to forget if everything depends on manual prompting.In my case, that included recurring briefs, verification jobs, and a more high-impact research workflow.
A good example is the cron job tied to high-impact paper processing. When a paper is important enough to trigger deeper handling, the automation pushes it into a follow-up path where spider.js expands the citation neighborhood and feeds telemetry back into my VIP watchlist curation workflow. A single interesting paper becomes a broader signal about which authors, labs, or research clusters may deserve more attention over time.
What I like about this is that it is not just automation in the sense of running a script on a timer. It builds continuity into the system. A scheduled job can notice, verify, enrich, and feed results back into the wider workflow without requiring manual intervention at each step.The combination of persistent state, shared files, and scheduled tasks changes the nature of the system. It starts to behave less like a demo and more like a small control plane for personal workflows.
Key takeaways from this deployment
The first thing I would say is that the setup was easier than the topology made it look.The architecture reads like a layered system: remote host, container boundary, tunnel, identity layer, and an agent runtime behind it. That can sound like a lot.In practice, it is just a composition of well-understood components. Each layer has a clear responsibility, and none of them behave in surprising ways.The system is not complicated so much as it is explicit.
Once each piece is understood, the overall setup becomes predictable rather than complex.The second thing I would say is that model choice matters more than I expected.Before settling on OpenAI through Codex, I spent about a week trying Google Gemini because I had seen good comments about it and expected it to be inexpensive. I thought the usage would land somewhere around 5 USD per month for my workflow.
Instead, it ended up costing me €37.94, and for my specific workflow, the quality did not justify that result.Luckily, OpenAI had just released openai-codex/gpt-5.4, and that changed the equation quite a bit.
For this setup, it was clearly a better fit in both quality and cost predictability.
It has felt stronger in practice, and it also made the overall experience much more compelling for the way I would like to use OpenClaw.If someone asked what I would recommend today, my answer would be simple: use GPT-5.4 through Codex.That is probably the most honest summary I can give.
Once the deployment model was understood clearly, OpenClaw itself was not especially difficult to get running or to adapt.
And after the rough edges were handled, I have had a genuinely positive experience using it.That positive experience is why I think the project is worth paying attention to.
Not because every edge case is already abstracted away, but because even in a slightly unusual setup, it was still practical enough to become useful quickly.
Closing thoughts
The interesting part of this setup was figuring out how to make a remote-first OpenClaw deployment stay secure, stay usable, and remain operationally honest when so much of the surrounding ecosystem still quietly assumes that everything lives on one laptop.That is an additional reason why I think tools like OpenClaw matter.
They can force real engineering questions back into the conversation.Now I also want to push this setup further in a few directions.One area I am particularly interested in exploring further is multi-agent architecture. Running a single assistant is useful, but the more interesting model is a system of specialized agents cooperating across clearly defined boundaries.In practice, that means deploying multiple MCP servers in my cluster, each handling a specific class of tasks rather than relying on a single general-purpose runtime.Another direction is treating AI-generated code and skills as first-class artifacts. Instead of leaving them inside the assistant’s internal workspace, I want them versioned and reviewed like any other piece of code.Integrating this with my GitLab setup would allow a more collaborative model: the agent can generate and modify artifacts, but I can step in, edit, review, and shape them directly. The goal is not to sit passively in front of the system, but to actively cooperate with it through shared, versioned state.Those directions point toward a broader shift: from interacting with an assistant to operating a system.I also plan to spend more time testing NemoClaw to better understand what it is trying to be in practice. That comparison will likely become more interesting as the ecosystem evolves.On top of that, I plan to integrate more control and monitoring into my OpenClaw pod using an open-source EDR stack. That will likely deserve its own write-up once I have something concrete.And those questions only become more relevant as agents move from demos to infrastructure.That transition is already happening.
