Degoog Environment variables

How to set environment variables

Degoog reads configuration from the process environment when it starts. The usual way to supply it is a .env file: one KEY=value per line, no export prefix, comments allowed with #. Every method below ends up loading that same file (or an equivalent path) into the process before launch.

Some settings can only be configured this way. In particular, DEGOOG_SETTINGS_PASSWORDS is read exclusively from the environment - there is no settings UI or on-disk file for it. If you expose your instance on the internet, set a password in your .env before the first start. An unlocked instance lets anyone install extensions, which runs code on your server.

# .env — example shared by every method below
DEGOOG_PORT=4444
# Optional: listen on a Unix domain socket instead of DEGOOG_PORT.
# DEGOOG_UNIX_SOCKET=/run/degoog/degoog.sock
DEGOOG_SETTINGS_PASSWORDS=your-secure-password
LOG_LEVEL=info

Release tarball

Prebuilt archives are attached to each GitHub release. Extract the tarball, cd into the degoog folder it contains, and save your .env next to package.json. Bun loads it automatically when you start the server from that folder. You also need bun, git, and curl on the host.

tar -xzf degoog_*_prebuild.tar.gz
cd degoog
# create .env here (see example above)
mkdir -p data
bun run src/server/index.ts

Always start Degoog from the extract root. Paths such as data/plugins are relative to that directory. For a persistent background process, use systemd (below), supervisord, or a screen / tmux session pointed at the same folder.

Docker and Podman

Create a .env file in the same folder as your compose file or run command, then point Docker at it. With Compose, add env_file: .env to the service (you can still list individual keys under environment: if you prefer). With docker run or podman run, pass --env-file .env. See the Running Degoog section on the overview page for more compose examples. Container images use PUID and PGID (documented below under Docker) so file ownership on mounted volumes matches your host user.

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

# or inline
docker run -d --env-file .env -p 4444:4444 -v ./data:/app/data ghcr.io/degoog-org/degoog:latest

systemd

Keep your variables in .env and reference that file from the unit with EnvironmentFile=/opt/degoog/.env. You can also set individual Environment=NAME=value lines in the unit file, but a single .env is easier to maintain. Set WorkingDirectory to your Degoog directory so relative paths resolve correctly.

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

Native install (git clone)

Same as the release tarball: save .env in the repository root and run bun run start from there after bun install and bun run build. Bun loads the file automatically. See Running Degoog on the overview page.

Viewing server logs

Set LOG_LEVEL to control how much the server prints (see the General table). Where you read that output depends on how you run Degoog:

• Docker Compose: docker compose logs -f
• Podman: podman logs -f degoog
• systemd: journalctl -u degoog -f (replace degoog with your unit name)
• Tarball or native: the terminal where you started the process; redirect stdout and stderr to a log file if you run detached

General

Docker

Plugins, themes, engines