Clawdbot Setup Complete Guide: Configure Your AI Assistant from Scratch

Have you also grown tired of repeatedly pasting the same reminder messages in different places every day? This little daily annoyance keeps intensifying. That day, I came across the tool Clawdbot, so I gave myself two evenings, a cup of tea, and a rule: if the setup started to feel like a part-time job, I'd stop. I didn't stop. It wasn't effortless, but it was reasonable, and a few moments even felt… kind.

I'm Anna. For context, I tested this in late January 2026 on a MacBook Air (M2, macOS Sonoma) with Docker Desktop 4.x, and a small Ubuntu 22.04 VPS I already use for side projects. What follows is the Clawdbot setup I wish I'd had, practical, honest, and not allergic to small annoyances.

Pre-installation Decisions: Which Setup Fits You?

A small decision upfront saves a lot of backtracking. Before you click anything, choose where Clawdbot will live. Your answer sets expectations for cost, privacy, and reliability.

Docker vs VPS vs Local

Here's how I thought about it, not theoretically, but standing in my kitchen waiting for the kettle to boil:

Local (my laptop): Easiest to try, zero hosting cost, slower only if your machine is old, and it keeps everything close. Downsides: it only runs when your laptop is on, which means no always-on habits or reminders. I used this to kick the tires for an hour.
Docker on my machine: Slightly more structured than a bare local run. It let me keep dependencies contained and reset with a single command if things got weird. This is the path of least regret for a first run.
VPS (small cloud server): Best if you want Clawdbot to run 24/7 and talk to external channels (Slack/Discord/Telegram). It adds a bit of devops-ish overhead, a domain, ports, firewall, but it's not scary if you take it step by step. I spun up a $6–$8/month instance and felt fine about it.

How I chose: I started local to make sure I actually liked the idea, then moved to the VPS for the always-on bits. If you're privacy-sensitive or experimenting, stay local. If you want gentle nudges and channels to work reliably, a VPS is worth the small monthly fee.

Tiny note on performance: on my M2 Air, startup was snappy: on the VPS, first boot took maybe 20–40 seconds longer while pulling images and warming caches. Not a big deal, just a "make tea first" moment.

Environment Preparation Checklist

I kept this simple. Fifteen minutes here saved me from three random error messages later.

Accounts and keys: Have API keys ready for whatever model/service you plan to use (if applicable). I stored them in a local .env file first, then moved to the VPS's environment store. No heroics.
Docker (optional but helpful): If you're going the container route, install Docker Desktop (Mac/Windows) or Docker Engine (Linux). The docs are straightforward: see the official Docker installation guides for your OS. I used Docker Desktop because I like clicking "restart" instead of searching for a process ID.

Ports and firewall: Decide on your web port (I used 8080 locally, 443 behind a reverse proxy on the VPS). If you're on a VPS, set basic firewall rules, allow 80/443 if using a proxy, and your chosen internal port. Nothing fancy. For Ubuntu 22.04 VPS users, I found the DigitalOcean UFW firewall guide particularly helpful.
Domain (VPS only): Not required for local testing. For the VPS I pointed a subdomain to the server's IP and set up TLS via a proxy. It took ten minutes and removed the "is this secure?" question from my brain.
Basic system checks: On the VPS, I ran updates, confirmed disk space, and checked time sync. Boring, yes. But boring keeps logs clean.

Time spent: ~20 minutes total for prep. I saved the details in a plaintext note because future me forgets what ports I chose.

Installation Wizard Detailed Guide

I appreciate when tools don't make me memorize flags or chase missing dependencies. The Clawdbot setup felt closer to that than I expected. Not polished to the point of magic, but supportive.

How I ran it (two paths):

Local quick start (Docker): I pulled the compose file, set a couple environment variables, and brought it up. It asked for basics on first launch, admin email, a password, and whether I wanted a sample workspace. I said yes to the sample: it made the dashboard less empty and my brain less wary.
VPS (always-on): Same idea, just with a reverse proxy in front and the environment variables stored outside the repo. First boot did the usual migrations and seeded a default admin. On a fresh box, I budgeted 10–15 minutes for the initial pull, then a minute or two for provisioning.

What worked nicely:

