Appsmith в Docker Compose: готовый файл

MAATRIX

Если у вас есть база данных или пара REST API, а бизнесу нужна админка для менеджеров — писать её с нуля на React ради CRUD-таблиц и пары форм не имеет смысла. Appsmith закрывает этот класс задач: вы подключаете источник данных, перетаскиваете виджеты на канвас, привязываете их к запросам — и через час у команды есть рабочая панель управления. Ниже — готовый docker-compose.yml, который поднимает Appsmith на собственном сервере за 10 минут, с пояснениями по каждому важному параметру.

Что такое Appsmith и когда он оправдан

Appsmith — open-source low-code платформа для внутренних инструментов: дашбордов, CRM-заглушек, панелей модерации, форм ввода данных. По архитектуре это одно Java/Node-приложение (сервер + встроенный MongoDB и Redis для служебных данных самого Appsmith), которое подключается к вашим внешним источникам — PostgreSQL, MySQL, REST API, S3, Google Sheets и т. д. — и рендерит интерфейс из готовых виджетов.

Это не замена полноценной разработке. Appsmith хорош, когда:

• нужна внутренняя админка для 2–20 сотрудников, а не публичный продукт;
• данные уже лежат в базе или отдаются через API, и задача — просто дать к ним удобный UI;
• изменения в логике происходят часто, а команда разработки маленькая или её нет вовсе.

Если планируется сложная бизнес-логика, кастомные визуализации или тысячи одновременных пользователей — это уже зона обычной разработки, а не low-code конструктора.

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

Требования к серверу

Appsmith — не самое лёгкое приложение. Официально рекомендуется от 4 ГБ RAM, на практике комфортно работает от 2 ГБ при небольшой нагрузке (до 5–10 одновременных пользователей), но стартовать лучше не ниже этого порога — иначе Node-процесс будет периодически падать по OOM при сборке запросов с большими датасетами.

Ориентировочная конфигурация:

Для боевой панели, к которой обращается вся команда каждый день, разумно сразу брать сервер с 4 ГБ RAM — Appsmith держит в памяти встроенный MongoDB, Redis и сам сервер приложения, и при недостатке памяти именно контейнер БД первым уходит в перезапуск, роняя весь стек.

Установка Docker и подготовка окружения

Если Docker и Docker Compose уже стоят — пропустите этот шаг. Если нет, на Ubuntu 24.04:

curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker $USER
newgrp docker
docker compose version

Создайте рабочую директорию и каталог для постоянного хранения данных Appsmith:

mkdir -p /opt/appsmith/stacks
cd /opt/appsmith

Appsmith хранит весь свой внутренний стейт (встроенные MongoDB, Redis, конфиги, загруженные файлы) в одном примонтированном томе /appsmith-stacks — это упрощает бэкапы: достаточно архивировать одну директорию, а не собирать данные из нескольких контейнеров.

Готовый docker-compose.yml

Официальный образ Appsmith — это моноблок (all-in-one), внутри которого уже запущены нужные сервисы. Такой подход проще для старта, но менее гибкий, чем классическая multi-container схема. Вот рабочий вариант:

version: "3.8"

services:
  appsmith:
    image: appsmith/appsmith-ce:latest
    container_name: appsmith
    restart: unless-stopped
    ports:
      - "127.0.0.1:8080:80"
      - "127.0.0.1:8443:443"
    volumes:
      - ./stacks:/appsmith-stacks
    environment:
      - APPSMITH_MONGODB_URI=mongodb://appsmith:appsmith@localhost:27017/appsmith?authSource=admin
      - APPSMITH_REDIS_URL=redis://localhost:6379
      - APPSMITH_ENCRYPTION_PASSWORD=change_me_to_random_string
      - APPSMITH_ENCRYPTION_SALT=change_me_to_random_salt
      - APPSMITH_DISABLE_TELEMETRY=true
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost/api/v1/health"]
      interval: 30s
      timeout: 10s
      retries: 5
      start_period: 90s

Ключевые моменты по параметрам:

