Appsmith на Ubuntu 24.04: пошаговая установка

MAATRIX

Внутренние админ-панели и дашборды почти всегда пишут одинаково: форма, таблица, пара кнопок, запрос к базе. Appsmith избавляет от этой рутины — вы собираете интерфейс из готовых виджетов и связываете его с существующей БД или API, а код пишете только там, где действительно нужна логика. Разберём, как поднять Appsmith на своём сервере с Ubuntu 24.04: от чистой системы до рабочей панели с HTTPS и бэкапом.

Appsmith: что это и зачем свой сервер

Appsmith — open-source low-code платформа для внутренних инструментов. На холсте вы перетаскиваете таблицы, формы, графики и кнопки, привязываете их к запросам — SQL к вашей БД, вызову REST API, GraphQL — и получаете рабочую админку без фронтенда с нуля. Типичные сценарии: панель поддержки для CRM, дашборд для отдела продаж поверх Postgres, внутренний инструмент для модерации контента.

Облачная версия Appsmith существует, но для внутренних панелей с доступом к боевой базе и токенам API это не всегда уместно: данные и учётки уходят на чужую инфраструктуру, а бесплатный тариф ограничивает число пользователей. Self-hosted вариант снимает оба вопроса — данные остаются у вас, пользователей и приложений можно заводить сколько нужно, а трафик к внутренним сервисам не покидает вашу сеть.

Appsmith распространяется в виде Docker-образа, который разворачивается одной командой: внутри контейнера уже упакованы все служебные компоненты (MongoDB и Redis для хранения самих приложений и кэша), а Ubuntu 24.04 даёт свежее ядро и актуальный Docker без плясок с версиями. Для комфортной работы производитель ориентирует на конфигурацию от 2 vCPU и 4 ГБ памяти — это ориентир, а не жёсткий порог: на паре ядер и 2 ГБ Appsmith тоже стартует и работает для тестов, но под несколькими активными пользователями и тяжёлыми запросами лучше не экономить на памяти. У MAATRIX такой VPS на Ubuntu 24.04 оплачивается из России картой, по СБП, криптой или токеном MAAT, локацию можно взять под задачу — RU для минимальной задержки к российским сервисам, US или UK для связки с зарубежными API.

Шаг 1. Подготовка сервера и Docker

Обновите систему и сразу закройте периметр фаерволом — Appsmith будет слушать 80 и 443 порты, остальное снаружи видеть не должно:

apt update && apt upgrade -y
ufw allow 22/tcp
ufw allow 80,443/tcp
ufw enable

Если ufw на сервере ещё не настраивался предметно, отдельно разберитесь с правилами и логированием — базовая инструкция есть в статье про настройку UFW на Ubuntu 24.04. Дальше ставим Docker официальным скриптом:

curl -fsSL https://get.docker.com | sh
docker --version

Заведите домен и направьте A-запись на IP сервера заранее — DNS распространяется не мгновенно, а он понадобится уже на шаге с HTTPS.

Шаг 2. Запуск Appsmith в Docker

Appsmith Community Edition разворачивается одним контейнером — никакого docker-compose с десятком сервисов не требуется, всё нужное (внутренние MongoDB, Redis, кэш) уже внутри образа. Создайте каталог для данных и запустите контейнер:

mkdir -p ~/appsmith && cd ~/appsmith

docker run -d \
  --name appsmith \
  -p 80:80 -p 443:443 \
  -v "$PWD/stacks:/appsmith-stacks" \
  --restart unless-stopped \
  appsmith/appsmith-ce

Ключевой момент — том stacks, смонтированный в /appsmith-stacks. В нём хранится буквально всё: данные внутренних БД, конфигурация, сертификаты, загруженные файлы и кастомные JS-библиотеки. Потерять этот каталог — значит потерять все приложения и настройки, поэтому именно его вы будете бэкапить и переносить при миграции на другой сервер.

Первый запуск занимает несколько минут — контейнер поднимает внутренние сервисы и накатывает миграции. Проверить прогресс:

docker logs -f appsmith

Когда в логах появится сообщение о готовности сервера, можно идти дальше. Ресурсы контейнера стоит сразу присматривать через docker stats appsmith — если память упирается в лимит уже на старте, это сигнал взять план с большим объёмом RAM ещё до того, как на сервере появятся реальные пользователи.

Шаг 3. HTTPS и домен через реверс-прокси

