Degoog Environment variables

How to set them

Degoog reads its configuration from the process environment at startup. The usual way to supply it is a .env file: one KEY=value per line, no export prefix, # for comments.

Some things can only be set this way. DEGOOG_SETTINGS_PASSWORDS in particular is read exclusively from the environment; there is no settings UI and no on-disk file for it. If your instance is reachable from the internet, set it before the first start. An unlocked instance lets anyone install extensions, and extensions run code on your server.

# .env
DEGOOG_PORT=4444
DEGOOG_SETTINGS_PASSWORDS=your-secure-password
LOG_LEVEL=info

# Optional: listen on a Unix socket instead of a port
# DEGOOG_UNIX_SOCKET=/run/degoog/degoog.sock

Docker and Podman

Put .env next to your compose file and add env_file: .env to the service, or pass --env-file .env to docker run / podman run. Container images also honour PUID and PGID so ownership on mounted volumes matches your host user.

services:
  degoog:
    image: ghcr.io/degoog-org/degoog:latest
    env_file: .env
    volumes:
      - ./data:/app/data
    ports:
      - "4444:4444"

Native install or release tarball

Save .env in the project root next to package.json; Bun loads it automatically when you start from that directory. Always start Degoog from that directory, because paths like data/plugins resolve relative to the working directory.

Prebuilt archives are attached to each GitHub release. You also need bun, git, and curl on the host.

systemd

[Service]
WorkingDirectory=/opt/degoog
EnvironmentFile=/opt/degoog/.env
ExecStart=/usr/local/bin/bun run src/server/index.ts
Restart=on-failure

Viewing server logs

LOG_LEVEL controls how much gets printed. Where to read it:

• Docker Compose: docker compose logs -f
• Podman: podman logs -f degoog
• systemd: journalctl -u degoog -f
• Tarball or native: the terminal you started it in. Redirect stdout and stderr to a file if you run detached.

Server and networking

How Degoog works out its own URL

A few things have to name Degoog in full rather than by a relative path: the opensearch.xml descriptor your browser reads to offer Degoog as a search engine, and the honeypot sitemap. Degoog has no way to know its own public address, so it works it out per request, in this order.

1. The scheme and host of DEGOOG_BASE_URL, if you set it to a full URL. This wins over everything below, so use it when the steps below cannot work.
2. The X-Forwarded-Proto and X-Forwarded-Host headers from your reverse proxy. Most proxies send these, which is why Degoog needs no configuration on a normal setup. If the header holds a comma-separated list, Degoog takes the first entry.
3. The Host header, then the address the request actually arrived on.

The default order is deliberate. It lets one image serve several hostnames, which a hardcoded URL cannot do. If your descriptor shows http://localhost:4444, your proxy reached step 3, so either forward the two X-Forwarded-* headers, preserve the original Host, or set DEGOOG_BASE_URL to the full public URL.

Redirects do not use any of this. Degoog sends them as paths, so the browser resolves them against whatever address it already used, and a proxy that rewrites nothing still lands the user in the right place.

Access and settings gate

Behaviour and localisation

Cache

Docker

Data directories and files

Everything below defaults to somewhere inside the data directory, so overriding DEGOOG_DATA_DIR alone usually gets you what you want.

Indexer

Connecting to Postgres

The indexer uses SQLite and needs no configuration. To point it at Postgres instead, there are three ways to give it a connection. Pick one. If DEGOOG_POSTGRES is set, Degoog uses it and ignores the rest.

A connection URL. The original form. Nothing about it has changed, so an existing instance keeps working untouched.

DEGOOG_POSTGRES=postgresql://degoog:changeme@degoog-postgres:5432/degoog

Separate values. Use these when your deployment hands you credentials as individual keys and you cannot build the URL yourself, as with a Kubernetes secret from the CNPG operator or the bjw-s app-template chart. Leave DEGOOG_POSTGRES unset and set DEGOOG_POSTGRES_HOST. Only the host and password have no default.

DEGOOG_POSTGRES_HOST=cnpg-postgres-rw
DEGOOG_POSTGRES_PORT=5432
DEGOOG_POSTGRES_USER=degoog
DEGOOG_POSTGRES_PASSWORD=changeme
DEGOOG_POSTGRES_DATABASE=degoog

A password containing @, :, / or # works here. Degoog passes each value straight to the driver, so there is no connection string for them to break.

A unix socket. Give DEGOOG_POSTGRES_HOST a path starting with / and Degoog connects over that socket using peer authentication, with no password. This is the route for a Postgres running on the same host, and the one the Nix module needs.

DEGOOG_POSTGRES_HOST=/var/run/postgresql
DEGOOG_POSTGRES_USER=degoog
DEGOOG_POSTGRES_DATABASE=degoog

If DEGOOG_POSTGRES_HOST is set but a TCP host has no password, or the port is not a number, Degoog logs the problem and falls back to SQLite instead of refusing to start. So if the indexer page reports SQLite on an instance you expected to be on Postgres, grep your logs for [indexer].

SearX compatibility layer

4get compatibility layer