Расширенная конфигурация

Databasus из коробки работает с разумными настройками по умолчанию — стандартной установке в один контейнер конфигурация не нужна вовсе. Каждая переменная на этой странице необязательна и не требуется в 99% продакшен-установок

OAuth

По умолчанию в Databasus вход по email и паролю. Дополнительно можно разрешить вход через аккаунт Google или GitHub. Кнопка провайдера появляется, как только задан его client ID, но вход срабатывает, только когда заданы оба значения: и client ID, и client secret.

При регистрации OAuth-приложения укажите redirect-адрес (callback) https://<your-domain>/auth/callback. Из-за этого редиректа для входа через OAuth ваш инстанс должен быть доступен по HTTPS на публичном домене — см. заметку ниже.

Google

Создайте OAuth-клиент в Google Cloud Console (APIs & Services → Credentials → Create credentials → OAuth client ID, тип приложения Web application) и добавьте https://<your-domain>/auth/callback как разрешенный redirect URI.

GitHub

Создайте OAuth-приложение в настройках разработчика GitHub (Settings → Developer settings → OAuth Apps → New OAuth App) и укажите authorization callback URL https://<your-domain>/auth/callback.

Почта (SMTP)

Подключите почтовый сервер, чтобы Databasus мог отправлять приглашения в рабочие пространства, коды сброса пароля и коды входа. Почтовый сервер считается настроенным, как только задан SMTP_HOST. Без него экран настроек показывает, что почтовый сервер не настроен, а на экране входа нет ссылки для сброса пароля.

Это почтовый сервер инстанса. У каналов уведомлений по email, которые сообщают о бекапах, свои настройки SMTP в форме каждого канала. Поэтому если письма от канала уведомлений доходят, это ничего не говорит о почтовом сервере инстанса. Чтобы проверить его, откройте Databasus settings → Mail server и нажмите Send test email. Письмо придет на ваш адрес, а если доставка не удалась, вы увидите ответ почтового сервера.

SMTP_SECURITY выбирает один из трех режимов. У каналов уведомлений по email такой же выбор есть в разделе Advanced settings.

Капча при регистрации (Cloudflare Turnstile)

Если ваш инстанс доступен из публичного интернета, на формы регистрации и входа можно поставить проверку Cloudflare Turnstile, чтобы отсечь ботов. Оба ключа берутся в панели Turnstile, а проверка включается, только когда заданы оба.

Права Docker-хранилища

Обычно Databasus берет числовые ID пользователя и группы у существующего каталога pgdata, затем проверяет mount с бекапами и корневой каталог данных. Если подходящего владельца нет, используется 999. Задавайте PUID или PGID, только когда автоматический выбор не подходит для вашего bind mount, CIFS или NFS. Допустимы десятичные значения от 1 до 4294967294.

Databasus и PostgreSQL работают под одной учетной записью ОС без прав root с именем databasus.

Entrypoint запускается с правами root внутри контейнера, выбирает ID и пробует выполнить chown и chmod. После этого он проверяет полный цикл работы с файлами от имени databasus. Mount может работать, даже если файловая система запрещает менять владельца или режим. Произвольное значение Docker user: не поддерживается.

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

Четыре прежние переменные для отдельных сервисов удалены сознательно. При обновлении уберите их из конфигурации. Если автоматически выбранным ID не хватает прав, контейнер остановится и укажет неудавшуюся операцию вместе со ссылкой на эту инструкцию.

Телеметрия

По умолчанию Databasus отправляет анонимную телеметрию использования. Она не содержит персональных данных и помогает нам понять, как используется проект. Что именно собирается, написано в политике конфиденциальности, и телеметрию можно полностью выключить.

Логирование

Databasus пишет логи в stdout и дублирует их в формате JSON в файл databasus.log на томе с данными. Если задать OPEN_TELEMETRY_URL, он также экспортирует их по OpenTelemetry в бэкенд вроде VictoriaLogs, Graylog, SigNoz, Grafana Loki, Datadog или Honeycomb, либо в OpenTelemetry Collector, который сам является OTLP-приемником.

• Транспорт определяется схемой. http:// и https:// отправляют OTLP/HTTP и используют URL как есть, включая путь; grpc:// и grpcs:// отправляют OTLP/gRPC и используют только хост и порт.
• Аутентификация задается в OPEN_TELEMETRY_HEADERS или прямо в URL в виде user:password@host.
• Секреты (пароли, токены, учетные данные) в URL вычищаются до того, как запись покидает процесс.
• Записи аудита уходят вместе с логами приложения с меткой log_type=audit и игнорируют LOG_LEVEL, поэтому повышение уровня никогда не обрежет аудиторский след.

Значения для популярных бэкендов, каждое с заголовком аутентификации. Замените хосты, регионы и ключи на свои:

Значения заголовков percent-декодируются, поэтому пробел после Basic или Bearer записывается как %20, а запятая внутри значения — как %2C. Basic-аутентификацию можно указать и прямо в URL в виде https://user:password@host/path — Databasus превратит ее в тот же заголовок и не пустит в логи. Через http:// и grpc:// ключи и пароли идут открытым текстом, так что вне доверенной сети используйте https:// или grpcs://.

Скрипт аналитики

Databasus может встроить в приложение ваш собственный скрипт аналитики или трекинга — Google Analytics, Plausible, Umami и похожие. Когда задан ANALYTICS_SCRIPT, его значение вставляется в <head> страницы при старте.

Предупреждение о безопасности: значение вставляется как есть, как сырой HTML и JavaScript, и получает полный доступ к интерфейсу Databasus в браузере каждого посетителя. Задавайте только тот сниппет, который вы полностью контролируете и которому доверяете.