Advanced config

Databasus runs with sensible defaults out of the box — a standard single-container install needs no configuration at all. Every variable on this page is optional and not needed in 99% of production setups

OAuth

By default Databasus uses email and password sign-in. You can additionally let people sign in with their Google or GitHub account. A provider's button appears as soon as its client ID is set, but sign-in only completes when both the client ID and the client secret are present.

When you register the OAuth application, set its redirect (callback) URL to https://<your-domain>/auth/callback. Because of that redirect, OAuth sign-in needs your instance served over HTTPS on a public domain — see the note below.

Google

Create an OAuth client in the Google Cloud Console (APIs & Services → Credentials → Create credentials → OAuth client ID, application type Web application) and add https://<your-domain>/auth/callback as an authorized redirect URI.

GitHub

Create an OAuth app under GitHub Developer settings (Settings → Developer settings → OAuth Apps → New OAuth App) and set the authorization callback URL to https://<your-domain>/auth/callback.

Email (SMTP)

Connect a mail server so Databasus can send workspace invitations, password reset codes and sign-in codes. The mail server counts as configured as soon as SMTP_HOST is set. Without it, the settings screen reports the mail server as not configured, and the sign-in screen hides the password reset link.

This is the instance mail server. Email notifiers, which report backup events, have SMTP settings of their own in each notifier's form, so a notifier that delivers mail tells you nothing about this server. To check the instance mail server, open Databasus settings → Mail server and press Send test email. The message goes to your own address, and a failed delivery shows the mail server's response.

SMTP_SECURITY selects one of three modes. Email notifiers offer the same choice under Advanced settings.

Sign up captcha (Cloudflare Turnstile)

If your instance is reachable from the public internet, you can put a Cloudflare Turnstile challenge on the sign-up and sign-in forms to keep bots out. Both keys come from the Turnstile dashboard, and the challenge activates only when both are set.

Docker storage permissions

Databasus normally selects its numeric user and group IDs from an existing pgdata directory, then from the backups mount or data root, and finally uses 999. Set PUID or PGID only when that automatic choice does not fit your bind mount, CIFS share, or NFS export. Values must be base-10 integers from 1 through 4294967294.

Databasus and PostgreSQL use the same non-root operating-system account named databasus.

The entrypoint starts as root inside the container to select the IDs and attempt chown and chmod. It then checks the actual file lifecycle as databasus. A mount can work even if it rejects metadata changes. An arbitrary Docker user: override is not supported.

ERROR: Databasus cannot write to local storage paths /databasus-data/temp and /databasus-data/backups as UID 999 and GID 999.
Required operation: save a file through local storage.
Set PUID and PGID or fix the mounted directory permissions: https://databasus.com/advanced-config/#docker-storage-permissions
Details: permission denied

The previous four service-specific identity variables were deliberately removed. Remove them from your configuration when upgrading. If the automatic IDs cannot access a mount, startup stops with the failed operation and this documentation link.

Telemetry

Databasus sends anonymous, non-identifying usage telemetry by default. It carries no personal data and helps us understand how the project is used. You can read exactly what is collected in the privacy policy, and you can turn it off completely.

Logging

Databasus writes its logs to stdout and mirrors them as JSON to databasus.log on the data volume. Set OPEN_TELEMETRY_URL and it also exports them over Open Telemetry to a backend such as VictoriaLogs, Graylog, SigNoz, Grafana Loki, Datadog or Honeycomb, or to an OpenTelemetry Collector, which is itself an OTLP receiver.

• Transport follows the scheme. http:// and https:// send OTLP/HTTP and use the URL verbatim, path included; grpc:// and grpcs:// send OTLP/gRPC and use only the host and port.
• Authentication goes into OPEN_TELEMETRY_HEADERS or into the URL as user:password@host.
• Secrets (passwords, tokens, credentials) inside URLs — are redacted before a record leaves the process.
• Audit entries ship with the application logs tagged log_type=audit and ignore LOG_LEVEL, so raising the level never drops the audit trail.

Values for common backends, each with the header that authenticates it. Replace hosts, regions and keys with your own:

Header values are percent-decoded, so the space after Basic or Bearer is written as %20 and a comma inside a value as %2C. Basic auth can also go straight into the URL as https://user:password@host/path — Databasus turns it into the same header and keeps it out of the logs. Over http:// and grpc:// keys and passwords travel in clear, so use https:// or grpcs:// outside a trusted network.

Analytics script

Databasus can inject your own analytics or tracking snippet — Google Analytics, Plausible, Umami and similar into the app. When ANALYTICS_SCRIPT is set, its value is inserted into the page <head> at startup.

Security warning: the value is injected verbatim as raw HTML and JavaScript and runs with full access to the Databasus UI in every visitor's browser. Only ever set it to a snippet you fully control and trust.