Degoog vs SearXNG: which should you self-host?

Degoog vs SearXNG: the short answer

Degoog vs SearXNG comes down to one trade. SearXNG is the mature metasearch engine with its engines built in. Degoog is a younger, modular one where almost everything, engines included, is an extension you install at runtime. If you run a public instance, or you need search that works the moment the container starts, stay on SearXNG. If you run a private instance for yourself and want a plugin system you can shape, Degoog 1.1.0 is worth a trial on the same VPS, behind a password and bound to localhost.

This guide is for someone who already runs SearXNG. It pins Degoog to the 1.1.0 image tag and SearXNG to the dated tag 2026.10.17-2a6fc07be. Every behaviour described here comes from the documentation for those versions as of 17 October 2026. Where the docs do not answer a question, the guide says so.

What each project is

Both projects are metasearch engines. A metasearch engine sends your query to other search engines, collects their results, and shows them on one page. Neither one keeps its own index of the web.

SearXNG's documentation describes it as "a free internet metasearch engine which aggregates results from up to 264 search services". That figure is the project's own count of the services it can query. The docs do not say how many of them a fresh install enables. SearXNG is written in Python and licensed AGPL-3.0 (GNU Affero General Public License, version 3). Its official image is searxng/searxng on Docker Hub, mirrored at ghcr.io/searxng/searxng. If you are new to it, the full guide to self-hosting SearXNG covers the install end to end.

On GitHub, Degoog describes itself as a "Search engine aggregator with a comprehensive plugin/extension system". Its README calls it "a more modular lighter alternative" inspired by SearXNG. It is written in TypeScript, runs on the Bun JavaScript runtime, and is also licensed AGPL-3.0. The 1.1.0 Dockerfile builds on oven/bun:1.3.14-alpine and exposes port 4444. The image is ghcr.io/degoog-org/degoog. Older posts and search results point at fccview/degoog and ghcr.io/fccview/degoog. Those are earlier paths from the original developer. Use the degoog-org paths.

The shared license matters if you plan to modify either project and offer it to other people over a network. AGPL-3.0 requires you to make your modified source available to those users. Both projects carry the same obligation, so the license does not separate them.

How mature is Degoog compared with SearXNG?

The SearXNG repository on GitHub was created on 12 April 2021, and it was still receiving commits on the day this guide was written. Its history before that belongs to the older searx project, which the comparison of searx and SearXNG covers.

The Degoog repository was created on 4 March 2026. Its early 0.x releases were labelled "Beta", and 0.15.0 was the first to be called a "Stable Beta". Version 1.0.0, titled "FIRST STABLE", was published on 3 October 2026. Version 1.1.0, "Stable Hippo", followed on 10 October 2026. That is about seven months from the first commit to the current release.

The Degoog FAQ is direct about this. It says SearXNG "came first and is way more mature". It also says Degoog bundles fewer engines and moves most features into extensions. Treat Degoog as a young project with a fast release pace. Expect changes between minor versions, and read the release notes before each upgrade. The 1.1.0 notes say engines and the lolcat and 4play transports need the matching update from that version. Pinning the core image does not pin the extensions you installed from the Store.

Release pinning: what a version means for each

Degoog publishes semantic versions as git tags without a v prefix, and matching image tags. The GitHub package page lists 1.1.0 and 1.1.0-arm64 next to latest. Pin 1.1.0. The getting-started docs show :latest, which means a docker compose pull can move you to a new minor version without warning.

SearXNG has no GitHub releases. Its releases page is empty. It publishes date-stamped container tags in the form YYYY.M.D-shortsha instead, often several per day. The newest tag on Docker Hub on 17 October 2026 was 2026.10.17-2a6fc07be, which matches the documentation build 2026.10.17+2a6fc07be. Pin a tag like that and move it forward on purpose. The SearXNG install docs also use :latest in their example, so the same advice applies.

Run both on one VPS to compare

You do not need to replace SearXNG to try Degoog. Run them side by side on different ports, both bound to 127.0.0.1, so neither is reachable from the internet while you test. These steps assume Docker Engine and the compose plugin are already installed.

This is SearXNG, pinned, taken from the manual example in its Docker docs:

mkdir -p ./searxng/config/ ./searxng/data/
cd ./searxng/
docker run --name searxng -d \
  -p 127.0.0.1:8888:8080 \
  -v "./config/:/etc/searxng/" \
  -v "./data/:/var/cache/searxng/" \
  docker.io/searxng/searxng:2026.10.17-2a6fc07be

