Building OpenClaw on a Hetzner VPS Without Turning It Into a Toy Demo

This was not an infrastructure project for the sake of infrastructure. The real motivation was to reduce the drag between having an idea and actually moving it into execution. Too many useful ideas die in the gap between intent and implementation, especially when the work becomes repetitive, operational, or boring.

OpenClaw felt promising because it offered a different working model. Instead of doing every step manually, the goal was to create a system that could keep momentum alive, take on implementation-heavy tasks, and let the human operate more like a manager: set direction, review outputs, course-correct, and move on.

That framing matters because it changes the evaluation criteria. The question is not whether the assistant feels impressive in a demo. The question is whether it becomes dependable enough to reduce procrastination and increase execution speed in real work.

The stack was chosen more for practicality than purity. Hetzner provided an inexpensive VPS with enough control to make the environment feel owned rather than rented. Ubuntu kept the server base predictable. Caddy simplified the secure web layer. Squarespace was already managing the domain. Telegram added a lightweight path for interacting with the system without having to stay inside one browser tab all day.

None of those tools are especially exotic on their own. The value came from how they fit together: infrastructure, access, domain routing, browser approval, and remote messaging all reinforcing the same assistant workflow.

• Hetzner for the VPS
• Ubuntu for the server base
• OpenClaw as the execution runtime
• Caddy for public HTTPS access
• Squarespace DNS for routing
• Telegram for remote interaction

Once the server existed, the setup path was surprisingly linear. Provision the machine, get SSH access, install OpenClaw, complete authentication, use the TUI onboarding flow, let Caddy expose the service behind a controlled endpoint, wire the DNS, and then approve trusted browser sessions.

That sounds obvious when written as a sentence. In practice, the difference between a loose checklist and a working system is whether the chain stays intact. This setup worked because each step unlocked the next one without forcing a major detour.

• Hetzner account and Ubuntu VPS creation
• SSH and root login flow
• OpenClaw installation and authentication
• TUI onboarding and Caddy-backed exposure
• DNS record changes for the subdomain
• Gateway token handling and browser approval
• Multi-device access and Telegram link-up

ssh root@<server-host>
apt update && apt upgrade -y

npm install -g openclaw
openclaw
# provider auth + onboarding handled inside the TUI

# choose secure public exposure during onboarding
# point assistant subdomain to the server in DNS
# let Caddy handle HTTPS and routing

The most satisfying part was how straightforward server access turned out to be. Once the VPS was available and SSH access was working, the setup stopped feeling abstract and started feeling like real progress. That matters because momentum is fragile in early setup work.

OpenClaw also benefited from having a path to public access that did not require building the entire web serving stack by hand. The onboarding flow plus Caddy did a lot of work in collapsing what could have become a much more annoying deployment process.

A      <assistant-subdomain>      -> <server-ip>
# browser access then rides through Caddy once the service is exposed

# browser opens trusted endpoint
# access token stored locally
# terminal used again to approve trusted browser request IDs

# after browser access is stable
# connect Telegram so the assistant is reachable outside the main browser workflow

The annoying parts were not particularly glamorous, which is exactly why they matter. Hetzner's KYC and document flow added friction up front. That is understandable from a safety and fraud-prevention perspective, but it still introduces a real tradeoff between trust, anonymity, and setup speed.

The stranger issue was operational: `npm install` for OpenClaw kept failing and hanging for a while, then later completed successfully without a dramatic intervention. It was not a conceptual blocker, but it was the kind of problem that can kill momentum if the rest of the setup is already mentally expensive.

That is worth documenting because polished retrospectives often delete the small annoyances that shape the real experience. Here, the work was very doable, but it was not perfectly frictionless.

npm install -g openclaw
# ... hangs / fails intermittently ...
# retry later
npm install -g openclaw

A      <assistant-subdomain>      -> <server-ip>
# trusted browser access only
# no public article should advertise the live endpoint directly

A lot of AI tooling feels exciting for an hour and then collapses into novelty. The difference here was reachability. Once OpenClaw was running on a real server, available through trusted browser access, and connected to Telegram, it stopped feeling like an experiment parked on a laptop.

That shift from demo to utility is the real threshold. A system becomes valuable when it can be reached reliably, trusted enough to use repeatedly, and integrated into the way work already happens.

Personally, this unlocked a more useful relationship to execution. The value was not just technical ownership of a server-hosted assistant. It was the reduction in activation energy. Once the system existed, it became easier to start, delegate, review, and continue instead of stalling before the first meaningful step.

For the future workflow, it proves that the human does not need to be the bottleneck for every implementation detail. The more scalable role is to hold the vision, define the task, inspect results, and intervene where judgment matters most. If the assistant layer is reliable enough, that working style compounds over time in a way manual solo execution usually does not.

What made the setup feel real was not the install alone, but the artifacts it produced: a trusted assistant workflow, a stable server-side runtime, browser access that could be approved intentionally, and a messaging layer that made the system reachable outside the original terminal.

Those artifacts matter more than any one screenshot because they are what turned the setup from a demo into infrastructure that could immediately support the next project.

• A running assistant on owned infrastructure
• Trusted browser access instead of a local-only experiment
• Telegram as a practical remote interface
• A working base layer for future publishing, planning, and delegation