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

MAATRIX

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

Из чего состоит Vikunja и почему это лёгкое приложение

Vikunja — это один Go-бинарник (в современных версиях он же образ vikunja/vikunja), который отдаёт и REST API, и статику собранного Vue.js-фронтенда с одного порта — по умолчанию 3456. Никакого отдельного Node.js-рантайма для рендеринга, никакой JVM, никакого второго процесса на реальном времени вроде Meteor у Wekan — сервер просто слушает HTTP и ходит в базу за задачами. Раньше проект распространялся как два отдельных образа (vikunja/api и vikunja/frontend за отдельным nginx), это ещё встречается в старых гайдах и docker-compose файлах — но с точки зрения памяти разница небольшая, единый бинарник просто убирает лишний процесс nginx-фронтенда.

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

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

Из опциональных вещей, которые не тянут заметную память сами по себе, но требуют внимания в конфиге: CalDAV-синхронизация задач с телефоном/календарём, отправка email-напоминаний через VIKUNJA_MAILER_* и разбор вложений к задачам — они увеличивают нагрузку на диск и сеть, но не на RAM в идле.

Сколько RAM нужно по сценарию использования

Ниже — практический ориентир, а не результат формального нагрузочного теста: точные цифры зависят от числа одновременно активных вкладок, объёма вложений и того, крутится ли на том же сервере что-то ещё. Но порядок величин достаточно устойчив, потому что сам процесс Vikunja в бездействии почти ничего не ест — основной расход появляется либо от базы данных, либо от соседних сервисов на сервере.

Даже верхняя строка таблицы для крупной команды остаётся скромной по меркам self-hosted инструментов — для сравнения, у Wekan на сопоставимом размере команды счёт идёт уже на 6–9 ГБ из-за связки Meteor + MongoDB с oplog. Vikunja в этом смысле ближе по профилю к Focalboard — тоже Go-бинарник, тоже SQLite или PostgreSQL на выбор, и тоже минимальный оверхед сверх базы данных.

Практический вывод: 1 ГБ RAM хватает с запасом для личного использования на SQLite, а команде до полутора-двух десятков человек на PostgreSQL комфортно живётся на 2 ГБ. Реальный «мешающий» фактор на таком сервере — это не сама Vikunja, а всё остальное: ОС, Docker daemon, обратный прокси и, если он тоже там, — PostgreSQL с дефолтными настройками, которые не рассчитаны на маленькую машину.

Docker Compose: SQLite для соло-использования

Самый простой вариант — единый бинарник и SQLite, без отдельной базы данных:

services:
  vikunja:
    image: vikunja/vikunja
    container_name: vikunja
    restart: unless-stopped
    mem_limit: 512m
    mem_reservation: 128m
    environment:
      VIKUNJA_SERVICE_PUBLICURL: https://tasks.example.com/
      VIKUNJA_SERVICE_JWTSECRET: change_this_to_a_random_secret
      VIKUNJA_SERVICE_TIMEZONE: Europe/Moscow
      VIKUNJA_DATABASE_TYPE: sqlite
      VIKUNJA_DATABASE_PATH: /db/vikunja.db
    ports:
      - "3456:3456"
    volumes:
      - ./files:/app/vikunja/files
      - ./db:/db

Для личного использования или пары-тройки пользователей этого достаточно даже на самом бюджетном VPS — mem_limit: 512m здесь уже с запасом, а не впритык.

Docker Compose: PostgreSQL для команды

Как только пользователей становится больше пяти-семи и они пишут одновременно (создают задачи, двигают карточки в канбане), стоит перейти на PostgreSQL — SQLite не рассчитан на конкурентную запись из нескольких соединений и на такой нагрузке начинает подтормаживать:

services:
  vikunja:
    image: vikunja/vikunja
    container_name: vikunja
    restart: unless-stopped
    mem_limit: 512m
    mem_reservation: 128m
    depends_on:
      - db
    environment:
      VIKUNJA_SERVICE_PUBLICURL: https://tasks.example.com/
      VIKUNJA_SERVICE_JWTSECRET: change_this_to_a_random_secret
      VIKUNJA_DATABASE_TYPE: postgres
      VIKUNJA_DATABASE_HOST: db
      VIKUNJA_DATABASE_USER: vikunja
      VIKUNJA_DATABASE_PASSWORD: change_me_please
      VIKUNJA_DATABASE_DATABASE: vikunja
      VIKUNJA_MAILER_ENABLED: "true"
      VIKUNJA_MAILER_HOST: smtp.example.com
      VIKUNJA_MAILER_FROMEMAIL: tasks@example.com
    ports:
      - "3456:3456"
    volumes:
      - ./files:/app/vikunja/files

  db:
    image: postgres:16-alpine
    container_name: vikunja-db
    restart: unless-stopped
    mem_limit: 768m
    mem_reservation: 256m
    environment:
      POSTGRES_USER: vikunja
      POSTGRES_PASSWORD: change_me_please
      POSTGRES_DB: vikunja
    command: >
      postgres -c shared_buffers=192MB -c work_mem=8MB
    volumes:
      - pg_data:/var/lib/postgresql/data

volumes:
  pg_data:

Значения shared_buffers и work_mem здесь намеренно понижены относительно дефолта PostgreSQL, который рассчитан на выделенный сервер БД — на VPS, где рядом крутится и сам Vikunja, отдавать базе половину RAM хоста «по умолчанию» не нужно. Если раньше не настраивали PostgreSQL под ограниченную память, общий порядок действий разобран в статье тюнинг PostgreSQL на VPS, а сравнение с MySQL — в материале PostgreSQL или MySQL: что выбрать для сервера. Общий принцип выставления mem_limit с запасом 20–30% сверх реального потребления, а не впритык, разобран в статье про Docker Compose для продакшена на VPS — он полностью применим и здесь.

Когда SQLite ломается и пора на PostgreSQL

SQLite в Vikunja работает надёжно, пока запись в базу почти всегда идёт от одного человека в один момент времени. Признаки, что пора переезжать:

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

Миграция данных из SQLite в PostgreSQL для Vikunja не входит в штатный функционал «одной кнопкой» — если она понадобится, проще спланировать переход на PostgreSQL сразу, до того как в SQLite накопится история задач за полгода.

Что ещё занимает память на сервере, кроме Vikunja

На маленьком VPS сам процесс Vikunja почти никогда не оказывается главным потребителем RAM. Реальные конкуренты за память на той же машине:

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

Отсюда практический вывод: если по таблице выше сам Vikunja «стоит» условно 60 МБ, не берите VPS ровно на эту цифру — закладывайте минимум 1 ГБ даже под соло-использование, чтобы ОС, Docker и прокси не толкались за остаток. Если после недели работы видно, что памяти системно не хватает не только Vikunja, но и соседним сервисам, стоит пройтись по чек-листу в статье что делать при нехватке RAM — часто дело не в объёме сервера, а в неправильных лимитах контейнеров.

Проверка реального потребления и подстраховка свопом

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

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

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

# Проверка, не убивал ли ядро процесс по OOM
dmesg -T | grep -i "killed process"
journalctl -k | grep -i oom

# Если запускали без Docker — прямой процесс
ps aux | grep vikunja

Если mem_limit контейнера выставлен слишком впритык, поведение будет выглядеть как случайный рестарт без ошибки в логах самого приложения — cgroup просто присылает процессу SIGKILL, и restart: unless-stopped поднимает контейнер заново. Небольшой своп на 512 МБ – 1 ГБ как страховка от кратковременного всплеска — разумная мера для маленького VPS, но не замена нормальному объёму RAM для PostgreSQL: подробнее о том, как выбрать размер и не превратить своп в костыль, — в статье правильный размер swap для VPS.

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