Appsmith по умолчанию слушает 80 и 443 напрямую в контейнере, и в его официальной документации есть встроенный механизм получения сертификата для кастомного домена через утилиту внутри контейнера. Но если на сервере уже крутятся другие сайты или сервисы на этих портах, проще и предсказуемее вынести TLS на внешний реверс-прокси, а Appsmith оставить на локальном порту.

Перезапустите контейнер, пробросив порты только на loopback:

docker stop appsmith && docker rm appsmith

docker run -d \
  --name appsmith \
  -p 127.0.0.1:8080:80 \
  -v "$PWD/stacks:/appsmith-stacks" \
  --restart unless-stopped \
  appsmith/appsmith-ce

Дальше — Caddy с автоматическим HTTPS перед контейнером. Подробный разбор установки и подводных камней есть в статье про Caddy с авто-SSL на Ubuntu 24.04, здесь минимальный конфиг:

appsmith.example.com {
    reverse_proxy 127.0.0.1:8080
}

Caddy сам выпустит и продлит сертификат Let's Encrypt, а наружу с сервера будет торчать только порт 443 самого Caddy. Такой вариант не конфликтует с другими сервисами на том же сервере и держит логику TLS в одном месте, а не размазанной между несколькими приложениями.

Шаг 4. Первый запуск, workspace и источники данных

Откройте домен в браузере. При первом визите Appsmith предложит создать учётную запись суперадминистратора — email и пароль. Это единственный барьер между интернетом и вашими внутренними панелями, поэтому пароль нужен надёжный, а если сервер смотрит наружу без VPN — стоит сразу подумать про 2FA, если она включена в вашей версии, либо ограничить доступ на уровне сети.

После входа вы попадаете в рабочее пространство (workspace) — контейнер для приложений одной команды. Внутри workspace создаётся первое приложение, и дальше начинается собственно low-code часть:

1. Datasource — подключение к источнику данных: PostgreSQL, MySQL, MongoDB, REST API, GraphQL, Google Sheets и другие. Для БД указываете хост, порт, имя базы и учётные данные — Appsmith хранит их зашифрованными и подставляет в запросы автоматически.
2. Query — сам запрос к источнику: SQL-выражение, вызов эндпоинта, параметризованный через {{ }} биндинги на данные из виджетов.
3. Widgets — таблицы, формы, графики, кнопки, выпадающие списки, которые перетаскиваются на холст и привязываются к результату запроса или к действиям пользователя через JS-выражения прямо в свойствах виджета.

Если панель будет ходить в вашу собственную PostgreSQL на этом же сервере или на соседнем, порядок установки и настройки описан в статье про PostgreSQL на Ubuntu 24.04. Для локальной связки в том же docker-сегменте не забудьте открыть доступ в pg_hba.conf именно с адреса, откуда стучится контейнер Appsmith, а не разрешать подключения отовсюду.

Шаг 5. Обновления, бэкап, ресурсы сервера

Обновление Appsmith — это скачивание свежего образа и пересоздание контейнера с тем же смонтированным томом:

docker pull appsmith/appsmith-ce
docker stop appsmith && docker rm appsmith
docker run -d \
  --name appsmith \
  -p 127.0.0.1:8080:80 \
  -v "$PWD/stacks:/appsmith-stacks" \
  --restart unless-stopped \
  appsmith/appsmith-ce

При старте контейнер сам прогоняет миграции внутренних БД до актуальной версии. Перед обновлением production-инстанса стоит заглянуть в changelog релиза на GitHub — иногда меняется поведение отдельных виджетов или коннекторов, и лучше узнать об этом заранее, а не по факту сломанного дашборда.

Бэкап в такой схеме сводится к архивированию каталога stacks:

tar czf appsmith-backup-$(date +%F).tar.gz -C ~/appsmith stacks

Делайте это по расписанию через cron и уносите архив за пределы сервера — если это единственная копия административных панелей команды, восстановление после потери сервера должно занимать минуты, а не требовать пересборки всех приложений вручную. Отдельно у Appsmith есть экспорт конкретного приложения в JSON прямо из интерфейса — удобно как быстрый снапшот перед рискованными изменениями, но не как замена полноценному бэкапу тома.

По ресурсам держите в уме: чем больше в workspace активных приложений и одновременных пользователей, тем заметнее растёт потребление памяти внутренними MongoDB и Redis. Если docker stats показывает, что контейнер регулярно упирается в лимит, а не колеблется в рабочем диапазоне — это честный повод перейти на план с большим объёмом RAM, а не подкручивать таймауты.

Частые вопросы