MAATRIX / Блог / Сколько RAM нужно для Focalboard

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

MAATRIX

Focalboard — канбан-доски, таблицы и календарь в одном self-hosted инструменте, который часто берут как замену Trello или Asana без подписки и без чужих серверов. Хорошая новость: приложение написано на Go, а не на Java или тяжёлом Node-стеке, поэтому по памяти оно заметно скромнее многих аналогов. Но конкретная цифра «сколько RAM брать» зависит от того, используете вы SQLite для одного человека или PostgreSQL для команды из полусотни людей — и в статье мы разложим это по сценариям, с реальными конфигами и лимитами.

Обсудить статью, задать вопрос или начать новую тему

Есть вопрос по этой статье, идея для обсуждения или просто хотите поделиться опытом? Сообщество MAATRIX ждёт. Для общения, пожалуйста, зарегистрируйтесь в нашем личном кабинете.

Перейти в сообщество →

Из чего состоит Focalboard и почему это важно для памяти

Focalboard — это один Go-бинарник (или один Docker-контейнер), который отдаёт и API, и статику фронтенда на React. Никакого отдельного веб-сервера, никакой JVM, никакого рантайма вроде Node.js под капотом — это и есть главная причина низкого потребления памяти по сравнению, например, с Wekan, который построен на Node.js и MongoDB и требует памяти на порядок больше.

Хранилище данных — на выбор:

  • SQLite — файл на диске, отдельный процесс не нужен, база живёт внутри того же контейнера. Это режим по умолчанию для персонального использования.
  • PostgreSQL или MySQL — отдельная СУБД, нужна для многопользовательского режима с одновременными правками и для более высокой нагрузки.

Важный нюанс на конец лета 2026 года: Focalboard как отдельный продукт Mattermost давно не получает активной разработки — компания сфокусировалась на встроенном плагине Boards внутри самого Mattermost, а standalone-репозиторий обновляется редко. Для небольшой команды или личного использования старый Docker-образ mattermost/focalboard по-прежнему прекрасно работает и легковесен, но если вы планируете рост до полноценной командной платформы с интеграциями, стоит заранее посмотреть в сторону Mattermost с плагином Boards — там активная поддержка, но и требования к памяти совсем другие.

Сколько RAM нужно: цифры под сценарии

Ниже — ориентировочные цифры, собранные из практики разворачивания на небольших VPS. Это не строгий бенчмарк с точными измерениями (у вас будет отличаться в зависимости от числа досок, карточек, вложений и активности одновременных пользователей), а рабочий ориентир для выбора тарифа.

СценарийRAM для FocalboardРекомендуемая RAM сервераБД
Один пользователь, немного досок150–300 МБ1 ГБSQLite
Малая команда, 3–10 человек300–600 МБ2 ГБSQLite или PostgreSQL
Команда 10–30 человек, активная работа600 МБ – 1,5 ГБ4 ГБPostgreSQL
30–50+ человек, много вложений и досок1,5–3 ГБ (Focalboard + отдельно PostgreSQL)8 ГБPostgreSQL на отдельном сервере или с щедрым лимитом

Обратите внимание: сам процесс Focalboard редко становится узким местом раньше, чем база данных или обратный прокси перед ним. Если вы ставите SQLite на диск с медленным IO (бюджетный сетевой диск), тормозить может именно дисковая подсистема, а не память — это стоит проверить отдельно, прежде чем накидывать RAM «на всякий случай».

Нужен сервер под эту задачу?

Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK, США, Франция и РФ. Оплата картой РФ и по СБП.

Арендовать сервер

Docker Compose для Focalboard с лимитами памяти

Самый частый способ развернуть Focalboard — Docker Compose. Вот минимальный вариант на SQLite для соло- или небольшого использования:

services:
  focalboard:
    image: mattermost/focalboard:latest
    container_name: focalboard
    restart: unless-stopped
    ports:
      - "8000:8000"
    volumes:
      - focalboard_data:/data
      - ./config.json:/opt/focalboard/config.json:ro
    deploy:
      resources:
        limits:
          memory: 512M
        reservations:
          memory: 128M

