Skip to content
Practical AI Guides, Reviews & Tutorials Sunday, 26 July 2026

Six weeks of running my own AI assistant on a small VPS

This isn’t a recommendation. It’s a report, including the parts that went badly — the free tier that couldn’t hold the context, the OAuth grind, and the backups I added too late.

I’ve had a self-hosted AI assistant running on a rented server for about six weeks now. I talk to it through Telegram. It reads my email when I ask, drafts replies I approve before sending, and runs a few scripts.

This isn’t a recommendation. It’s a report, including the parts that went badly.

Why not just use the app

Two honest reasons.

The first is that I wanted it in Telegram, because that’s where I already am. Opening a separate app to ask a question is a small amount of friction, and small friction is exactly what kills a habit.

The second is that I wanted it to do things, not just answer. Read the mailbox. Run a script. Touch a file. That means giving something real access to real accounts, and I wanted that running on a machine I pay for and can turn off, not one I can’t see.

Neither reason is about privacy absolutism. The models I’m calling are commercial APIs; my text goes to them regardless. What I control is the surrounding layer — the tools, the permissions, the logs.

What it actually cost

A small VPS: two virtual cores, 8GB of RAM, a few dollars a month. Model calls on top, which vary with how much I use it, and are the larger number in a busy month.

The RAM matters more than the cores. I started smaller and it fell over.

The failures, in order

Free model tiers. I tried to run the whole thing on a free API tier. It failed constantly, and it took me an embarrassing while to work out why: the assistant sends a large system prompt with every request, around 65,000 tokens of context. The free tier’s limit was well below that. Every single call was too big. Nothing was broken; I’d simply picked a bucket smaller than the thing I was pouring.

Authentication, repeatedly. More of my six weeks went on OAuth than on anything else. Tokens expiring because the app was still in “testing” mode. A credential store encrypted under one password and then read by a process using another, producing an error message about an integrity check that told me nothing until I understood it meant wrong password, not corrupt data. An API key in a format the library refused to accept over the transport it defaulted to.

None of this is AI-specific. It’s ordinary systems plumbing, and it’s the actual work.

Editing config by hand. I broke the configuration file twice with a stray comma. Now I never open it in an editor. I write a small Python script that makes the change, validate the JSON, restart, and only then copy the file over the known-good backup. Slower per edit. Faster overall.

What works well enough to keep

Draft-and-approve email is the one I’d miss. It writes the reply, sends it to me in Telegram, and does nothing until I say send. I’ve never once let it send unreviewed, and I don’t intend to. The blank page problem is gone; the responsibility isn’t.

Reading things is reliable. Summarising a long thread, finding an attachment, pulling a figure out of a document — this works nearly every time.

Running commands works, with supervision. It’s good at the ninety percent of shell work that’s routine. It is confidently wrong often enough that I read what it proposes before it runs.

What I got wrong

I over-trusted the setup phase and under-planned the backups. Three weeks in, I had a working system and no snapshot of it. If the container had died, I’d have rebuilt from memory. Now there’s a nightly archive of the config, the workspace, and the environment file, pulled down to my laptop weekly. Should have been step two, not step twelve.

I also assumed self-hosting meant fewer moving parts. It means different moving parts, and more of them. The app was one thing to trust. This is a server, a container, four model providers, a bot token, an OAuth app, and a keyring — each with its own way of failing at two in the morning.

Would I recommend it

If you want an AI that answers questions: no. Use the app. It’s better, it’s cheaper, and someone else is on call.

If you want an AI that does things on your behalf, and you’re willing to treat it as a system you maintain rather than a product you use, then yes — with the understanding that you’re signing up for the plumbing. Budget your time for authentication, not for prompting.

Six weeks in, I use it daily. I also spent more evenings on OAuth than I spent writing anything it does.

Share with .. ..

Mohammed Sajjad

Chief Accountant by day, automation builder by night. Building self-hosted AI tools, VBA macros, web design and Python apps that make finance work less painful.

Newsletter

New Post

This the new post of today

Subscribe to Blog via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Related entries

  1. No. 064 Facebook Verified: Meta wants a video of your face, and this time it’s free · 5 min
  2. No. 063 The month-end close used to eat an afternoon. Now it’s a button. · 4 min
  3. No. 063 I tried to let an AI post to my own blog. It took four dead ends to get there. · 3 min
  4. No. 060 5 Ways I Use AI to Automate Boring Office Work · 2 min
  5. No. 060 ChatGPT vs Claude vs Gemini in 2026: Which One Should You Use? · 2 min

Leave a note

Your email address will not be published. Required fields are marked *