Before you expose it anywhere, set secret_key in ./config/settings.yml. The server settings docs say it must not stay at the placeholder value change this!.

Degoog needs a data directory owned by UID and GID 1000. The container runs as 1000:1000 unless you change PUID and PGID, so a directory owned by root is one the container cannot write its settings into.

mkdir -p ~/degoog/data
cd ~/degoog
sudo chown -R 1000:1000 ./data
openssl rand -base64 24

Copy the random string that openssl prints. Base64 output never contains a comma. That matters because DEGOOG_SETTINGS_PASSWORDS is a comma-separated list, so a comma inside a password would split it into two passwords. Save the file below as ~/degoog/docker-compose.yml. It is the project's simple.yml example with three changes: the tag is pinned, the port is bound to localhost, and the container gets a fixed name so the commands later in this guide can find it.

services:
  degoog:
    image: ghcr.io/degoog-org/degoog:1.1.0
    container_name: degoog
    volumes:
      - ./data:/app/data
    ports:
      - "127.0.0.1:4444:4444"
    restart: unless-stopped
    environment:
      DEGOOG_SETTINGS_PASSWORDS: "PASTE_THE_RANDOM_STRING_HERE"
      DEGOOG_PUBLIC_INSTANCE: "false"

Start it and check it:

docker compose up -d
docker compose logs degoog | grep -i "temporary settings password"
ss -tln | grep 4444

The grep on the logs should print nothing. Degoog prints a yellow "Temporary settings password" banner only when DEGOOG_SETTINGS_PASSWORDS is unset, and that one-off password changes on every restart. If you see the banner, the variable did not reach the container. The ss line should show 127.0.0.1:4444. If it shows 0.0.0.0:4444, the port mapping is missing the address, and any network that can reach the VPS can reach the instance.

To open it from your laptop, use an SSH tunnel such as ssh -L 4444:127.0.0.1:4444 you@your-vps, then browse to http://localhost:4444. A setup tour starts on the first visit.

Engine coverage: built in or installed

This is the biggest practical difference. A fresh SearXNG container answers queries straight away, because its engines are Python modules shipped inside the image under searx/engines. You turn them on and off in settings.yml. If you have tuned that list before, the guide to which SearXNG engines to enable and disable still applies.

Degoog ships with no engines. Its engines page says "None ship with the app". You install engines from the Store, and the setup tour will not let you continue until at least one is installed. The docs publish no count of available engines, so there is no fair number to set against SearXNG's 264.

Degoog has a second route to engines: an experimental SearX compatibility layer, switched on under Settings, Server. It imports SearXNG engine .py files from upstream. Imports are test-loaded first, and a failed load leaves nothing behind. The layer needs Python on the host, and DEGOOG_PYTHON_BIN points it at a different binary. The 1.1.0 notes say more SearXNG-compatible engines were added. I could not confirm from the docs whether the official Docker image includes Python. Check your own container:

docker exec degoog sh -c 'command -v python3 || echo missing'

A printed path means Python is present. missing means the image has nothing to run imported engines with.

How each handles rate limits and blocked engines

Two different problems hide under the words "rate limit". One is upstream engines throttling your instance. The other is your instance throttling the bots that hit it. Keep them apart, because each project solves them differently.

Upstream throttling. Every metasearch engine sends automated requests to the big search engines. Once those engines notice, they answer with HTTP 429 (too many requests) or a CAPTCHA page. SearXNG handles this with outgoing proxies, used round-robin when you set several, and with per-engine retry_on_http_error lists such as [403, 429], which retry through a different proxy and source IP. Our guide to SearXNG 429 errors walks through reading those failures, and routing SearXNG engine requests through a proxy covers the proxy setup.

Degoog's docs have no single rate-limit setting. A throttled engine shows "0 results" in the sidebar. Hovering over it can show a reason such as "Rate limited (429)" or "Blocked by the engine". The documented fix works per engine: open Settings, Engines, Configure, Advanced, choose a different outgoing HTTP client (Degoog calls it a transport), save, and retry. The built-in transports are Fetch, Curl, Curl Fallback and Curl Impersonate. Curl Fallback retries on 429 by itself. Curl Impersonate needs the curl-impersonate binary. The Store adds more, including FlareSolverr and Browserless. You can also give an engine its own timeout and user agent, or rotate it through proxies. Since 1.1.0, an expired rotating proxy gets a 10-minute cooldown per engine.