volumes:
  focalboard_data:

Минимальный config.json для SQLite-режима:

{
  "serverRoot": "http://localhost:8000",
  "port": 8000,
  "dbtype": "sqlite3",
  "dbconfig": "/data/focalboard.db",
  "useSSL": false,
  "webpath": "./pack",
  "filespath": "/data/files",
  "session_expire_time": 2592000,
  "session_refresh_time": 18000
}

Для команды с PostgreSQL добавляем отдельный сервис базы и меняем dbtype/dbconfig:

services:
  focalboard:
    image: mattermost/focalboard:latest
    restart: unless-stopped
    ports:
      - "8000:8000"
    volumes:
      - focalboard_files:/data/files
      - ./config.json:/opt/focalboard/config.json:ro
    depends_on:
      - postgres
    deploy:
      resources:
        limits:
          memory: 768M

  postgres:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_DB: focalboard
      POSTGRES_USER: focalboard
      POSTGRES_PASSWORD: change_me_please
    volumes:
      - pg_data:/var/lib/postgresql/data
    deploy:
      resources:
        limits:
          memory: 1G

volumes:
  focalboard_files:
  pg_data:

В config.json для этого случая:

"dbtype": "postgres",
"dbconfig": "postgres://focalboard:change_me_please@postgres:5432/focalboard?sslmode=disable"

Лимиты deploy.resources.limits.memory в Docker Compose без Swarm-режима сам по себе docker compose up может игнорировать — если вы не разворачиваете через docker stack deploy, эффективнее выставлять лимиты через ключ mem_limit в том же сервисе (он поддерживается «классическим» compose-движком) или ограничивать через systemd/cgroups на уровне хоста, если хотите жёсткий потолок.

SQLite или PostgreSQL — как выбор базы двигает память

SQLite — самый экономный вариант: файл базы читается и пишется напрямую, отдельный процесс с собственным кэшем и буферами не нужен. Для одного-двух пользователей и десятка досок это разумный выбор — вы экономите и RAM, и сложность обслуживания (нет отдельного бэкапа СУБД, достаточно копировать файл).

Переходить на PostgreSQL стоит, когда:

  • одновременно работает больше 5–10 человек и SQLite начинает подтормаживать на конкурентных записях (это ограничение самого SQLite, а не Focalboard);
  • вам важна репликация или отдельный бэкап базы без остановки приложения;
  • вы уже держите PostgreSQL на сервере под другие сервисы — тогда логично завести отдельную базу focalboard в том же инстансе и не тратить память на второй движок.

PostgreSQL сам по себе требует памяти под shared_buffers, work_mem и кэш ОС — на маленьком сервере разумно выставить shared_buffers в районе 128–256 МБ, а не оставлять дефолт, рассчитанный на выделенный сервер БД. Подробнее про подбор этих параметров — тема отдельная, но общий принцип: не давайте PostgreSQL по умолчанию претендовать на память, которая нужна остальным сервисам.

Что ещё съедает память на сервере, кроме Focalboard

Сам процесс Focalboard редко бывает главным потребителем RAM на минимальном VPS. Реальные конкуренты за память:

  • Обратный прокси (nginx или Caddy) перед Focalboard для HTTPS — обычно 20–50 МБ на простую конфигурацию, но растёт с числом воркеров и активных соединений;
  • PostgreSQL, если вы его подключили — от 100 МБ и выше, в зависимости от настроек;
  • Сама операционная система — ядро Linux, systemd, sshd, cron и прочие фоновые процессы обычно съедают 150–300 МБ на минимальном Ubuntu/Debian;
  • Docker daemon — ещё 50–150 МБ сверху, если вы не используете подкачку через containerd напрямую.

Отсюда практический вывод: если Focalboard-процессу по таблице выше нужно условно 300 МБ, закладывайте сервер минимум на 1–1,5 ГБ, а не ровно 300 МБ — иначе первый же всплеск активности (загрузка вложения, экспорт доски) упрётся в OOM killer, который прибьёт процесс без предупреждения в логах приложения.

