Сколько RAM нужно для Appsmith

MAATRIX

Appsmith собирает админ-панель или дашборд поверх вашей БД и API за пару часов вместо недели фронтенд-разработки — но самостоятельный хостинг ставит закономерный вопрос: сколько памяти под него закладывать. Официальный образ тянет за собой не только сам сервер, а ещё встроенную MongoDB, Redis и Node.js-сервис для реального времени, и если взять сервер впритык, всё это начинает пожирать друг друга через swap. Разберём, из чего складывается аппетит Appsmith и какую конфигурацию VPS брать под тест, рабочую установку и продакшен для команды.

Из чего состоит Appsmith и почему он ест больше памяти, чем кажется

На первый взгляд Appsmith выглядит как обычное веб-приложение: открыл браузер, перетащил виджеты, подключил датасорс. Но под капотом официального Docker-образа appsmith/appsmith-ce живёт целый мини-стек:

• appsmith-server — бэкенд на Java (Spring Boot), обрабатывает запросы, хранит логику приложений, выполняет запросы к вашим датасорсам;
• MongoDB — встроенная база, где лежат сами определения приложений, страниц, виджетов, пользователи и права доступа (это не ваша рабочая БД, а внутреннее хранилище Appsmith);
• Redis — кеш и хранилище сессий;
• RTS (Realtime Service) — Node.js-процесс, отвечает за совместное редактирование в реальном времени, когда несколько разработчиков правят одно приложение одновременно;
• nginx — раздаёт статику клиента (React-приложение) и проксирует запросы к остальным сервисам.

Всё это по умолчанию упаковано в один контейнер (single-container deployment) — так проще ставить, но именно поэтому Appsmith ощутимо тяжелее, чем условный n8n или NocoDB того же класса задач. JVM под Spring Boot сама по себе редко живёт меньше 400-600 МБ резидентной памяти даже в простое, MongoDB на пустой базе стабильно занимает 150-300 МБ, Redis — десятки мегабайт, плюс Node.js-процесс RTS. Дальше добавляется память под сами запросы: чем больше открытых вкладок редактора, тем больше сокет-соединений держит RTS, чем сложнее запросы к датасорсам — тем больше буферов у JVM.

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

2 ГБ: минимум для теста одним пользователем

На 2 ГБ RAM (1-2 vCPU) официальный образ Appsmith запускается и даже открывается в браузере — но это конфигурация "посмотреть, что это такое", не рабочая. В таком объёме память распределяется примерно так: 500-700 МБ уходит ядру Linux и системным процессам, 600-900 МБ — JVM-серверу, 150-300 МБ — MongoDB, остальное делят Redis, RTS и nginx. Свободного запаса почти не остаётся, и первая же операция с крупным датасетом или параллельное открытие двух вкладок редактора уводит систему в swap.

Проверить фактическое потребление сразу после старта:

docker stats appsmith --no-stream

Если видите, что контейнер уже стабильно держит 1.5+ ГБ в простое — это нормально для Appsmith, а не признак утечки. На 2 ГБ обязательно настройте swap, иначе при пиковой нагрузке ядро может убить процесс через OOM killer вместо того, чтобы просто притормозить его — как это настроить, разобрано в статье про настройку swap. Но рассчитывать на постоянную работу нескольких человек на такой конфигурации не стоит — это тест-драйв, максимум одна короткая сессия.

4 ГБ: комфортный порог для постоянной работы

4 ГБ — практический минимум, с которого Appsmith перестаёт быть источником тревоги. На этом объёме контейнер получает разумный запас: JVM может держать больший heap без частых сборок мусора, MongoDB — кеш индексов вместо постоянного чтения с диска, а системе остаётся 1-1.5 ГБ на файловый кеш и обработку скачков нагрузки.

Этого достаточно для:

• одного-двух разработчиков, которые собирают и правят приложения по очереди;
• 3-5 внутренних приложений среднего размера (десяток страниц, несколько датасорсов);
• нечастых запросов к внешним API и БД без тяжёлых join'ов и больших выборок.

Если приложений становится больше или запросы к БД начинают возвращать тысячи строк на одну таблицу-виджет — память начнёт расти быстрее, чем кажется на старте, потому что каждый датасет буферизуется в JVM перед отдачей на клиент.

8 ГБ и выше: команда, продакшен, внешние БД