Protecting your own instance. SearXNG has the limiter: bot detection plus IP rate limiting. It needs a Valkey database and is turned on with limiter: true under server: in settings.yml. The sample config sets it to false. The guide to limiter.toml and Valkey covers it. Degoog takes a different approach. Honeypot traps and browser verification are on by default, with 24-hour bans. Degoog also ignores X-Forwarded-For by default, so read the proxy-trust options on its server settings page before you put it behind a reverse proxy.

What about "Degoog does not get rate limited"? You will see this claim in forum threads. It comes from one user in a Lemmy thread about the Degoog beta, posted about seven months before this guide: "Not sure why degoog is not getting rate limited like SearxNG on the same system and same VPN." The maintainer replied in that thread that "Bing does get blocked quite often" for them. It is one person's report about a beta version. Both tools send automated queries to the same engines, so expect both to be throttled, and judge by your own sidebar and logs.

Memory use: a claim to measure

The maintainer, fccview, wrote in the Lemmy announcement for version 0.15.0, about six months before this guide, that "the app itself is extremely light (about 50mb to 70mb ram usage whilst idle". That is a self-reported number for a much older version. The docs give no memory figure and no minimum. I did not measure 1.1.0. Measure it on your own box, first idle and then during a few searches:

docker stats --no-stream degoog searxng

Compare the MEM USAGE column for both containers. Extensions add to Degoog's number, and a transport that drives a headless browser adds a lot, so measure the setup you would actually run.

Security: extensions run code on your server

This section matters more than any feature comparison. Degoog's README says it plainly: "an unlocked instance lets anyone install extensions, which runs code on the server". An extension is code. If the settings page has no password, anyone who can load your instance can install code. That code runs inside your container, with the container's access to your data volume and network.

Set DEGOOG_SETTINGS_PASSWORDS before the first start of any instance the internet can reach. Degoog reads the variable only from the environment. No settings page or file can set it. There is also DEGOOG_DANGEROUSLY_NO_PASSWORD=true, which removes the gate entirely. Never set it on a reachable instance. For a public instance, the FAQ also recommends DEGOOG_PUBLIC_INSTANCE=true. Public mode limits the visitor settings page and moves the admin panel to /admin. Serve it over HTTPS (HTTP over TLS, transport layer security) from a reverse proxy you control.

The password guards the install button. Vetting what you install is still your job. The README says community-store extensions have "only been INITIALLY vetted". The store docs add that extensions are not sandboxed or reviewed after they are listed, and that anyone can publish a store. Whoever controls a store's URL controls the code that arrives on your machine. The only curated store is github.com/degoog-org/official-extensions. The Degoog team maintains it, it is added automatically, and you cannot remove it. Read an extension's source before you install it, the same way you would read a script before you pipe it into a shell. Degoog also offers DEGOOG_OUTGOING_ALLOWED_HOSTS, an allowlist for outgoing requests, which limits where a misbehaving extension can send data.

SearXNG works differently. Its engines are Python modules in the repository, so they arrive inside the image you chose to deploy. Changing an engine means changing code and building your own image. The admin edits settings.yml to enable or disable the engines already there. A visitor to your SearXNG instance has no button that adds code. SearXNG still needs care in public, with the limiter on and sensible settings, and whether SearXNG is safe and hardening a public SearXNG instance cover that side. The runtime code-install risk simply has no equivalent there.

Can Open WebUI or an agent use Degoog as if it were SearXNG?

Partly, and only after you change two things. Degoog can answer its API (application programming interface) requests in SearXNG's JSON shape, but only after you enable "Serve the SearXNG API shape" in Settings, Server. With it on, /api/search honours format=json. Requests without that parameter are unaffected.

The URL changes too. SearXNG serves search at /search. Degoog's API docs do not document a /search route. They tell Open WebUI users to set the SearxNG Query URL to the instance followed by /api/search, for example http://127.0.0.1:4444/api/search. If Open WebUI runs in its own container, 127.0.0.1 means that container, not the host, so use an address Open WebUI can actually reach. The rest of the Open WebUI steps match connecting the SearXNG JSON API to Open WebUI: turn on Web Search in the admin settings and pick searxng as the engine.

I could not confirm whether the response matches what each client reads. Degoog's docs do not list the fields of the SearXNG-shaped response, and SearXNG's search API page does not list its JSON fields either. I did not run Open WebUI against Degoog. Compare the two responses yourself, after you install at least one Degoog engine:

