Published

SearXNG

Self-hosted metasearch engine: it sends each query to many search services at once and merges the results, without cookies or profiling toward those services. Fits a household or team that wants its own search page, or a private search backend for AI tools.

Resources by load level

What the app itself needs at each level, next to what we recommend for a server that runs only this app.

Level	What it means	App requirements	Recommended
LightEstimate	Up to 5 users, ~300 searches/day (1 at a time), default engines and settings, favicons off; e.g. a household search page or one AI chat app's web search.	0.5 vCPU · 0.5 GiB RAM · 0.6 GiB disk	0.72 vCPU · 2.1 GiB RAM · 10.005 GiB disk
MediumEstimate	Up to 25 users or several AI tools, ~3,000 searches/day, up to 4 searches at once (Granian's 4 blocking threads), default engines, favicons off.	1 vCPU · 1 GiB RAM · 0.85 GiB disk	1.32 vCPU · 2.7 GiB RAM · 10.293 GiB disk
HeavyEstimate	Up to 100 users or busy AI agents, ~15,000 searches/day, 4 searches at once most of the day, one Granian worker as upstream advises, favicons off.	1.5 vCPU · 1.5 GiB RAM · 1.35 GiB disk	1.92 vCPU · 3.3 GiB RAM · 10.868 GiB disk

Recommended = app requirements + system baseline + safety headroom, under sizing policy 2026.10.0. Options stay at their defaults. “Estimate” means the sources give no number for that case, so it is worked out from them by the method stated under Components. How the numbers are built

Size it in the Stack Sizer

Ready-to-run files

Support level Supported

Compose template from the official sources; not yet verified by a run.

Create docker-compose

Components

What each component needs at each load level, before baseline and headroom.

vCPU / GiB RAM / GiB disk
Component	Light	Medium	Heavy	Sources
SearXNG (app)	0.5 / 0.5 / 0.6	1 / 1 / 0.85	1.5 / 1.5 / 1.35	[5][11][13][14][18][19][23][25][26][27]

How the estimates are worked out

SearXNG · Light: No upstream figure. RAM: a maintainer runs instances on 512 MB VMs (0.477 GiB), and one worker used 150 MB in a user report; rounded up to 0.5 GiB. vCPU: that VM has 1 vCPU for everything; one search at a time mostly waits on engines, so half a core. Disk: image 98,301,157 B compressed (0.092 GiB) + 271,150,592 B unpacked (0.253 GiB), both kept by the containerd store = 0.344 GiB. Data is caches only: the favicon cache is capped at 50 MB and off by default, other caches expire after 7 days. 0.344 + 0.25 GiB caches and settings → 0.6.
SearXNG · Medium: RAM: the light 0.5 GiB ×2 for 4 searches in flight (GRANIAN_BLOCKING_THREADS=4), each holding engine responses, plus the image proxy, which the docs say uses memory → 1 GiB. vCPU: one Granian worker (default 1) is one Python process, so about one core at most. Disk: image 98,301,157 B compressed (0.092 GiB) + 271,150,592 B unpacked (0.253 GiB), both kept by the containerd store = 0.344 GiB. Data is caches only: the favicon cache is capped at 50 MB and off by default, other caches expire after 7 days. 0.344 + 0.5 GiB → 0.85.
SearXNG · Heavy: vCPU: one core for the Python worker kept busy, plus 0.5 for Granian's I/O runtime and TLS to the engines → 1.5. RAM: medium 1 GiB + 0.5 GiB for larger in-memory caches under steady load → 1.5. The docs advise against more workers, so this is the ceiling of one container. Disk: image 98,301,157 B compressed (0.092 GiB) + 271,150,592 B unpacked (0.253 GiB), both kept by the containerd store = 0.344 GiB. Data is caches only: the favicon cache is capped at 50 MB and off by default, other caches expire after 7 days. 0.344 + 1 GiB → 1.35.

Ports

Public ports are meant to be reached from outside the stack, usually through a reverse proxy; internal ones stay on the stack's own network.

Component	Port	Exposure	Purpose	Sources
SearXNG	8080/tcp	Public, through a proxy	Web UI and search API (Granian HTTP); serve through an HTTPS reverse proxy	[1][5]

Every port in the catalog, with conflicts between apps

User and permissions (UID/GID)

The user each container's process runs as, and the paths it writes to. A bind mount for one of these paths must be writable by that UID:GID.

Component	UID:GID	User	Starts as root	Writes to	Sources
SearXNGDerived	0:0	`root`	No	`/etc/searxng/var/cache/searxng`	[3][5][6]

SearXNG: The image sets no USER, so entrypoint.sh runs as root: it chowns /etc/searxng and /var/cache/searxng to searxng (977:977) unless FORCE_OWNERSHIP=false, runs update-ca-certificates, then execs granian without dropping privileges, so the server stays uid 0.

Storage growth

How much each component's data grows per month at each load level, on top of the disk in the profile. A value marked Assumption is ANAROQ's stated assumption, not a figure from the sources; the notes say what it rests on.

GiB per month
Component	Light	Medium	Heavy	Sources
SearXNGDerived	0	0	0	[9][18][19]

What the growth figures rest on

SearXNG: SearXNG keeps no search history. Its caches are bounded: values expire after 7 days with hourly maintenance, and the favicon cache (off by default) is trimmed to its 50 MB limit. The preset disk already holds them; enabling favicons with a larger limit adds up to that limit.

Upgrade and rollback

How to move to a new version safely, and how to go back if it fails.

Back up first

Copy the config volume (/etc/searxng: settings.yml and any limiter.toml or favicons.toml). The data volume holds caches only. [9][18]

Upgrade steps

SearXNG is a rolling release with date-sha image tags and no release notes: check the commit history between your tag and the target, especially commits marked [mod] container. [24][30][31]DerivedUpstream publishes no changelog; the breaking container changes below were found in commits of that kind.
Set the new pinned tag in the Compose file, then run docker compose pull and docker compose up -d. [9]
settings.yml in /etc/searxng is only created when missing, so an update never rewrites it; compare it with the current settings docs after the update. [3][29]

Roll back

Pin the previous tag and run docker compose up -d; if settings.yml was changed for the new version, restore the config backup. [9][24]DerivedUpstream documents no downgrade. SearXNG stores no user data, only settings and caches, so running the older tag is inferred to be safe.

Known breaking changes

In 2026.6.16: The settings template became minimal (use_default_settings, secret_key, image_proxy) and is no longer checked against an existing settings.yml for changes. [4][29]
In 2026.3.28: Compose moved into the searxng repository (services core and valkey, ./core-config mount); searxng-docker is superseded. Migrating means moving the old config files and pointing the Valkey URL at valkey. [9][10][30]
In 2025.7.4: Granian replaced uWSGI in the image: uWSGI settings no longer apply (Granian is set with GRANIAN_* variables), and the entrypoint chowns the volumes on every start unless FORCE_OWNERSHIP=false. [13][31]

Limits

The JSON API is off by default (search.formats is html only): AI tools such as Open WebUI get 403 Forbidden until json is added to search.formats in /etc/searxng/settings.yml and the container is restarted. [16][17][28]
SearXNG has no index of its own: results come from upstream engines, which see the server's IP and may answer with CAPTCHAs or block it, so result quality varies over time. [12][20][21]
Not set up as a public instance: the limiter (bot protection) is off and there is no Valkey. Turning it on needs Valkey and a limiter.toml whose trusted_proxies include the proxy, since only 127.0.0.0/8 and ::1 are trusted by default. [11][12]
One Granian worker with 4 blocking threads; upstream advises against more workers (more resources, bot detection issues), so one container does not scale past the heavy level. [5][13][14]

Security

There are no user accounts: preferences live in browser cookies, and anyone who reaches the URL can search through your server's IP. Keep a private instance behind a VPN or proxy authentication. [12][20]
SEARXNG_SECRET overrides secret_key in settings.yml; SearXNG exits at start if the key is still the placeholder ultrasecretkey. Keep it secret and stable. [7][8][11]
The container runs as root (no USER in the image) and chowns its volumes on every start; set FORCE_OWNERSHIP=false if the volumes must keep other owners. [3][6][9]

Backup

Back up the config volume (/etc/searxng): settings.yml and any limiter.toml or favicons.toml. /var/cache/searxng holds caches that SearXNG rebuilds, and there is no search history to keep. [9][18][19]