What AI Can You Run on a 1-2 GB VPS?

Part 4 of the AI series, and the first of the plan-size guides. New to all this? Start with part 1. For the 1 GB and 2 GB plans in general, see the 1 GB VPS guide and the 2 GB VPS guide.

The honest headline first: a 1 or 2 GB VPS cannot run a chatbot as clever as the ones you know. But that is not the same as "no AI". Most of the useful pieces of an AI setup are small: the web page, the connections, the speech and text tools, and the automation. A tiny plan can host all of those, and can still use a powerful model by calling out to a service for the parts that need one. This guide shows what that looks like, with ten ideas that fit, and what does not.

What is in this guide

• What fits in the memory
• 1. A private chat page for outside models
• 2. A gateway that tracks your spending
• 3. Document OCR on demand
• 4. Text-to-speech
• 5. Search by meaning over your notes
• 6. Transcribing short recordings
• 7. A tiny local model for sorting and tagging
• 8. Automations that call an AI
• 9. A chat bot for Telegram or Discord
• 10. A daily digest, written for you
• What does not fit
• Keeping keys and costs under control
• When to step up

What fits in the memory

These are rough figures for idle use, and they vary with versions and settings. Treat them as a way to plan, not as promises.

Piece	Roughly
Operating system and SSH	100 to 200 MB
Docker itself	100 to 200 MB
A chat page such as Open WebUI	Plan on about 500 MB to 1 GB
A gateway such as LiteLLM	Plan on a few hundred MB
An automation tool such as n8n	Plan on about 500 MB
Tesseract OCR	Small, and only used while a scan is processed
A small speech or embedding model	From tens to a few hundred MB while working
A tiny language model (under 1B parameters)	About 0.5 to 1 GB when loaded

The practical lesson is that 1 GB suits one or two light pieces, and 2 GB suits a small combination. Do not try to run everything at once. A little swap space is a sensible safety net on these plans, but if the server is swapping regularly, it needs fewer pieces or a bigger plan.

1. A private chat page for outside models

What it is. A ChatGPT-style page, hosted on your own server, that talks to an outside model service using your own account and key. You get a clean interface, history stored on your server, saved prompts, and the choice of many models in one place.

Why it suits this plan. The heavy thinking happens somewhere else. Your VPS only serves a web page, which a 2 GB plan handles well, and a 1 GB plan can manage with care.

How to set it up. Use the Open WebUI setup from part 3, but leave out the Ollama service and point the page at your provider with these settings:

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    restart: unless-stopped
    ports:
      - "127.0.0.1:3000:8080"
    env_file: .env
    volumes:
      - open-webui:/app/backend/data

volumes:
  open-webui:

Put the connection details in a file called .env next to it, readable only by you (chmod 600 .env):

OPENAI_API_BASE_URL=your provider's address
OPENAI_API_KEY=your key

Watch out for. What you type goes to the provider, so this is private from other users, but not from them. Pay-per-use costs are small for chat and add up with long documents. Set a spending limit on the provider's account.

2. A gateway that tracks your spending

What it is. A small program that sits in front of one or more AI providers. Your apps send everything to it, and it forwards the request, keeps a log, enforces budgets and can switch to a backup provider if one is down.

Why it suits this plan. It moves text and does not run a model, so it needs little memory, yet it solves a real problem: knowing what you are spending and giving each app its own key you can revoke.

How to set it up. LiteLLM is the best-known open-source choice. Follow its documentation to define your models and give each of your tools a separate key with its own budget. Keep the port on 127.0.0.1 unless you have a reason not to.

Watch out for. A gateway holds your real provider keys, so protect it like a password manager. Back up its settings and keep it updated.

3. Document OCR on demand

What it is. Turning photographed or scanned pages into text you can search and copy. Receipts, letters, manuals and old documents all become usable.

Why it suits this plan. Tesseract, the standard open-source OCR engine, is not a large AI model. It needs little memory and runs fine on the smallest plans.

How to set it up.

sudo apt install tesseract-ocr ocrmypdf
tesseract scan.png result
ocrmypdf input.pdf searchable.pdf

The first command installs the tools, the second turns an image into result.txt, and the third adds a searchable text layer to a PDF. Install extra language packs if you need them.

Watch out for. Accuracy depends on the scan: straight, high-resolution and well-lit pages work best. Handwriting and complex tables are poor, and need a bigger vision model.

4. Text-to-speech

What it is. Turning text into spoken audio: articles read aloud, voice notes for a project, spoken alerts.

Why it suits this plan. Small speech engines such as Piper are designed to run on weak hardware, including tiny single-board computers, and they work quickly on a CPU.

How to set it up. Install Piper from its own documentation, download one voice file, and pipe text into it to produce an audio file. Voices come in several qualities, and the "medium" ones are a good balance of size and sound.

Watch out for. Voices are licensed individually, so check the terms if you will publish the audio commercially. Very long texts are best split into paragraphs.

5. Search by meaning over your notes