• ports привязаны к 127.0.0.1 — контейнер не торчит наружу напрямую, доступ идёт только через обратный прокси (см. ниже). Это базовая гигиена для любого сервиса, который не должен принимать соединения из интернета напрямую.
• APPSMITH_ENCRYPTION_PASSWORD и APPSMITH_ENCRYPTION_SALT — обязательно замените на случайные строки (openssl rand -hex 32), ими шифруются сохранённые credentials источников данных внутри Appsmith. Потеряете их — не расшифруете сохранённые пароли к базам.
• start_period: 90s в healthcheck — первый старт Appsmith поднимает внутренние MongoDB и Redis, инициализация занимает 40–90 секунд, слишком короткий период даст ложные "unhealthy".
• restart: unless-stopped — переживает перезагрузку хоста без ручного вмешательства.

Запуск:

docker compose up -d
docker compose logs -f appsmith

Дождитесь строки о том, что сервер поднялся (обычно 1-2 минуты на первый старт), затем откройте http://<ip-сервера>:8080 — появится мастер первичной настройки: создание администратора и (опционально) подключение SMTP для приглашений пользователей.

Обратный прокси, домен и SSL

Открывать порт 8080 напрямую в интернет — плохая идея: нет шифрования, нет нормального логирования, нет защиты от перебора паролей на уровне веб-сервера. Правильный путь — Nginx или Caddy перед контейнером плюс сертификат Let's Encrypt.

Конфиг для Nginx (после того как настроили reverse proxy и выпустили SSL):

server {
    listen 443 ssl http2;
    server_name admin.example.com;

    ssl_certificate /etc/letsencrypt/live/admin.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/admin.example.com/privkey.pem;

    client_max_body_size 100m;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        proxy_read_timeout 90s;
    }
}

server {
    listen 80;
    server_name admin.example.com;
    return 301 https://$host$request_uri;
}

Upgrade/Connection заголовки нужны обязательно — Appsmith использует WebSocket-соединения для live-обновления интерфейса при совместном редактировании приложений, без них редактор будет заметно тормозить и терять изменения.

Кому не нужен отдельный домен для теста, можно временно оставить доступ по IP:порту через SSH-туннель:

ssh -L 8080:localhost:8080 user@server-ip

и открывать http://localhost:8080 с локальной машины — так вы не светите панель наружу вообще, что удобно на этапе первичной настройки источников данных.

Подключение источников данных

Главная ценность Appsmith — не в самом UI-конструкторе, а в том, как быстро он подключается к существующим данным. После входа в админку:

1. Datasources → New Datasource → выбираете тип (PostgreSQL, MySQL, MongoDB, REST API, S3, GraphQL и т. д.).
2. Для базы данных указываете хост, порт, имя БД, пользователя и пароль. Если PostgreSQL стоит на том же сервере, хостом будет не localhost (это будет localhost контейнера Appsmith), а IP хоста или имя сервиса, если база тоже в Docker-сети — тогда добавьте оба контейнера в общую network в compose-файле.
3. Для REST API — базовый URL, авторизация (Bearer token, Basic Auth, API Key) сохраняется в датасорсе один раз и переиспользуется во всех запросах приложения.

Пример подключения к внешней PostgreSQL из того же docker-compose проекта — добавьте сеть:

services:
  appsmith:
    # ...
    networks:
      - appsmith_net

  postgres:
    image: postgres:16
    environment:
      - POSTGRES_PASSWORD=strong_password
    networks:
      - appsmith_net

networks:
  appsmith_net:
    driver: bridge

Тогда в датасорсе Appsmith хостом указывается имя сервиса — postgres, а не IP.

После подключения датасорса создаёте запрос (SQL или REST-вызов), а затем привязываете его результат к виджету — таблице, графику, выпадающему списку — через {{ queryName.data }} в биндингах. Это основной паттерн работы: данные → запрос → виджет.

Бэкап и обновление

Appsmith хранит и код приложений, и credentials источников данных внутри /appsmith-stacks. Бэкапить нужно именно эту директорию:

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

Автоматизировать через cron — раз в сутки, с ротацией старых архивов и выгрузкой во внешнее хранилище (S3-совместимое или отдельный сервер бэкапов), чтобы не потерять данные при отказе основного диска.

Обновление до новой версии — стандартно для образа с тегом latest:

docker compose pull
docker compose up -d

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

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