Vane, the self-hosted answering engine that makes SearxNG your problem too

SearxNG does the searching, and the slim image hands that job to you

Vane splits into two halves, the answer layer and the search layer, and the tag you pull decides who owns the second one. The default tag bundles both, so a single command gives you SearxNG and the app inside one container:

docker run -d -p 3000:3000 -v vane-data:/home/vane/data --name vane itzcrazykns1337/vane:latest

The slim tag assumes you already run SearxNG somewhere and takes the address through a single environment variable:

docker run -d -p 3000:3000 -e SEARXNG_API_URL=http://your-searxng-url:8080 -v vane-data:/home/vane/data --name vane itzcrazykns1337/vane:slim-latest

That one variable is the whole integration surface, and it carries two conditions on your own instance: JSON format has to be enabled in the SearxNG settings, and the Wolfram Alpha search engine has to be enabled. Point the slim image at an instance without JSON output and results never parse. Leave Wolfram Alpha off and calculation answers have no source to cite. The bundled SearxNG already satisfies both, which is the real difference between the two tags.

Speed, Balanced, and Quality mode are named but never defined

Three modes, Speed, Balanced, and Quality, sit on the results page as the main control, and nothing in the repository says what any of them change. There is no documented environment variable or config file mapping a mode to a result count, a page budget, or a model, and the troubleshooting notes never mention them. What is traceable is the surface they act on: source selection covers the web, discussions, and academic papers, domain restriction narrows a query to sites you name, widgets handle small lookups such as weather, calculations, and stock prices, and SearxNG supplies the raw results behind the citations.

The consequence appears the first time you compare two answers. Switch one query from Balanced to Quality and the reply changes, but nothing tells you whether more sources were queried, more pages were turned into text, or a different model was prompted. When you report a wrong answer, the mode name carries no diagnostic weight. Until that table is written down somewhere, treat the label as a hint about intended effort rather than a setting you can reason about or reproduce.

A local OpenAI-compatible server must bind 0.0.0.0 and the key field cannot stay empty

When Vane says you have not configured any chat model providers, even after you entered one, the fix lives on the server side, and three conditions are listed. The server has to be running on 0.0.0.0 rather than 127.0.0.1, on the same port you typed into the API URL. The model name has to match what your local server actually has loaded. And the API key has to be right, or, if your server defines none, you still have to put something in the key field and not leave it empty.

The 0.0.0.0 rule exists because the app runs in a container, where 127.0.0.1 means the container itself. A model server bound to the host loopback is invisible from inside, and the error that comes back is an empty provider list rather than a refused connection, which sends people hunting through Vane's own settings. The key field behaves the same way for servers that ignore authentication but reject an empty string. Both mistakes look like missing configuration, so check the bind address first and the key field second.

Ollama on Linux needs a private IP, Windows and Mac need host.docker.internal

Ollama is the supported local route, wired in through the ollama package, and it hits the same container network wall as any other local model server. The settings screen wants a URL chosen per operating system:

- Windows: `http://host.docker.internal:11434` - Mac: `http://host.docker.internal:11434` - Linux: `http://<private_ip_of_host>:11434`

Windows and Mac get the same hostname because Docker Desktop supplies it. Linux has no equivalent, so you paste the host's private address, which puts a DHCP reservation in front of a text field in a web form, and a changed address becomes a broken setup with no other symptom. The troubleshooting notes give you a first thing to check, the API URL in the settings menu, but a failure there does not distinguish a typo from an unreachable address from a firewall dropping traffic between host and container. If you are on Linux, record the private address somewhere durable before the day you need it.

The named volume covers /home/vane/data while the image creates /home/vane/uploads

Exactly one volume is declared, and it points at /home/vane/data. The compose file shows the whole surface, including the port published straight to your host:

services:
  vane:
    image: itzcrazykns1337/vane:latest
    build:
      context: .
    ports:
      - '3000:3000'
    volumes:
      - data:/home/vane/data
    restart: unless-stopped

volumes:
  data:
    name: 'vane-data'

The image build, meanwhile, creates a second directory, /home/vane/uploads, and no documented command mounts it. So the claim that the -v flags persist your data and uploaded files holds for whatever lands under /home/vane/data and is unproven for uploads. The upload feature accepts PDFs, text files, and images, and the manifest carries mammoth and officeparser for document parsing, so there is real content at stake. If uploads follow the build-time directory, they vanish when the container is replaced. One more trap in the same file: it declares both an image and a build context, so a compose run builds from your checkout and tags the result with the published name, which can shadow the release you meant to run.

The image builds with yarn and a frozen lockfile while the manual path says npm i

Two install routes, two package managers, and the repository ships both signals. The Docker build copies package.json and yarn.lock, then installs against a frozen lockfile:

yarn install --frozen-lockfile --network-timeout 600000

The non-Docker path, a few steps later in the same guide, says:

npm i

The guide does say Docker is preferred because it simplifies dependencies and environment variables, and the file layout backs that up. Both routes then run the same build, which pins the bundler to webpack instead of letting Next.js choose, and both start the production server on port 3000. The practical difference is reproducibility: a container build fails loudly when package.json and yarn.lock disagree, while a manual npm install resolves from package.json and leaves the committed lockfile unused, so a source install and the published image are not guaranteed to carry the same dependency tree. If you build from source to match a running container, check which lockfile you actually installed with.

The full image clones SearxNG source during the build, unpinned

The bundled SearxNG is not a package install, it is a build-time clone. The image creates a searxng system user, copies three configuration files into /etc/searxng, switches to that user, clones the SearxNG repository into /usr/local/searxng/searxng-src, creates a virtual environment at /usr/local/searxng/searx-pyenv, and installs into it. The same stage adds uwsgi with its Python plugin, plus a Playwright shell Chromium install with system dependencies, on a node:24.5.0-slim base carrying python3, sqlite3, and a compiler toolchain.

Two consequences follow. A rebuild needs a working git clone, a Python toolchain, and a long network timeout, so a locked down or offline build host cannot reproduce that image, and the machine doing the build carries all of it. And because the clone names no tag and no commit, the metasearch half of your image depends on when the build ran, while the Node half stays pinned. Two images built a month apart can carry different search engines behind the same itzcrazykns1337/vane:latest tag, and nothing in the repository records which one a running container has.

History lands in local SQLite and no sign-in step ever appears

Search history is kept locally, and the stack behind that claim is visible in the manifest: better-sqlite3 for the database, drizzle-orm for the queries, a drizzle directory of migrations, a drizzle.config.ts, and a data directory that the named volume mounts over. Your queries never have to leave a disk you control. The same choice removes the hosted features, since no account is created during setup, there is no sync, and no share link appears in the documented flow. Setup is a form for API keys, models, and the SearxNG URL, and after that the instance is yours alone.

That has a cost the guide does not discuss. Port 3000 is published to the host by both the run command and the compose file, with no authentication package in the dependency list, no user table, and no reverse proxy example. Anything that can reach that port can read your saved queries. If that is not acceptable, hardening the deployment is work the project hands back to you. On freshness, the last commit landed on September 1, 2026, while the newest tag, v1.12.2, is dated April 10, 2026, so the published release trails the working tree by about five months, with v1.12.1 and v1.12.0 both dated late December 2025.

Editorial conclusion

Vane belongs to people who already run containers and want their search history to stay on a disk they mount. Skip it if you need a hosted service, a shared workspace, or documented behavior for the three search modes. Before adopting, confirm your SearxNG instance returns JSON with Wolfram Alpha enabled, and check that any local model server binds 0.0.0.0 instead of 127.0.0.1, since both appear as failure causes in the troubleshooting notes.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes