Most "run your own AI" guides stop at the model. If you are building a personal AI assistant that lives on a small VPS and answers you 24/7 through Telegram, the model is usually the part you do not host — you call an API for that. What you host is the boring machinery around it: the bot process, the memory database, the scheduler, the browser it drives.
That machinery is what fills a $6 box. Here are real numbers from six months of running one, not numbers from a spec sheet.
1. Idle is not free
A Node process holding a long-lived Telegram polling loop, a SQLite handle and a couple of extensions sits at roughly 180–260 MB resident doing nothing at all. On a 1 GB VPS that is a quarter of the box gone before the first message arrives.
2. The build is the spike, not the runtime
What actually kills a 1 GB instance is npm ci plus a TypeScript build. Type-checking a mid-size project peaks well above 1 GB and the OOM killer takes the process out mid-compile — usually right after an update, which is the worst possible moment.
The fix is not a bigger plan. It is either building elsewhere and shipping compiled output, or adding 2 GB of swap and accepting a slow build once a week.
Swap is fine for a build spike. Swap is terrible for a runtime spike. If your assistant is swapping while answering, you are one cron job away from a 30-second reply.
3. The database grows faster than you expect
Conversation history with full-text search and vector embeddings is the fastest-growing file on disk. Rough shape after half a year of daily use:
| Component | Size |
|---|---|
| raw conversation chunks | ~120 MB |
| embedding table | ~ same again |
| FTS index overhead | 20–30% on top |
Nothing dramatic — until you add retention. Daily plus weekly backups multiply whatever the live database weighs by seven to eleven. "10 GB is plenty" stops being true quietly.
4. Embeddings decide your RAM tier
This is the biggest fork in the road:
- Hosted embedding API — costs money, almost no memory.
- Local embedding model — free, and 700 MB – 1.4 GB permanently resident if you want the first query of the day to be fast.
A 2 GB VPS can do local embeddings for a single user. A 1 GB VPS cannot, no matter how carefully you tune it. Discovering this after you have written the ingestion pipeline is an expensive afternoon.
5. A headless browser is a second server
If the assistant logs into things on your behalf, Chromium is not a library — it is another 300–500 MB process with its own crash modes and its own zombie tabs. Budget for it separately, keep exactly one tab alive, and restart the whole browser on a schedule instead of hunting leaks.
The sizing rule I ended up with
| RAM | What it actually supports |
|---|---|
| 1 GB | hosted embeddings only, no browser, builds done off-box, swap for updates |
| 2 GB | honest minimum for local embeddings or a browser — not both |
| 4 GB | comfortable: local embeddings + browser + on-box builds + room for the DB to double |
The interesting part: none of this is about AI. It is ordinary capacity planning for a long-running service, which is exactly why tutorials skip it — they are written to be impressive rather than operational.
If you are weighing a managed chatbot against a self-hosted AI assistant, the honest trade is not privacy versus convenience. It is privacy versus the twenty minutes a month you will spend watching a graph.
Longer field notes on the same machinery — what broke, what the fix was: https://avelina.ai/blog
What is your actual RSS for a always-on assistant process? Curious whether the 180–260 MB idle figure holds outside Node.
Top comments (0)