Ben Niehaus recently shared something that caught my attention: "I was thinking about making a tutorial on how to install Open Claw on a VPS and make it at least a bit secure. Well there is a YouTube video for it. Complete with all cmds how to run, and of course using tailscale." He added, "Not technical at all, but this is the way. Oh Btw it is fun to watch too."

I like this kind of post because it is honest about what most people actually need: a straightforward path to getting something running, plus a baseline security posture that keeps you out of obvious trouble. Not everyone wants a 40-page hardening guide. But almost everyone hosting anything on a public VPS needs a minimum set of safeguards.

This article expands on Ben’s point. If you want to run Open Claw (or any self-hosted app) on a VPS, you can keep it simple, but you should also be deliberate about what "at least a bit secure" means.

Key idea from Ben Niehaus: keep the setup approachable, but use a private network layer (like Tailscale) so you are not exposing admin ports to the whole internet.

Why "a bit secure" matters on a VPS

A VPS is on the public internet by default. The moment you attach a public IP, you should assume:

Your IP will be scanned automatically, often within minutes
Weak SSH setups will be brute-forced
Newly exposed web services will be probed for default passwords and known vulnerabilities

So the goal is not perfection. The goal is reducing exposure and tightening access so that a basic mistake does not become a full compromise.

The core pattern Ben points to: private access first

Ben’s mention of Tailscale is the quiet hero of the whole approach.

Tailscale (built on WireGuard) lets you create a private network between your laptop and the VPS. Instead of opening an admin UI or an API port to the world, you connect over the tailnet and treat the VPS like it is on your local network.

Why this is a big deal

When you rely on private access:

You can keep most ports closed on the public firewall
You can avoid exposing Open Claw directly while you are still configuring it
You reduce the risk of random scanners finding your service

This is the difference between "internet-facing by default" and "private by default, public only when needed."

A practical blueprint for installing Open Claw on a VPS (safely)

Ben linked to a YouTube video that includes the commands to run. Even if you follow that step-by-step, here is the security-oriented structure I recommend wrapping around any tutorial.

1) Start with a clean server and a non-root user

Before installing anything:

Update packages (OS security patches first)
Create a non-root user for administration
Use sudo rather than logging in as root

This reduces the blast radius of mistakes and helps you keep cleaner audit trails.

2) Lock down SSH the boring way

The "boring" way is good:

Use SSH keys, not passwords
Disable password authentication if possible
Consider restricting SSH to your Tailscale interface, or at least to known IPs
Use a non-default SSH port only if you understand it is not real security, just noise reduction

If you do one thing, make it SSH keys. A VPS with password SSH is a magnet for brute force.

3) Put Tailscale in front of everything that does not need to be public

This is the part Ben highlighted, and I think it is the best default for modern self-hosting.

A good rule:

Admin panels, dashboards, databases, and internal APIs: Tailscale only
Public web endpoints: only what you intentionally publish

If Open Claw includes any kind of UI or control plane, start by keeping it reachable only via Tailscale until you are confident in the configuration.

If you are unsure whether something should be public, make it private first. You can always open it later.

4) Use a firewall with an "allowlist" mindset

On most VPS providers, you can use both:

A cloud firewall (provider-level)
A host firewall (like ufw on Ubuntu)

The pattern:

Allow: SSH (ideally only via Tailscale), and whatever public ports you truly need (often 80 and 443)
Deny: everything else

This is where "a bit secure" becomes real. If the port is not open, it cannot be exploited remotely.

5) Run Open Claw with sensible defaults (and do not skip secrets)

Many self-hosted tools are compromised because they are installed quickly and left with:

Default credentials
Weak admin passwords
Hard-coded API keys checked into a repo
Environment files readable by too many users

If the tutorial provides a default login, treat that as a temporary onboarding step. Change it immediately.

Practical tips:

Store secrets in environment variables or a secrets manager
Restrict file permissions on config files
Do not paste sensitive tokens into public issue threads or screenshots

6) Prefer HTTPS when you make anything public

If you decide to expose Open Claw (or a portion of it) to the internet, do it behind HTTPS. Common approaches:

A reverse proxy (Nginx, Caddy, Traefik)
Automatic certificates (Let’s Encrypt)

This protects credentials in transit and reduces accidental leakage.

7) Add basic monitoring and updates

You do not need enterprise tooling. But you do need to know when things break.

Minimum viable operations:

Enable unattended security updates if appropriate for your distro
Set a calendar reminder to update Open Claw and dependencies
Watch logs for repeated auth failures
Consider fail2ban for SSH if you keep SSH internet-accessible

A simple threat model you can actually use

Instead of vague "secure it" advice, here is a usable checklist based on likely threats.

Threat: internet scanners find your service

Mitigation:

Keep services private behind Tailscale
Close unused ports

Threat: SSH brute force

Mitigation:

SSH keys only
Disable password auth
Restrict SSH exposure

Threat: leaked credentials or tokens

Mitigation:

Rotate defaults immediately
Store secrets properly
Use least privilege accounts

Threat: unpatched vulnerabilities

Mitigation:

Patch the OS
Update Open Claw and dependencies
Subscribe to release notes where possible

Why "not technical" content works (and why it is worth making)

Ben said the video is "not technical at all," and that is exactly why it will help people. Tutorials that succeed tend to:

Reduce decision fatigue
Show the full path from zero to working
Include the small operational details people forget

When you add one good security habit to a simple tutorial (like "use Tailscale"), you change outcomes for a lot of beginners. You do not need to turn every post into a security lecture. You just need to make the safe path the easy path.

A final, practical checklist (print this)

Before you call your VPS setup "done":

OS updated and rebooted if needed
Non-root admin user created
SSH keys enabled, password auth disabled if possible
Tailscale connected and tested
Public firewall only allows required ports
Open Claw credentials changed from defaults
Secrets stored safely with tight permissions
If public: HTTPS enabled behind a reverse proxy
Updates and basic log checks planned

If you hit these, you are already ahead of most internet-exposed VPS deployments.

This blog post expands on a viral LinkedIn post by Ben Niehaus. View the original LinkedIn post →