sudo apt install -y jq
curl -s 'http://127.0.0.1:8888/search?q=linux&format=json' | jq '.results[0] | keys'
curl -s 'http://127.0.0.1:4444/api/search?q=linux&format=json' | jq '.results[0] | keys'

The SearXNG line may fail to parse. If so, run curl -s -o /dev/null -w '%{http_code}\n' 'http://127.0.0.1:8888/search?q=linux&format=json'. A 403 means SearXNG is refusing JSON, because json is not listed under search.formats in settings.yml. The sample config lists only html, and the docs say an unset format returns 403 Forbidden. Add json, then run docker restart searxng. Once both lines print, compare them. A field in the first list that is missing from the second is a field a SearXNG client may look for and not find.

Agent tools raise a separate question. A SearXNG search tool in a coding agent, like the ones in giving agents web search through SearXNG, often has the /search path and the field names built in. Whether a given tool works with Degoog depends on two things: whether it lets you set the full path, and whether it reads only fields Degoog returns. I did not test any agent tool. There is one more catch. Degoog's search routes are open by default, but once you protect them, callers must send Authorization: Bearer YOUR_API_KEY, and requests without it get a 401. The API key section appears only once DEGOOG_SETTINGS_PASSWORDS is set. Degoog's docs warn you to confirm that your client can send custom headers, and many SearXNG clients have no field for one.

Who should stay on SearXNG, and who should try Degoog

Stay on SearXNG if you run a public instance. Its engines are fixed at deploy time, so no visitor path adds code. The limiter with Valkey is a documented, mature answer to bot traffic. Degoog can be made safe for public use, but that safety depends on a password you must never drop and on every extension you choose to trust.

Stay on SearXNG if other tools depend on it. Open WebUI and agent search tools expect /search and SearXNG's JSON. Degoog's compatibility mode moves the path, and its response fields are undocumented. Test it before you count on it as a swap.

Stay on SearXNG if you want search that works with no extra steps. It answers from the first start. Degoog answers nothing until you install engines.

Try Degoog if you run a private instance for yourself or a few trusted people. Bind it to localhost or reach it only over a private network, for example the tailnet you would use for a Tailscale exit node on a VPS, and set a settings password. In that setting the extension model works in your favour: you add the engines and transports you want and leave out the rest.

Try Degoog if you like to build things. Engines and transports are both extensions, and the 1.x line is moving fast. Read each extension's code before you install it, pin 1.1.0, and keep your SearXNG container running next to it until Degoog has earned the job.

FAQ

Is Degoog a drop-in replacement for SearXNG?

No. Degoog can serve a SearXNG-shaped JSON response, but only after you enable "Serve the SearXNG API shape" in Settings, Server, and its path is /api/search, not /search. Its docs do not list the response fields, so test each client, such as Open WebUI or an agent's search tool, before you switch. Degoog also ships with no engines, so a fresh instance returns nothing until you install some from the Store.

Is it safe to expose Degoog to the internet?

Only with DEGOOG_SETTINGS_PASSWORDS set before the first start. Degoog's README warns that an unlocked instance lets anyone install extensions, and extensions run code on your server. If the variable is unset, Degoog prints a one-off "Temporary settings password" in the logs, and it changes on every restart. For a public instance the FAQ also recommends DEGOOG_PUBLIC_INSTANCE=true, served over HTTPS from a reverse proxy you control. Community-store extensions are only initially vetted, so read their code before you install them.

Does Degoog avoid the rate limits that SearXNG hits?

Do not count on it. The claim comes from a single user's report about a beta version, and the maintainer replied that Bing still blocks their own instance quite often. In Degoog a throttled engine shows "0 results", with a reason such as "Rate limited (429)" on hover. The documented fix is to switch that engine to a different transport, such as Curl Fallback, which retries on 429.

Which versions of Degoog and SearXNG should I pin?

Pin Degoog to ghcr.io/degoog-org/degoog:1.1.0, the current stable release as of 17 October 2026. Update your Store extensions along with it, because the 1.1.0 release notes say engines need the matching update. SearXNG has no numbered releases. It publishes date-stamped tags such as 2026.10.17-2a6fc07be, often several a day, so pick one and move it forward on purpose instead of using latest.

How much RAM does Degoog use?

The maintainer reported about 50 to 70 MB idle for version 0.15.0, months before the 1.x releases. The docs give no figure and no minimum, and nobody has published a measurement for 1.1.0. Run docker stats --no-stream degoog with the extensions you actually use, because a transport that drives a headless browser adds its own memory.