Как проверить, что памяти хватает, и что делать при нехватке

Первое, что стоит сделать после разворачивания — не гадать, а посмотреть реальное потребление:

# Общая память на хосте
free -h

# Потребление по контейнерам в реальном времени
docker stats --no-stream

# История OOM-убийств в системном логе
dmesg | grep -i "killed process"
journalctl -k | grep -i oom

Если docker stats показывает, что Focalboard регулярно упирается в лимит из deploy.resources.limits, контейнер не падает сразу — он начинает тормозить или получает SIGKILL от cgroup, что в логах выглядит как внезапный рестарт без явной причины. Первый шаг — поднять лимит, второй, если апгрейд сервера пока не вариант, — временно подключить своп. Как правильно выбрать его размер и не превратить его в костыль вместо нормальной памяти, разобрано в статье про правильный размер swap для VPS.

Если же после недели наблюдений видно, что памяти системно не хватает — не только Focalboard, но и остальным сервисам на сервере — это симптом, который стоит разобрать по шагам: он не всегда решается покупкой RAM «с запасом», иногда дело в неправильно настроенных лимитах или утечке в соседнем сервисе. Общий чек-лист диагностики есть в статье что делать при нехватке RAM.

Практическая рекомендация по серверу

Для одного пользователя или маленькой команды до 5–10 человек с SQLite достаточно VPS с 1–2 ГБ RAM и 1 vCPU — Focalboard в этом режиме почти не заметен на фоне остальной нагрузки. Для команды побольше с PostgreSQL и активными вложениями закладывайте 4 ГБ и выше, особенно если на том же сервере крутится обратный прокси и другие self-hosted сервисы. Если параллельно с Focalboard вы держите Mattermost, почту или CI — считайте память по сумме всех сервисов, а не только по строке из этой таблицы, и берите сервер с запасом хотя бы в 30–40% сверх расчёта, чтобы не упираться в лимиты при первом же всплеске активности.

Нужен сервер под эту задачу?

Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK, США, Франция и РФ. Оплата картой РФ и по СБП.

Арендовать сервер

Нужны сами нейросети для контента?

Генерируйте изображения, видео и озвучку нейросетями на falapi.io — десятки моделей в одном окне. Оплата картой РФ и по СБП.

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

Focalboard всё ещё развивается или проект заброшен?

Активная разработка функциональности перенесена в плагин Boards внутри Mattermost, а standalone-репозиторий Focalboard обновляется редко. Для небольшого использования это не критично — образ стабилен и работает, но для растущей команды стоит заранее оценить переход на Mattermost с Boards.

Можно ли запустить Focalboard совсем без Docker?

Да, есть отдельный бинарник под Linux/macOS/Windows, который можно запустить как systemd-сервис — по памяти он ведёт себя так же, как в контейнере, но без накладных расходов Docker daemon.

SQLite выдержит команду из 20 человек?

Технически да, если нагрузка не сильно конкурентная (мало одновременных записей), но на практике при таком числе пользователей PostgreSQL даёт более предсказуемое поведение и упрощает бэкапы.

Что произойдёт, если контейнеру не хватит памяти по лимиту?

Cgroup-контроллер пришлёт процессу SIGKILL, контейнер перезапустится согласно политике restart, а в dmesg/journalctl -k появится запись про OOM — само приложение об этом ничего не сообщит.

Нужен ли Focalboard отдельный сервер или можно подселить к другим сервисам?

Из-за низкого потребления памяти Focalboard прекрасно живёт рядом с другими лёгкими self-hosted инструментами на одном VPS — главное учитывать суммарную нагрузку, а не только его собственную строку в таблице.

Обсудить статью, задать вопрос или начать новую тему

Есть вопрос по этой статье, идея для обсуждения или просто хотите поделиться опытом? Сообщество MAATRIX ждёт. Для общения, пожалуйста, зарегистрируйтесь в нашем личном кабинете.

Перейти в сообщество →