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

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

ЧтоГдеКомментарий
Env-файл панели/etc/axottle/axottle.envСоздаётся установщиком; права 640, владелец root:axottle
Systemd-юнитaxottle.serviceПодключает env-файл через EnvironmentFile=, запускает /opt/axottle/bin/axottle serve от пользователя axottle
Корень установки/opt/axottleБинарник, миграции, каталог данных, файлы установщика
Каталог данныхAXOTTLE_DATA_DIR (в production /opt/axottle/data)Состояние лицензии, журнал обновлений панели, локальные бэкапы
Основные данные панель хранит в PostgreSQL (DSN задаётся переменной AXOTTLE_DB_URL). Миграции схемы применяются автоматически при каждом старте axottle serve — до того, как панель начнёт принимать трафик.
Команда сброса пароля администратора подключается к PostgreSQL напрямую и должна видеть конфигурацию установленной панели. Doctor также использует эту конфигурацию для проверок базы, но не прекращает диагностику, если PostgreSQL недоступен.

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

1

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

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

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

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

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

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

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

curl -s http://localhost:8080/health
Ожидаемый ответ:
{"status":"ok","timestamp":"2026-07-11T00:00:00Z","version":"<версия>"}
Затем просмотрите логи на предмет ошибок старта:
axottle logs backend --tail 50

​
Проверка

Панель считается успешно переконфигурированной, когда после рестарта GET /health возвращает "status":"ok", axottle status показывает running, а в логах нет ошибок инициализации.
axottle status
Пример вывода: 
Status:      running
Version:     <версия>
DB:          connected
Setup done:  true
Uptime:      42s
Команда завершается с ненулевым кодом, если статус отличается от running — удобно для скриптов.

​
Откат

1

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

sudo cp /etc/axottle/axottle.env.bak /etc/axottle/axottle.env
2

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

sudo systemctl restart axottle
curl -s http://localhost:8080/health

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

  • Рестарт обязателен для любого изменения. Изменённый 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.