A few days ago I shared how OpenClaw has been helping me — it can truly take over the programmer role, freeing me from the grind of development tasks so I can think about project decisions, product design, and where the company is heading. I can finally act like a CEO of a one-person company, doing more of what a manager should do. That’s been a huge level-up for me.

But when I was about to ship a project the other day, I realized it still can’t replace me when it comes to DevOps:

1. Extremely high complexity: DevOps work is far more complex than programming. You’re operating command lines, logging into servers to check things, and you need to be incredibly careful — one mistake can have massive consequences.

2. Multi-dimensional interaction: You need to open various web UIs to manage cloud resources, copy-paste critical keys, deploy services, and operate cloud platform dashboards.

3. Constant context switching: You’re jumping between the terminal and web UIs, constantly verifying and handling edge cases. These operations go beyond what plain text can express.

While OpenClaw can already replace the programmer, no agent can truly handle DevOps yet. I think there’s a huge opportunity here. Maybe it’s time to build a real, autonomous DevOps Agent.

A Real Deployment Story

To show what DevOps difficulties actually look like, let me walk through my recent experience deploying Vocalflow — a voice input and transcription service I built.

First, I created a project on my self-hosted Dokploy instance and set up the app inside it. Then I manually clicked through the configuration to set the Docker image path pointing to GitHub’s container registry. Since the image is private, I had to dig up a GitHub PAT and paste it in.

Next, I wrote GitHub Actions for building the image — this was the one thing I had OpenClaw help with. Then I added another Action: once the image build completes, it calls the deployment platform’s API via curl to trigger auto-deployment. Since this step requires token authentication, I had to open the GitHub Actions settings page and add the Secret Value.

After all that, I pushed the code. The auto-deployment kicked in, but the app failed to start. I checked and found that better-sqlite3 couldn’t find its native Node extension. I had OpenClaw debug and search for a while:

1. First it tried switching the image base from Alpine to Debian Slim — didn’t help.
2. After several fruitless searches, I manually went to the project’s Issues and searched for “Alpine,” finally finding a relevant thread about Docker startup problems. https://github.com/WiseLibs/better-sqlite3/issues/146
3. In there I found a reply about pnpm workspaces — turns out pnpm was blocking better-sqlite3’s post-install build step, and you need to add an “approve-builds” config.

Once I told OpenClaw, it added the file and pushed again. The project finally came alive.

Then came domain configuration. I had to go to the Cloudflare Dashboard, find my top-level domain, add a subdomain, and point it to the deployment server. After that, I went back to Dokploy to map the new domain to the service and configure automatic HTTPS via Let’s Encrypt. I also needed to get the port right — I asked OpenClaw which port the service was actually running on. Only then was everything set up. I then checked Docker’s runtime logs to verify whether auto-migration ran correctly. It didn’t. I notified OpenClaw to look into it, but since it couldn’t directly access the production logs, verifying the fix was hard. I went back and forth debugging several times. Once that was sorted, I started a new session and had it research and write a CLI tool for fetching Dokploy service logs — just to make life easier next time. https://github.com/reorx/scripts/blob/master/dokploy-logs

The Future of the DevOps Agent

This is what DevOps work looks like — extremely tedious, fragmented, and unpredictable. There’s no universal approach to standardize it. Especially in the early stages of a project, entropy is incredibly high. Only after a project stabilizes can you start managing things through standardized text-based tools like Ansible or Terraform, forming SOPs.

In an era where development moves this fast and everyone is constantly building new projects, general-purpose Coding LLMs trained on existing data do have DevOps knowledge, but they can’t truly do the job. They can’t close the loop the way they can with development work. That’s the reality, and it’s the direction I believe future agents need to explore.

The core ideas behind such an agent:

• Not another DevOps platform: Don’t try to build yet another IaaS or ops platform.
• Adapt to the real world: The agent should adapt to real-world DevOps workflows, learning and mastering various skills — like operating AWS, Dokploy, or Cloudflare infrastructure.
• Pluggable architecture: The agent should be pluggable, like a person who can work at any company in any role. It can be installed into any system — whether that’s OpenClaw, Claude Code, or Cursor.

This would complete the last missing piece, freeing developers and small companies from DevOps busywork and closing the entire loop from idea → development → launch.