The wizard didn't shove too many decisions at me. It asked for the essentials and let me skip integrations I wasn't ready for.
Clear validation. When I pasted an API key with a stray space (classic), it flagged it immediately.

Key configuration file parameters

If you like context before committing, here are the knobs that mattered in practice. I kept them in a .env file locally and environment variables on the VPS.

APP_URL: The external URL your bot will live at. Matters for webhooks and redirects. I forgot this once: OAuth sulked.
PORT: Local port for the web app. 8080 is a friendly default unless something else already claimed it.
DATABASE_URL (or equivalent): If you're graduating from the embedded storage, point this to Postgres or your choice. Do it on the VPS when you care about resilience.
MODEL_PROVIDER / API_KEY: Model selection plus your key. I tested with a single provider to start: switching later was painless but did require a restart.
LOG_LEVEL: I set this to "info" first, flipped to "debug" briefly when testing a webhook, then back to keep noise down.
FILE_STORAGE or MEDIA_DIR: Where uploads or exports land. Local path for my laptop, mounted volume on the VPS.
SESSION/SECRET_KEY: Auto-generated on first run is fine: back it up if you're planning to keep the instance long-term.

Two tiny tips:

Put comments in a separate note, not the .env file. Future you will thank you when copy-pasting to a remote shell.
Change one thing at a time and restart. When I tweaked three variables at once, I lost five minutes hunting the wrong culprit.

Dashboard Initial Setup

Landing on the dashboard felt like walking into a room that's already mostly tidy. Not empty, not overwhelming.

I did three things right away:

Created a "Daily" space with two light automations, a morning check-in (three questions) and an evening wrap-up. Nothing fancy. It made the tool relevant within 24 hours instead of "someday."
Adjusted defaults: time zone (again), date format, and notification windows. The time window mattered more than I expected: it kept the nudges in the hours where I'm actually receptive.
Enabled a sample knowledge base. I tossed in a few personal notes, a cooking conversion chart, a short reading list, to see how retrieval felt. It was better than rummaging through old tabs.

Minor annoyance: a couple labels were a bit generic until I hovered for help text. Not a deal-breaker, just a small pause while I figured out what "scope" meant in one menu.

Connect Your First Channel

This is where Clawdbot stops being a tab and starts being present. I connected a single channel first, one I actually use daily, instead of wiring everything at once.

What I tried:

Slack: App creation, permissions, one redirect URL, then a token. I copied the token into the dashboard and ran the built-in test. It worked on the second try (the first failed because of the APP_URL mismatch I mentioned earlier). After that, posting felt seamless. For anyone new to Slack bot setup, the official Slack OAuth installation guide walks through the complete flow clearly.
Email relay (lightweight): For a friendlier daily check-in, I set a simple email channel. It wasn't instant, but "good enough" for me, messages landed reliably within a minute.

A small reality check: each platform has its own hoops, a bot token here, a slash command there. Do one channel, get it stable, then move on. Ten minutes focused beats thirty minutes scattered.

If you're on a VPS, confirm your proxy passes through the right headers: I missed one and webhooks quietly failed until I fixed it. The logs nudged me in the right direction once I remembered to look.

Verify Installation Success

I like proof. Not elaborate benchmarking, just enough to trust the thing.

My quick checks:

Health page responds: A simple status endpoint (or the dashboard home) should load cleanly. If it hesitates for more than a few seconds, watch the logs during startup once.
Logs are calm: On first boot I looked for obvious red flags, repeated timeouts, auth errors, missing ENV warnings. After the first day, I stopped checking.
A round trip works: I sent a short message from my channel, watched it show up, and got a reply back. That one loop made it "real."
Persistence survives restart: I restarted the service and confirmed my settings and a couple messages were still there. No one likes rebuilding small things.

Time saved? It's early, but I noticed the mental load drop almost immediately. Instead of juggling three micro-reminders, I've got one place nudging me gently at the right time. Not dramatic. Just pleasant.

All that setup and waiting… imagine if your reminders just happened, quietly, while you are busy. Try our Macaron. It keeps track, nudge you when needed, and never ask for a terminal or login.

If you want to take Clawdbot one step further and keep it running reliably in Docker, check out our detailed guide here: Clawdbot Docker Setup.