What it is. Instead of finding exact words, you ask "that thing about renewing the domain" and get the right note, even if it never used those words.

Why it suits this plan. Small embedding models are only tens or a few hundred megabytes and are quick on a CPU. Notes and bookmarks are not many documents, so the search itself is light.

How to set it up. The simplest route is a tool that already includes it: Open WebUI and AnythingLLM can index uploaded files. For a do-it-yourself version, a short Python script can embed your text files with a small model and store the results in SQLite or PostgreSQL with the pgvector extension, then compare your question against them.

Watch out for. Indexing a large library is slow on one or two cores, so do it overnight. The first load of an embedding model is the memory peak, so avoid running it alongside other heavy pieces.

6. Transcribing short recordings

What it is. Speech turned into text: voice memos, short interviews, a few minutes of a meeting.

Why it suits this plan. The smallest Whisper models (tiny and base) need very little memory, and the whisper.cpp project runs them well on a CPU. You will not get fast or perfect transcripts, but you will get useful ones, privately.

How to set it up. Build whisper.cpp from its documentation and download the tiny or base model. Convert your audio to 16 kHz WAV with ffmpeg first, then run the program on the file.

Watch out for. On a single core, the work can take longer than the recording itself. Names and technical words are often wrong on the smallest models. For long audio or better accuracy, use a bigger plan, as the next guides in this series explain.

7. A tiny local model for sorting and tagging

What it is. A very small language model (well under one billion parameters) that does narrow jobs: labelling messages as "urgent" or "not", pulling a date out of an email, tagging notes with a topic.

Why it suits this plan. You give the model a precise task and a short answer, which is where small models are surprisingly good. They load in under a gigabyte, and respond fast because the answers are short.

How to set it up. Run Ollama or llama.cpp with a sub-1B model, and call it from a script with a clear instruction such as "Reply with one word: urgent, normal or spam." Test it on fifty real examples before you trust it.

Watch out for. Tiny models are weak at open-ended chat, and make confident mistakes. Do not let their output delete or send anything without a check.

8. Automations that call an AI

What it is. "When X happens, ask an AI to do Y, then do Z." For example: a new support email arrives, the AI summarises it and suggests a reply, and the result lands in your notes.

Why it suits this plan. Workflow tools such as n8n do the plumbing, and the AI step is a call to a model somewhere else. A 2 GB plan runs n8n comfortably as the only major service.

How to set it up. Run n8n in Docker with its data in a volume, reach it through an SSH tunnel at first, and build a workflow with a trigger, an AI step and an action. Start with something harmless, such as summarising and storing, not sending.

Watch out for. Automations can loop and run up costs. Add a limit on how many runs per hour, and keep a human in the loop for anything that sends messages to other people.

9. A chat bot for Telegram or Discord

What it is. A bot in your own chat group or private chat that answers questions, summarises long threads or looks things up using an AI service.

Why it suits this plan. A bot is a small program that waits for messages. It needs only tens of megabytes, and the AI work happens at the provider.

How to set it up. Create the bot with the chat service's own bot setup, then run a short script (Python or Node) under systemd or in Docker that receives messages and forwards them to your gateway or provider. Keep the token in an environment file.

Watch out for. Anyone who can message the bot can spend your money, so limit it to specific users or groups. Be careful what you paste into a group chat.

10. A daily digest, written for you

What it is. A scheduled job that gathers information (a few news feeds, your server's warnings, your sales stats) and sends you one short summary each morning.

Why it suits this plan. A cron job uses almost nothing between runs, and one short request a day costs very little through an outside model.

How to set it up. Write a script that collects the text, sends it to your gateway with a request such as "Summarise the key points in ten lines", and emails or messages you the result. Run it from cron at a fixed time.

Watch out for. Summaries can be wrong or leave out the one thing that mattered, so keep a link to the originals. Do not send logs that contain passwords, personal data or private keys to an outside service.

What does not fit

• A chatbot with the quality of the big services. Models that good do not fit in 2 GB. Use an outside service for that, through idea 1.
• Running a 7-8B model. Needs about 5 to 6 GB for the model alone. The 8 GB guide in this series covers it.
• Several heavy tools together. A chat page, an automation tool and a model will not all fit in 1 GB, and are tight in 2 GB.
• Image generation. Needs a GPU.
• Many users at once. Fine for you and a few friends, not for a public service.

Keeping keys and costs under control

• Create a separate key for each tool, so you can cancel one without breaking the rest.
• Set a monthly spending cap on every provider account, and an alert at half of it.
• Keep keys in environment files with strict permissions, never in scripts or in a git repository.
• Keep every port on 127.0.0.1 and reach tools through an SSH tunnel, or put them behind HTTPS and a login. See the security guide.
• Remember that anything sent to an outside provider is no longer private to you. Check what you are sending.

When to step up

Move to a 4 GB plan when you want a small model running on the server itself, bigger speech models, or several of the tools above running together. The step is not large in cost, and it opens up the local-model ideas in the next guide in this series.

You can also see the cheapest plans and the sales page for current deals.