Docs/Belken Workstation/Install

Belken Workstation install guide

One command on a fresh Windows 11 box brings up the whole stack. This page covers what you need before you start, what each step is actually doing to your machine, and how to verify the thing is up before you trust it with work.

1command
7steps
30 to 45minutes, fresh box
13agent workspaces

What it is

Belken Workstation is a single Docker Compose stack that puts an agent operations layer on one machine. The core of it is the OpenClaw gateway plus the infrastructure agents actually need: Postgres with pgvector, ChromaDB, Redis, n8n for workflows, and a private SearXNG for search.

Two one shot containers run on first boot. One seeds a writable config from the template in the repo. The other creates 13 isolated agent workspaces, one directory per agent, so personalities never bleed into each other. That isolation is not a nicety. Sharing a workspace between agents is what produced the identity bleed we had to go back and fix once already.

Everything past the core is optional and turns on by profile. The branding machine adds Persona Studio and browser sidecars for posting from logged in accounts. The GPU profile adds ComfyUI, Forge and Remotion. The full profile adds a local Ollama. The installer decides which of these your hardware can carry and skips the rest with a stated reason.

Before you start

You do not need to pre install Docker, WSL2, Ubuntu, Tailscale, Python, UV, age or OpenSSH. The installer handles all of it.

Grab your numeric Telegram user ID before you run anything. The installer asks for it so the agent only answers you. You can get it from @userinfobot in Telegram.

The install

Open PowerShell as Administrator and run this. The repo is private, so the clone uses SSH and your machine needs a key registered with a GitHub account that has access. An HTTPS clone returns Repository not found.

PS> git clone git@github.com:belkenbot/belken-workstation.git $env:USERPROFILE\belken-workstation
PS> cd $env:USERPROFILE\belken-workstation
PS> Set-ExecutionPolicy Bypass -Scope Process -Force
PS> .\install.ps1
If it reboots, run it again

WSL2 needs a restart the first time its Windows features get enabled. The installer reboots once and the script is idempotent, so re running the same command picks up where it left off rather than starting over.

What each step does

The installer prints a banner and walks seven numbered steps with four sub steps inside them. Most of the wall time is image pulls.

STEP 1

WSL2

Enables the Microsoft-Windows-Subsystem-Linux and VirtualMachinePlatform features. First time only, and it needs the reboot. If both are already on, this is a no op.

STEP 2

Ubuntu on WSL

Installs the Ubuntu distro if no WSL distro is present and updates the WSL kernel. Ubuntu will ask you to set a username and password on first launch. That is optional and the Docker stack does not need it.

STEP 3

GPU detection, driver and crash audit

Looks for nvidia-smi. If a GPU is there it prints the model and VRAM and unlocks the GPU services. If not, it continues and notes that those services will be unavailable.

When a GPU is found it also reads the driver date and warns loudly if the driver is more than 180 days old, then audits C:\Windows\Minidump\. Three or more blue screen dumps in the last twelve months gets flagged with the most recent filename, because a stale driver on a new GPU architecture under heavy load is a real crash risk and it is better to know now.

STEP 4

Docker Desktop

Downloads and silently installs Docker Desktop, starts it, and waits up to 90 seconds for the daemon.

The version is pinned to 4.73.1 on purpose. Release 4.74.0 has a Windows only regression where internal services try to listen on malformed socket paths, each one fails in turn, and the Linux backend never starts. The installer hardcodes the 4.73.1 download and also switches off Docker AI in the settings store, because that feature spawns the same broken socket and turns into a delayed failure after any crash or settings reset.

It then builds a local wrapper image around the upstream OpenClaw image that adds ca-certificates. Without that, every outbound HTTPS call from the gateway fails its TLS handshake quietly. Telegram polling dies and provider API calls error out with nothing useful in the log.

STEP 5

NVIDIA container toolkit

On Windows with Docker Desktop, GPU passthrough is automatic through the WSL2 backend. No separate toolkit install is needed, so this step is a sanity check.

STEP 5b

Tailscale

Silent install. You run tailscale up once from an interactive shell afterward to join your tailnet. Optional if you do not use it.

STEP 5c

Python 3.13 and UV

Installs Python 3.13 and UV on the Windows host, and python3 with pip and venv inside WSL2 Ubuntu. Both are skipped if already present.

UV matters because most modern MCP servers spawn isolated environments through uvx. The step also scans for the recommended Claude Desktop connectors and prints which are installed and which are missing. It deliberately does not write the Claude Desktop config file, because Claude Desktop rewrites that block on startup. Install connectors through the in app Connectors screen instead.

STEP 5d

SSH keys and tunnels

Enables the Windows OpenSSH client, generates an ed25519 keypair if you do not have one, and writes a marked block into your SSH config with host entries for sibling machines. Re running the installer replaces only that marked block, so any hosts you added yourself survive.

It prints the public key and the one line command to authorize it on each target box. After that, aliases like ssh rtx work, and a tunnel entry can forward a remote Ollama to localhost:11434 on this machine.