Когда Appsmith переходит из режима "внутренний инструмент для двух человек" в режим "на нём работает вся команда", закладывайте от 8 ГБ. На этом уровне вы получаете запас под несколько одновременных RTS-соединений (совместное редактирование), больше приложений в работе и, что важно, возможность держать пиковую нагрузку без деградации отклика интерфейса — а это то, что пользователи замечают быстрее всего.

Ориентировочные диапазоны — именно ориентировочные, ваша цифра будет зависеть от числа и сложности датасорсов, объёма выгружаемых данных на страницу и того, сколько человек одновременно в редакторе:

На больших инсталляциях есть смысл вынести MongoDB и Redis из общего контейнера на отдельные управляемые или самостоятельно настроенные сервисы — Appsmith поддерживает подключение к внешним экземплярам через переменные окружения APPSMITH_MONGODB_URI и APPSMITH_REDIS_URL. Это разгружает основной контейнер и позволяет масштабировать базу данных отдельно от бэкенда, не пересобирая весь стек.

docker-compose.yml с лимитами и мониторингом

Официальный способ быстрого старта — через docker run с монтированием каталога данных:

docker run -d --name appsmith \
  -p 80:80 -p 443:443 \
  -v ~/appsmith-stacks:/appsmith-stacks \
  --ulimit nofile=1048576:1048576 \
  --restart unless-stopped \
  appsmith/appsmith-ce

Высокий ulimit для файловых дескрипторов нужен из-за встроенной MongoDB — с дефолтным лимитом системы она может отказываться стартовать на некоторых дистрибутивах. Для контроля памяти удобнее оформить это через docker-compose, где сразу задаётся жёсткий лимит и резерв:

services:
  appsmith:
    image: appsmith/appsmith-ce
    container_name: appsmith
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./appsmith-stacks:/appsmith-stacks
    ulimits:
      nofile:
        soft: 1048576
        hard: 1048576
    deploy:
      resources:
        limits:
          memory: 4g
        reservations:
          memory: 2g

Обратите внимание: секция deploy.resources в чистом docker-compose up без Swarm иногда игнорируется на старых версиях Docker Compose — если лимит не применяется, используйте вместо неё mem_limit: 4g на уровне сервиса (работает в Compose V2 без Swarm). Подробнее про разницу этих подходов и когда какой лимит реально сработает — в статье про лимиты CPU и памяти в Docker.

Жёсткий лимит памяти — это подстраховка, а не способ сэкономить: если выставить его ниже реальной потребности контейнера, Appsmith будет падать по OOM в самый неподходящий момент, вместо того чтобы просто работать медленнее. Ставьте лимит с запасом 20-30% сверх наблюдаемого потребления в docker stats, а не впритык.

Как снизить аппетит Appsmith по памяти

Если сервер тесноват, а переезжать пока рано, есть несколько практических рычагов:

• Ограничить JVM heap явно. Часть потребления Appsmith — это не фактически используемые данные, а резерв, который JVM берёт "на всякий случай". Задайте более консервативный heap через переменную окружения JAVA_OPTS (например, -Xmx1024m для сервера с 2-4 ГБ) — это снизит пиковое потребление ценой чуть более частой сборки мусора под нагрузкой.
• Вынести MongoDB наружу, даже на этом же сервере, но отдельным контейнером с собственным лимитом памяти — так проще увидеть, сколько реально ест сама база, а не гадать по общей цифре контейнера.
• Отключить телеметрию, если не нужна: APPSMITH_DISABLE_TELEMETRY=true — экономия небольшая, но безопасная и без побочных эффектов.
• Регулярно чистить неиспользуемые приложения и версии — MongoDB хранит историю изменений и черновики, и на старой инсталляции без чистки это ощутимо раздувает базу и, соответственно, её кеш в памяти.
• Настроить swap как страховку, а не как основной ресурс. Правильный размер и когда его вообще стоит включать — в статье про подбор swap для VPS. Для интерактивного инструмента вроде Appsmith активный своп ощущается пользователями как зависания интерфейса, так что это скорее аварийный буфер, чем рабочий режим.

Для сравнения по объёму: похожий по назначению инструмент автоматизации n8n при сопоставимой нагрузке требует заметно меньше памяти именно потому, что не тащит за собой встроенную MongoDB — разбор его требований есть в статье сколько RAM нужно для n8n, полезно для понимания, за счёт чего конкретно Appsmith тяжелее.

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