One winner per job, and why

Self-hosted AI tools

Tools grouped by the job they do, with one winner and one runner-up each. Every entry states how I know: whether it runs in my production setup, whether I installed and evaluated it, or whether I am judging from documentation alone.

Updated 2026-10-24 7 jobs No paid placement
The picks

Run local models

You have a GPU or a decent CPU and want to run an open model on your own hardware.

Winner
Ollama
MIT · Runs in the author's production setup

One binary, one command per model, an HTTP API that everything else speaks, and model tags that pin a quantisation so results are reproducible. It is the least interesting choice, which is what you want from the layer everything else sits on.

Watch out: It is not a serving stack. No batching, no multi-tenant auth, no request queue. Past a handful of concurrent users you want vLLM instead.

Runner-up
llama.cpp
MIT · Installed and evaluated, not in production

The engine underneath several of these tools. Direct control over context, offload and quantisation, and usually the first to get new model support.

Watch out: You are now maintaining build flags and a launch script. Choose it when you need a specific knob Ollama does not expose.

Chat with your own documents

You have PDFs, notes or contracts and want to ask questions across them locally.

Winner
AnythingLLM
MIT · Installed and evaluated, not in production

The shortest path from a folder of documents to a usable chat. Handles the embedding, the vector store and the interface in one container, and lets you point it at a local Ollama model so nothing leaves the box.

Watch out: Retrieval quality on messy PDFs is ordinary. If your documents have complex tables, you will fight it.

Runner-up
RAGflow
Apache-2.0 · Installed and evaluated, not in production

Substantially better document parsing — layout-aware chunking that survives tables and multi-column pages. Worth the extra container when document quality is the actual problem.

Watch out: Heavier: several services, more RAM, more to upgrade. Not the thing to run on a small VPS.

Automate recurring work

Something should happen on a schedule or a trigger, and sometimes a model should be part of it.

Winner
n8n
Sustainable Use License (source-available) · Runs in the author's production setup

The glue between services, with a visual editor for the flows you only touch monthly and code nodes for the parts that need it. Self-hosted, and the model call is one node rather than a project.

Watch out: The licence is source-available, not OSI-open. Read it before building a product on it. Upgrades occasionally need attention.

Runner-up
Systemd timers + a small script
n/a (part of the OS) · Runs in the author's production setup

For genuinely simple schedules, a timer and forty lines of Node or Python is more legible at 2 a.m. than any visual editor. It also never needs upgrading.

Watch out: You own the error handling, retries and logging. That is the whole trade.

Run an agent that does real work

You want an agent with tools, memory and a schedule, not a chat window.

Winner
OpenClaw
MIT · Runs in the author's production setup

A gateway process with a dashboard, a plugin catalog, and a shape that survives being left running: sessions persist, tools are explicit, and the human-approval boundary is configurable rather than implied.

Watch out: Messaging integrations are the friction. iMessage in particular needs a Mac or a paid relay; test delivery before trusting it with anything that matters.

Runner-up
Hermes Agent
check upstream · Runs in the author's production setup

Stronger at scheduled and recurring jobs — if most of your list starts with "every morning", it fits the shape of the work better.

Watch out: Fewer integrations and a smaller ecosystem. Verify the licence before depending on it commercially.

Know when something breaks

You need to hear about downtime before a customer tells you.

Winner
Uptime Kuma
MIT · Runs in the author's production setup

One container, a clean UI, HTTP and TCP checks, and notifications to almost anywhere. It does the job in an evening and then stays quiet.

Watch out: It watches, it does not explain. Pair it with real logs, and make sure the monitor is not on the same box as the thing it watches.

Runner-up
Healthchecks.io (self-hosted)
BSD-3-Clause · Judged from documentation and issue tracker; not run

Better model for cron jobs specifically: the job pings on success, and silence is the alarm. Catches the failure mode where a scheduled task simply stops running.

Watch out: Judged from documentation, not run. Different question from uptime — it is about jobs, not endpoints.

Store the application's data

The site or tool needs a database on one box.

Winner
SQLite
Public domain · Runs in the author's production setup

A file, no server, consistent backups with one command, and in Node it is part of the runtime. For one application on one machine it is not a compromise, it is the correct answer.

Watch out: Concurrent writers from multiple machines is not its world. The moment you need that, move to Postgres deliberately, with numbers.

Runner-up
PostgreSQL
PostgreSQL License · Runs in the author's production setup

When you genuinely need concurrent writers, extensions or an analytics workload. Well understood, well documented, and a reasonable default for anything with more than one app writing.

Watch out: It is a server: it needs patching, tuning, and a real backup routine. Do not run it because it sounds more serious.

Serve HTTP with certificates

You need TLS for several domains without thinking about renewal.

Winner
Caddy
Apache-2.0 · Runs in the author's production setup

Automatic HTTPS that simply works, a config file short enough to read in one sitting, and sane defaults. For a handful of sites it removes an entire category of mistake.

Watch out: Smaller ecosystem than nginx, and fewer people have opinions about it — which cuts both ways when you need help.

Runner-up
Traefik
MIT · Runs in the author's production setup

The better fit when routing should follow containers automatically: labels on the container, no config file to edit, certificates issued on demand. This site's current host uses it.

Watch out: Docker-provider magic makes some failures opaque. When a route does not appear, the reason is in the Traefik logs and nowhere else.

How these were chosen

Criteria

  • Does it do the job without a second tool bolted on?
  • Can one person operate it: install, upgrade, back up, restore?
  • What does it cost in RAM and maintenance, not just licence?
  • When it breaks at 2 a.m., is the failure legible in logs?

What the labels mean

  • ran — Runs in the author's production setup
  • trial — Installed and evaluated, not in production
  • docs — Judged from documentation and issue tracker; not run

Limits

  • These are one operator's judgements for a small business, not a feature matrix.
  • A tool that is worse here may be better at your scale. The runner-up is often the right answer.
  • Nothing here is paid placement. No affiliate links are used anywhere in this table.