Degoog Server settings

Settings, Server is where you shape the instance itself: how fast people can query it, how it reaches the internet, what it does about bots, and what it remembers. Most of these have sensible defaults, but I encourage you all to test out and fine tune your instance to your liking. Degoog is HEAVILY customisable.

Server presets

If you do not want to reason about every switch individually, start here. A preset applies a one-shot template of settings that suit a particular kind of deployment, shows you exactly which values it will change before you commit, and warns you about what it cannot do for you.

Streaming results

With streaming on, results appear as each engine responds instead of waiting for all of them to finish. It makes a multi-engine search feel dramatically faster, particularly when one engine is slow. That said the page does end up being slightly chaotic with results moving around as new one pop in. I personally live in chaos, so it's how I have my own instance configured.

• Auto-retry failed engines retries an engine that came back empty, up to Max retries per engine. I'd keep this low at around 2/3 times max so to not hammer engines that decide you are being rate limited. It'll just make the situation worse.
• Streaming is not compatible with the POST search method. If you turn on POST in your search options, streaming will stop applying to you.

Rate limiting

Limits requests per IP to protect both your instance and the upstream engines you are querying. There are two independent groups, each with a short burst window and a longer sustained window:

Autocomplete delay (ms) lives in the same section. It is how long Degoog waits after you stop typing before asking providers for suggestions. Raising it cuts requests noticeably.

Bot control

Two independent defences, both on by default:

• Honeypot traps. Degoog serves bait paths that look like carelessly exposed secrets: a .env file, a PHP admin panel, a WordPress login, an API endpoint, a JavaScript source file. No legitimate visitor ever requests them. Anything that does gets banned.
• Browser verification (CSS HMAC). Injects a signed token into a stylesheet on every page. A real browser can't help but fetching that stylesheet, a scraper reading only the HTML does not. Requests that never fetch it accumulate strikes until they are banned.

Ban duration is in hours and defaults to 72. Set it to 0 for permanent bans (frankly that'd make you a piece of shit given IP rotate, but you do you). Expired bans are cleaned up automatically on the next request.

Below that you'll find the live Blocked IPs list, showing when each was banned and when it expires. You can unban entries, or add an address manually with Ban IP. Banned visitors get a themed 403 page rather than a bare error.

Proxy

Routes server-side search requests through proxies. One URL per line, requests rotate through the list. These can be overridden per-engine in the Engines tab.

Test proxy connection fetches your exit IP directly and through the proxy, then compares them, and tells you which of four things happened: the proxy is working and here are both IPs, the IPs match so the proxy may not be doing anything, the proxy could not be contacted at all, or the IP check service itself was unreachable. Much better than guessing.

Image proxy

Result thumbnails are fetched by your server and re-served, so clients never contacts the image host directly. By default the image proxy refuses private and local addresses, which is the correct default and stops it being used to probe your internal network.

If you run engines against your own services (a Jellyfin library, a Meilisearch index) you will need those thumbnails. Turn on Allow local network images and add regex patterns for the hosts you actually trust. Leaving the allow list empty permits every local address, which the UI describes as being at your own risk, and it means it.

Domain blocking, replacement and scoring

Three separate lists that reshape results after engines return them.

Blocking

One domain per line. Subdomains are included automatically. Wrap a line in slashes for a regular expression, which is matched against the hostname only, not the full URL, and takes no flags:

example.com
/(^|\.)instagram\.com$/
/^www\.instagram\.com$/

The first regex blocks instagram.com and every subdomain; the second blocks only www.instagram.com.

Replacement

Rewrites domains in result URLs, one rule per line, preserving the path. Subdomains match automatically:

reddit.com -> old.reddit.com
twitter.com -> nitter.net

Scoring

Add one domain and one number per row. Positive numbers move that domain up; negative numbers move it down. Subdomains match automatically.

example.com|20
spam.example|-15

Think of it as a final nudge after Degoog has already merged the search engines. If a result has 29 points and you add example.com|20, it becomes 49. If you add spam.example|-15, it becomes 14.

It is not a percentage. It is just plus or minus points. Use small numbers like 5 or -5 for a gentle nudge, and bigger numbers when you really trust or dislike a domain.

For context, a first-place result from a normal engine starts at 10 points. If two engines return the same URL, Degoog adds their points together and gives it a small extra bonus. The full result math is in How aggregation works.

Domain rules run in order: block first, replace second, score last.

Acting from the results page

Each list has an Allow ... from search results toggle. Turn it on and signed-in users get a kebab menu on every result row to block, replace, or score that domain on the spot. These menus are hidden entirely on public or unauthenticated instances regardless of the setting.

Search language

By default the language dropdown on the results page offers roughly 90 built-in languages. Turn on Change search languages and provide your own list of codes, one per line, to trim it to the handful your users actually need.

The fallback language when nobody picks one comes from DEGOOG_DEFAULT_SEARCH_LANGUAGE.

Custom CSS

Injects your own CSS into every page. It loads after theme and plugin styles, so it overrides them by default; reach for !important only when you are fighting a more specific selector.

API key

Degoog generates a server key you can use to protect the public API endpoints. The section is hidden until a password is configured via DEGOOG_SETTINGS_PASSWORDS, since there would be nothing protecting the key itself.

You can reveal, copy, and regenerate the key, and there are two independent switches:

• Protect search routes covers /api/search, /api/search/stream, and /api/search/retry.
• Protect suggestion routes covers /api/suggest and /api/suggest/opensearch.

External callers send the key as a bearer token. The web UI does not use it; it gets a short-lived signed nonce with the page instead, so turning this on does not break your own browsing. Full details in the API reference.

Cache

Flushes stored cache entries. Search and autocomplete are kept separately, and extensions register their own caches (the wiki panel and AI summary plugin each have one), so you get four buttons: clear search, clear autocomplete, clear extensions, or clear all.

Without DEGOOG_VALKEY_URL, all caching is per-process and in memory, and disappears on restart. With Valkey configured, the cache is shared across replicas and settings changes propagate instantly.

The remaining switches

• Degoog Indexer. Turns on local result recording and makes the Indexer tab appear. See Indexer.
• SearX compatibility layer. Adds the SearX section to the Engines tab. See SearX compatibility layer.
• Serve the SearXNG API shape. Makes /api/search honour the format=json parameter that SearXNG clients such as Open WebUI already send, and answer them with a SearXNG-shaped response. Requests without that parameter are unaffected.
• Keyboard shortcuts. Enables the shortcuts system for the instance. When off, the Shortcuts tab is hidden and no shortcuts are active.
• Restart server. Restarts the Degoog process. Searches in flight may be briefly interrupted.