STEP 6

Deploy the stack

This is the long one. It creates .env, auto generates secure random values for the gateway token, dashboard auth secret, SearXNG secret and n8n encryption key, and writes a copy of everything it generated to a gitignored credentials file so you are not digging through the env file later.

It renders the live config files from their templates so the real token never lands in git, then picks profiles from your hardware. GPU services come on when a GPU is present. The local model profile only comes on with a GPU and at least 28 GB of RAM, because it runs out of memory below that. Anything it cannot pull is skipped with a stated reason rather than failing the run.

After the containers are up it waits for Postgres to report healthy, fixes the ownership of the browser sidecar data volumes so the first screenshot does not fail with a permission error, prompts you for an LLM provider and key, and wires the Telegram bot including the operator allowlist.

STEP 6b

Desktop shortcut

Drops a Belken Control Center shortcut on your desktop pointing at the local dashboard. It polls every service every five seconds and gives you an open button for each one.

STEP 7

Verify

Inspects every container that should be running for the profiles it chose, HTTP probes every service with a URL, and prints a final banner with running services, skipped profiles and the reason each was skipped, your generated credentials, and a first visit checklist.

Services and ports

The core stack is always on. Everything else appears only if its profile was enabled.

Service
Port
Reach it at
OpenClaw gateway
18789
http://localhost:18789
n8n workflows
5678
http://localhost:5678
SearXNG search
8080
http://localhost:8080
ChromaDB
8400
http://localhost:8400
Postgres with pgvector
5432
localhost:5432, no HTTP
Redis
6379
internal only
Persona frontend, branding profile
5173
http://localhost:5173
Persona API, branding profile
3721
http://localhost:3721
Headless browser sidecars
18800 to 18802
automation, always on with branding
Headed Chrome sidecars
18803 to 18805
interactive logins, off by default
ComfyUI, GPU profile
8188
http://localhost:8188
Forge pipeline, GPU profile
8200
http://localhost:8200
Remotion editor, GPU profile
3100
http://localhost:3100
Ollama, full profile
11434
http://localhost:11434
Why two kinds of browser

The headless sidecars run automation and stay up. The headed ones run real Google Chrome and stay off by default, because Google sign in refuses containerized Chromium with a browser not secure message. Log in through the headed one, then point automation at the headless one. They keep separate profile volumes on purpose.

Verify it worked

Do not take the banner's word for it. Three commands settle it.

PS> docker compose ps
PS> docker inspect --format='{{.State.Health.Status}}' belken-postgres
healthy
PS> curl http://localhost:18789

If Postgres takes longer than sixty seconds to report healthy, the installer warns but does not fail. Give it another minute and check again. If it stays unhealthy, read docker logs belken-postgres before anything else.

First session

Every agent ships with a bootstrap prompt that runs a first conversation where the agent settles its own name, voice and identity through dialogue. Do not skip this for the agents you actually talk to. It is the difference between an assistant that feels like itself and one that feels like a template, and skipping it is what caused the identity problem we had to go back and fix.

PS> docker exec -it belken-openclaw openclaw agents list
PS> docker exec -it belken-openclaw openclaw chat
# talk with the main agent. it writes its own identity from the conversation.

PS> docker exec -it belken-openclaw openclaw chat --agent director

Task agents that never hold a conversation can stay generic. Skipping the ritual for those is fine.

Adding services later

If a profile got skipped because you had no GPU, not enough RAM, or an image would not pull, you can opt in any time without reinstalling.

PS> cd $env:USERPROFILE\belken-workstation

# GPU pipeline, if you added a GPU after install
PS> docker compose --profile gpu up -d

# the four local MCP servers
PS> docker compose --profile mcp up -d

# headed Chrome, first run builds the image and takes a couple of minutes
PS> docker compose --profile headed up -d --build

# everything
PS> docker compose --profile full up -d

The MCP profile brings up four local servers covering image generation, Persona operations, private search and workflow control. They register themselves with the gateway, so agents can call them without leaving it.

Resetting

There are two levels of teardown and the difference matters.

Light reset

reset.ps1 wipes the stack, removes pulled images and deletes the install directory, but leaves Docker Desktop, Tailscale and WSL2 in place so the next install is fast. This is the one you want almost every time.

Full cleanup

cleanup.ps1 takes the machine back to a clean slate. It stops the stack, uninstalls Docker Desktop and Tailscale, scrubs the leftover Docker folders, unregisters the WSL distros and removes the working directories. It installs nothing and exits with a state report so you can check before reinstalling. Reboot once afterward to clear pending file deletions.

Run both as Administrator

Cleanup deliberately leaves the WSL2 Windows features enabled. That means the next install skips its WSL step and avoids an extra reboot. Turn them off by hand only if you want the machine fully stock.

Something broke during the install

Fourteen specific failures, each with the exact symptom you will see, the cause, and the command that fixes it. Every one of them happened on a real machine here first.

Go to troubleshooting All docs