Combined degoog + SearXNG in a single container — would you accept a PR?

[SiaoZeng]

Hey! Love the project and the shoutout to SearXNG in the README.

I built a combined deployment that runs degoog + SearXNG in a single Docker container — SearXNG as a headless API backend (242+ engines), degoog as the frontend. Connected via a custom SearXNG engine + a manager plugin.

What it does

• Single container — supervisord runs both degoog (Bun) and SearXNG (Python/Flask)
• SearXNG Custom Engine — bridges SearXNG's JSON API into degoog's engine system
• Engine Manager Plugin — web UI to browse/toggle all 250 SearXNG engines (filter by category, batch save, auto-restart)
• Dynamic activation — SEARXNG_ENABLE_ENGINES env var to pick engines at startup
• CLI tool (tools/dg) — terminal search against the degoog API
• Nothing changes for the default degoog setup — the combined mode is opt-in via Dockerfile.combined

Why it could be useful

Gives degoog users instant access to SearXNG's engine catalog (arXiv, PubMed, HuggingFace, npm, crates.io, StackOverflow, 200+ more) while keeping degoog's UI, plugin store, and extension system.

Working implementation

https://github.com/SiaoZeng/degoog (commit 0a8ac4f)

Container is ~200MB, starts in under 5 seconds.

Questions

1. Would this be welcome as a PR?
2. Should it live alongside the existing Dockerfile, or in a separate directory?
3. Any concerns about the approach?

Happy to adapt based on feedback.

[fccview]

Hey!
I had a quick glance at the commit, it's a lot..

I mean, it really goes absolutely outside of scope with the project, so I don't think I'd be accepting that as a PR.

That said, it actually would be extremely easy to implement searxng as a custom engine in a store, I can't imagine it being more than 200 lines of code to achieve pretty much the same exact result :)

[SiaoZeng]

Ha, fair point — the combined container was definitely overscoped for upstream. Thanks for the honest feedback!

So if I understand correctly, the right approach would be:

1. SearXNG engine as a store extension — just the custom engine file (~140 lines) that queries a user-provided SearXNG instance via its JSON API (/search?format=json&engines=...). Users point it at their own SearXNG and get all 242+ engines in degoog.

2. Optionally a second store plugin for managing which SearXNG engines are active (a small settings page that talks to SearXNG's /config endpoint).

Would that be welcome in the official store (fccview-degoog-extensions), or should I publish it as a third-party store repo?

[fccview]

That sounds sensible, I love the plugin idea to set engines on and off (although engines have settings themselves so you could just do everything within the engine, it will increase how big the file is, but it's understandable)

I'd be happy either way, however I always push users to have their own store as it creates a healthier more vary environment. I'll definitely add your store to the readme if you make it, and it may encourage you to create more extension as you'd have the freedom to merge at will :)

Entirely up to you on this one ♥️

[SiaoZeng]

Done! Created a store repo with the engine + manager plugin:

https://github.com/SiaoZeng/degoog-searxng-extensions

• engines/searxng — ~110 lines, queries SearXNG's JSON API, configurable URL/categories/engines/safesearch
• plugins/searxng-manager — web UI to toggle individual SearXNG engines

Users can install via Settings > Store by adding the repo URL. Would love to get it listed in the README if you think it's solid enough!

[fccview]

That was fast!
I'll add it to the readme for next release but I have a few pointers looking at the code

• In the engine export const outgoingHosts = ["localhost", "127.0.0.1"]; will make it so searxng will only work on localhost, you may need to use ["*"] for the outgoing hosts so people can add custom urls instead of localhost
• the plugin seems redundant as you already have a comma separated list of engines in the searxng engine, also it's unauthenticated so on a public instance anyone can enable/disable engines on your searxng for example
• the plugin uses env variables that can never be read as plugins can't read env variables

Hope this helps fine tuning it all :)

I'd feed your llm of choice the whole engines/plugins documentation ♥️

[SiaoZeng]

Thanks for the pointers — all three fixed in v1.0.1:

1. outgoingHosts changed to ["*"] so any SearXNG URL works
2. Removed the manager plugin entirely — you're right, the comma-separated engine/category fields in the engine settings cover the same functionality, and the plugin had an auth gap on public instances
3. No more process.env usage

The store repo is now just the engine (~110 lines): https://github.com/SiaoZeng/degoog-searxng-extensions

Let me know if anything else needs adjusting!