Skip to main content
Панель Axottle конфигурируется только через переменные окружения с префиксом AXOTTLE_*. Отдельного конфигурационного файла в формате YAML/TOML нет: в production все переменные задаются в env-файле, который systemd передаёт процессу панели при запуске. Конфигурация читается один раз — при старте процесса. Полный перечень переменных со значениями по умолчанию — на странице Переменные окружения.
Для кого: администратор, SRE. Требуемые права: root (или sudo) на сервере панели — env-файл доступен только привилегированным пользователям.
Горячей перезагрузки конфигурации нет. Любое изменение любой переменной AXOTTLE_* вступает в силу только после рестарта сервиса axottle. Правка env-файла без рестарта не меняет поведение работающей панели.

​
Где живёт конфигурация

Основные данные панель хранит в PostgreSQL (DSN задаётся переменной AXOTTLE_DB_URL). Миграции схемы применяются автоматически при каждом старте axottle serve — до того, как панель начнёт принимать трафик.
Команда сброса пароля администратора подключается к PostgreSQL напрямую и должна видеть конфигурацию установленной панели. Doctor также использует эту конфигурацию для проверок базы, но не прекращает диагностику, если PostgreSQL недоступен.

​
Безопасное изменение конфигурации

1

Сохраните текущую версию env-файла

Копия понадобится для отката. Не храните резервные копии env-файла в общедоступных каталогах — файл содержит секреты.
2

Отредактируйте переменные

Формат — строки вида AXOTTLE_PORT=8080, по одной переменной на строку. Реальные значения секретов здесь не показываем — используйте свои.
3

Перезапустите сервис

Рестарт кратковременно прерывает доступ к панели и API. При старте панель автоматически применяет миграции БД.
4

Проверьте здоровье панели

Ожидаемый ответ:
Затем просмотрите логи на предмет ошибок старта:

​
Проверка

Панель считается успешно переконфигурированной, когда после рестарта GET /health возвращает "status":"ok", axottle status показывает running, а в логах нет ошибок инициализации.
Пример вывода:
Команда завершается с ненулевым кодом, если статус отличается от running — удобно для скриптов.

​
Откат

1

Верните сохранённую копию

2

Перезапустите сервис и проверьте

​
Ограничения и риски

  • Рестарт обязателен для любого изменения. Изменённый env-файл без рестарта создаёт расхождение между «тем, что на диске» и «тем, что работает» — это частая причина путаницы при диагностике.
  • Секреты в env-файле. AXOTTLE_SECRET_KEY — мастер-ключ шифрования хранилища секретов панели. Задайте сильное значение в production и ограничьте доступ к файлу (установщик выставляет 640 root:axottle — не ослабляйте эти права). Подробнее — в таблице переменных.
  • Ошибочный DSN базы (AXOTTLE_DB_URL) не даст панели подняться. Проверяйте логи сразу после рестарта.

​
Типовые ошибки

Скорее всего, сервис не перезапущен. Выполните sudo systemctl restart axottle и проверьте systemctl status axottle.
Проверьте синтаксис файла (одна переменная на строку, без пробелов вокруг =), затем логи: journalctl -u axottle -n 100. Если причина не ясна — откатите файл из резервной копии и перезапустите сервис.
Запускайте команды на сервере панели через sudo. В TUI откройте Doctor и выберите Attempt safe recovery — инструмент попробует поднять PostgreSQL и повторит проверку. Если это не помогло, проверьте контейнер или службу PostgreSQL и конфигурацию AXOTTLE_DB_URL в env-файле установленной панели.

​
Связанные страницы

Переменные окружения

Полная таблица всех переменных AXOTTLE_*.

CLI axottle

Команды status, doctor, logs и другие.
Проверено для версии Axottle текущей ветки. Дата проверки: 2026-07-12.