The self-hosted AI assistant guide

Why teams self-host their assistant

A self-hosted assistant is not a philosophical statement, it solves concrete problems that SaaS assistants cannot.

• Privacy: conversations and files stay on infrastructure you control, which for regulated teams is not optional.
• Cost control: you pay for model usage, not per-seat fees that scale with headcount.
• Customization: system prompts, tools and integrations you decide, without waiting on a vendor roadmap.
• Multi-channel: one assistant with one memory across every messaging app, instead of one bot per platform.
• No artificial limits: no vendor rate caps or usage tiers between you and your own compute.

The anatomy: three components

Every self-hosted assistant, however assembled, is three parts. The gateway connects to messaging platforms and normalizes messages in and out. The model backend processes each message with Claude, GPT or a local model. The state store persists conversation history and preferences so the assistant remembers anything at all.

You can build each part yourself, and for a single channel with one user that is a reasonable weekend. The reason runtimes like OpenClaw exist is that the second channel, the second user and the second month each multiply the plumbing, and the bundle starts beating the bespoke build.

Picking your channels

Channel choice sets most of your setup effort, because the platforms differ enormously in how welcoming they are to bots.

• Telegram: the easy start. An official bot API and a token from BotFather in thirty seconds. Best for a quick first assistant and groups.
• Discord: also easy, official API, well-trodden. Best for communities and servers.
• WhatsApp: medium. It runs over an unofficial client protocol with QR-code pairing, and sessions expire periodically. Worth it because it is where people actually are.
• Slack: medium, official SDK with OAuth scopes to configure. The natural choice for team assistants.
• iMessage: hard, requires an always-on Mac running a bridge server. Only for committed Apple households.
• Signal and Microsoft Teams: the hard tier, via CLI bridges and bot frameworks respectively. Choose them for privacy or corporate mandates, not convenience.

Choosing the model: cloud API or local

Cloud APIs are the right default for most: Claude for conversation, coding and analysis, GPT for versatility and ecosystem, Gemini if you live in Google Workspace. They need no special hardware, and if you already pay for a Claude Pro or ChatGPT Plus subscription, the assistant can often ride it instead of metered keys.

Local models, Llama 3, Mistral or Qwen, remove per-token costs and keep every byte on your hardware, at a price: you need a GPU with 16GB+ VRAM, 32GB of system RAM and a fast SSD for good results, and quality still trails the frontier cloud models. The honest rule: choose local for privacy or cost-at-volume reasons you can articulate, not as a default.

What it actually costs

The DIY budget has three lines. Hosting: $5-20/month for a VPS with 1 CPU and 1GB RAM, which is enough for cloud-API setups, or a Raspberry Pi at home for nearly nothing. Model usage: $10-100/month on APIs depending on how much you talk to it, or a flat subscription if you connect one. Maintenance: your time, which is the line that decides whether DIY is cheap.

For local models, swap the VPS line for GPU hardware you probably already priced. There is no per-seat fee anywhere, which is exactly the point, and why a self-hosted assistant gets more attractive the more people use it.

OpenClaw: the all-in-one route

OpenClaw, formerly known as MoltBot and Clawdbot, bundles the whole architecture into one open-source runtime: a multi-channel gateway covering WhatsApp, Telegram, Discord, Slack, iMessage, Signal and more, model switching across Claude, GPT, Gemini or local models, persistent conversation state, a web UI for configuration, and bring-your-own-key auth including existing subscriptions.

The practical consequence: instead of building a gateway, backend and state store per channel, you configure one runtime once and every channel talks to the same assistant with the same memory. It is the difference between assembling an assistant and operating one, and it is why OpenClaw has become the default answer for serious self-hosted setups.

Security is not optional

A self-hosted assistant holds credentials and talks to strangers' input all day. Treat it like the production service it is.

• Keys: never in git, always in environment variables or a secrets manager, rotated periodically, with spending caps set at the provider so a leak has a ceiling.
• Access: allowlist the users and numbers that may talk to the assistant, rate limit per user, and log interactions for audit.
• Injection: treat inbound messages as untrusted input and watch for prompt injection attempts, especially once the assistant can take actions.
• Data: encrypt stored conversations at rest, expire old ones, and stay conscious of what flows to cloud model providers; local models exist for the truly sensitive tier.

From personal assistant to production service

The build order that works: pick one channel, Telegram if you have no strong pull elsewhere, choose your model, deploy on a VPS or home server, and only then add channels. Add a health check endpoint and external uptime monitoring early, because an assistant that silently died is worse than none.

The fork in the road comes when other people start depending on it. A personal assistant can go down for an evening; a team's assistant cannot, and an assistant per client absolutely cannot. At that point you need automatic recovery, isolation between instances, versioned state and observability, which is a platform, not a weekend project. Molted runs OpenClaw as exactly that platform, in production since January 2026, with self-healing that catches crashes in under 60 seconds and 1,000+ integrations ready on day one, managed or on your own infrastructure.