How to Self-Host Your Own AI Assistant (and the Stuff Nobody Warns You About)

I run my own AI assistant. Not a ChatGPT tab, but an actual assistant that lives on a server I control, remembers what we talked about last month, reads my email, messages me on Telegram, and doesn't send my life to anyone I haven't explicitly chosen. It cost me almost nothing to run and about two weekends to get right. This is the guide I wish someone had handed me before the first weekend, including the parts that only bite you after you think you're done.

Why bother

Three reasons: it's yours, it remembers, and it's cheap. A hosted chatbot forgets you between sessions and lives inside someone else's product decisions. A self-hosted assistant keeps its memory on your disk, connects to the things you care about, and you decide exactly which model gets to see what. If any of that appeals, keep reading.

In practical terms, I can ask mine to find an email thread, summarise what was agreed, and pull out the actions without digging through the inbox myself. If one of those actions belongs on my calendar, it can prepare the event but still asks before creating it. That same pattern can turn client emails, support requests, or recurring reports into a short list of decisions instead of another hour of admin.

What you need

Three ingredients: a box, Docker, and a chat surface.

The box. Mine is an Oracle Cloud Always Free ARM instance (Ampere A1). It used to be an absurd deal: 4 cores and 24GB of RAM for free, but Oracle cut the free tier in June 2026 to 2 cores and 12GB. That's still comfortably enough for Docker plus an assistant framework; the heavy lifting happens in the model providers' datacenters, not on your box. If you go pay-as-you-go, you can still reach the old 4/24 allocation.

Docker. Run everything in containers with a compose file, not bare metal. This isn't ideology; it's that in six months you'll want to upgrade or rebuild the box, and docker compose up against a versioned config is a ten-minute job instead of an archaeology dig through your own shell history.

A chat surface. You need somewhere to actually talk to the thing. I use Telegram: the bot API is free, painless, and works on every device I own. The assistant framework I run is OpenClaw, an open-source self-hosted gateway that handles the Telegram connection, model routing, tool access, and memory. There are alternatives; the architecture advice below applies to all of them.

The stack at a glance

• Oracle Cloud Ampere A1 for the server.
• Docker Compose for repeatable deployment and upgrades.
• OpenClaw for model routing, memory, tools, and integrations.
• Telegram as the chat interface.
• Tailscale for private remote access without exposing the gateway.
• OpenRouter and Ollama Cloud for free routine inference, with subscription-authenticated frontier models for harder work.
• DataImpulse as a residential-proxy fallback when websites block the server's datacenter IP.

Keeping the model side cheap

Self-hosting the assistant does not mean you need to self-host the language model. A small free server is enough for the gateway, memory, Telegram connection, and tools; the expensive inference can happen elsewhere. The trick is to use access you already have before reaching for a metered API key.

Use subscription-backed sign-in for frontier work. OpenClaw supports ChatGPT/Codex subscription OAuth and can reuse an existing Claude CLI login. On those supported routes, requests draw from the quota attached to your existing subscription instead of creating a separate pay-as-you-go API bill. Provider rules and limits can change, so check the current OpenClaw OAuth notes before treating this as permanent, but it is the cheapest sensible way to keep a strong model available for genuinely difficult work.

Use free cloud routes for routine work. OpenRouter's openrouter/free router sends a request to one of the free models currently available, filtering for capabilities such as tool use or image understanding. You do not control the exact model and free availability can move around, but it is useful for low-volume personal tasks. Ollama's free plan also includes light use of cloud-hosted open models, while its web search API has a free individual allowance.

My setup therefore uses two tiers:

• Frontier models through subscription auth for code, planning, and anything that genuinely needs stronger reasoning.
• A free cloud route for routine chatter, heartbeat checks, summaries, and small errands. Ollama Cloud is what I currently use for that layer.

Prompt caching matters too. An assistant repeatedly sends its instructions and memory alongside your messages; caching that stable context reduces how much work the provider has to repeat. Between subscription quota for the hard jobs and free cloud models for the ordinary ones, a personal assistant can stay cheap without pretending a tiny VPS can run a frontier model locally.

Making it remember

Here's the wall everyone hits: you restart the container and your assistant greets you like a stranger. LLMs are stateless. The context window is not memory; it's a whiteboard that gets wiped.

The fix doesn't need a vector database. Mine is two kinds of plain Markdown files on disk:

• Daily notes: one small file per day (memory/2026-07-19.md). The assistant jots down what happened, what's pending, what was decided. Cheap to write, cheap to skim.
• One curated long-term file: the distilled stuff that should survive forever: who I am, ongoing projects, preferences, standing rules. The assistant reads it at the start of every session, and periodically promotes durable facts up from the daily notes.

The instruction that makes it work is one line in the system prompt: "if something should survive a restart, write it down." Files survive restarts, get backed up with everything else, and, crucially, you can open them in a text editor and see exactly what your assistant believes about you. Try doing that with a hosted product.

The security part people skip

This is the section to actually read. You are about to run a service with access to your email, calendar, and files. Getting this wrong is worse than not building it at all.

Never expose the gateway to the public internet. Mine binds to loopback only, 127.0.0.1, so nothing outside the box can reach it directly. When I need remote access, it goes through a Tailscale tunnel: an encrypted private network between my devices, with no open port for the rest of the world to find. Shodan is full of people's exposed self-hosted AI panels. Do not join them. If you remember one thing from this article, it's this paragraph.

Gate anything that acts on the outside world. My assistant reads Gmail freely, since reading is reversible. But calendar writes require my explicit approval before they happen, every time. The principle: read access can be generous, write access to the real world gets a human in the loop. You do not want a confused language model autonomously emailing your clients at 3am.

Keep secrets out of your repo. Your compose files and config belong in git; your API keys, bot tokens, and OAuth credentials do not. Environment files with tight permissions, listed in .gitignore from day one. Everyone who has leaked a key to GitHub was also sure they'd never do that.

The gotchas nobody mentions

Datacenter IPs are pariahs. The moment your assistant tries to browse the web from a cloud server, you'll discover half the internet blocks datacenter IP ranges outright: Cloudflare challenges, silent 403s, endless CAPTCHAs. Nothing is wrong with your code; the site just hates where your packets come from. My fix is a residential proxy (I use DataImpulse at roughly $1/GB, pay-as-you-go) that the assistant routes browsing through when a site blocks the server's own IP. It's not magic; it solves IP-reputation blocks, not JavaScript fingerprinting, but it turns "mysteriously broken" into "works" surprisingly often. Nobody puts this in the quickstart docs, and everybody hits it.

Cost creep. "Free" has edges. Frontier usage can burn through your subscription quota, paid fallbacks still bill by usage, the proxy charges per gigabyte, and one runaway automation loop can quietly exhaust a limit overnight. Check your provider dashboards weekly for the first month, set spending alerts where available, and make the free route the default rather than the exception.

The short version

Free ARM box (with tempered expectations post-June-2026), Docker Compose, Telegram in front, frontier models for hard problems and a cheap one for everything else, memory as plain files, gateway on loopback behind a tunnel, approvals on anything that writes to the real world, and a residential proxy for when the internet decides your server is a robot. None of it is exotic. All of it is the difference between a weekend toy and something you'll still be using, and trusting, a year from now.

If you want the benefits of a private AI assistant without spending your weekend configuring Docker and residential proxies, we should talk.