Как установить и настроить Vikunja на VPS

MAATRIX

Если вы устали от того, что таск-менеджер живёт на чужих серверах, а бесплатный тариф режет число проектов и участников, — логичный шаг переехать на self-hosted вариант. Vikunja закрывает именно этот сценарий: лёгкий, быстро разворачивается в Docker и не требует армии администраторов. Ниже — рабочая установка на VPS с нуля: от контейнеров до HTTPS, бэкапов и первых настроек.

Что такое Vikunja и кому она подойдёт

Vikunja — открытый (AGPL) менеджер задач с бэкендом на Go и фронтендом на Vue. По сути это альтернатива Todoist или Any.do, только данные хранятся у вас, а не у стороннего сервиса. Из коробки есть:

• проекты (раньше назывались списками) с вложенностью и общим деревом;
• представления «список», «канбан-доска», «таблица», «Ганта» и календарь;
• метки, приоритеты, дедлайны и повторяющиеся задачи;
• напоминания — с доставкой по email или через CalDAV в календарь телефона;
• команды и совместный доступ к проектам с разными правами;
• REST API и синхронизацию через CalDAV/приложения для iOS и Android.

Для соло-пользователя или небольшой команды (до 10-20 человек) Vikunja комфортно работает на самом скромном VPS — 1 vCPU и 1 ГБ RAM хватает с запасом. Если нужна не просто личная to-do, а канбан для команды разработки, обратите внимание на Wekan или Focalboard — они ближе к классическому Trello. Vikunja же сильнее именно как персональный и семейный трекер задач с напоминаниями.

Что нужно перед установкой

Понадобится:

• VPS с Ubuntu 24.04 (подойдёт и Debian 12) с установленным Docker и Docker Compose;
• доменное имя или поддомен, направленный A-записью на IP сервера — без него можно обойтись, но HTTPS и мобильные приложения работают заметно приятнее с нормальным доменом;
• открытые порты 80 и 443 для выпуска SSL-сертификата;
• минимум 1 ГБ RAM и 1 vCPU, 10-15 ГБ диска на систему и файлы вложений с запасом на рост.

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

Проверьте версии на сервере:

docker --version
docker compose version

Если команды не находятся — сначала установите Docker Engine и плагин compose, дальше по инструкции.

Установка Vikunja через Docker Compose

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

mkdir -p /opt/vikunja/{files,db}
cd /opt/vikunja

Сгенерируйте случайный секрет для подписи JWT-токенов — он понадобится в переменных окружения:

openssl rand -base64 32

Сохраните результат — это VIKUNJA_SERVICE_JWTSECRET, без него сессии не будут работать корректно после перезапуска контейнера.

Создайте docker-compose.yml:

services:
  db:
    image: mariadb:10.11
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: "замените_на_сложный_пароль"
      MYSQL_DATABASE: vikunja
      MYSQL_USER: vikunja
      MYSQL_PASSWORD: "замените_на_другой_сложный_пароль"
    volumes:
      - ./db:/var/lib/mysql

  api:
    image: vikunja/api
    restart: unless-stopped
    depends_on:
      - db
    environment:
      VIKUNJA_DATABASE_HOST: db
      VIKUNJA_DATABASE_TYPE: mysql
      VIKUNJA_DATABASE_USER: vikunja
      VIKUNJA_DATABASE_PASSWORD: "замените_на_другой_сложный_пароль"
      VIKUNJA_DATABASE_DATABASE: vikunja
      VIKUNJA_SERVICE_JWTSECRET: "вставьте_сгенерированный_секрет"
      VIKUNJA_SERVICE_PUBLICURL: "https://vikunja.example.com/"
      VIKUNJA_SERVICE_ENABLEREGISTRATION: "false"
    volumes:
      - ./files:/app/vikunja/files

  frontend:
    image: vikunja/frontend
    restart: unless-stopped
    depends_on:
      - api
    environment:
      VIKUNJA_API_URL: "https://vikunja.example.com/api/v1"
    ports:
      - "127.0.0.1:3456:80"

Пара пояснений по переменным:

• VIKUNJA_DATABASE_TYPE можно заменить на postgres или sqlite — для маленьких инсталляций SQLite экономит ресурсы и убирает контейнер db вообще (тогда достаточно смонтировать файл базы через volume в api).
• VIKUNJA_SERVICE_ENABLEREGISTRATION: "false" закрывает публичную регистрацию — критично, если сервис торчит наружу: без этого любой прохожий сможет создать себе аккаунт.
• API слушает на 3456 порту внутри сети контейнеров, наружу порт api отдельно пробрасывать не нужно — фронтенд ходит к нему через внутреннюю docker-сеть, а наружу смотрит только сам фронтенд.

Порт фронтенда намеренно забинжен на 127.0.0.1 — снаружи к Vikunja будет пускать только reverse-proxy с HTTPS, напрямую по HTTP порт 3456 недоступен.

Запускаем:

docker compose up -d
docker compose logs -f api

Дождитесь в логах сообщения о применённых миграциях базы — это значит, что API поднялся и создал таблицы.

Домен, HTTPS и reverse-proxy

Проще всего поставить перед Vikunja Caddy — он сам выпускает и продлевает Let's Encrypt сертификат. Если Caddy ещё не установлен, разверните его по инструкции Caddy с авто-SSL на Ubuntu 24.04.

Минимальный Caddyfile:

vikunja.example.com {
    reverse_proxy 127.0.0.1:3456
}

Перезапустите Caddy — сертификат выпустится автоматически при первом обращении по HTTPS:

sudo systemctl reload caddy

Если вы используете nginx, схема аналогичная — проксируйте весь трафик домена на 127.0.0.1:3456, а SSL получайте через certbot отдельным шагом. Важный нюанс: VIKUNJA_SERVICE_PUBLICURL и VIKUNJA_API_URL в compose-файле должны совпадать с реальным внешним адресом (со схемой https:// и завершающим слэшем для PUBLICURL) — иначе фронтенд будет пытаться достучаться до API по неправильному пути и вы получите бесконечную загрузку авторизации.

Первая настройка: аккаунт, проекты, напоминания

Откройте https://vikunja.example.com/ — увидите форму регистрации первого пользователя (она доступна один раз даже при ENABLEREGISTRATION: false, для остальных регистрация закрыта). Создайте админский аккаунт и войдите.

Дальше стоит настроить:

• Проекты — создайте базовую структуру: «Работа», «Дом», «Проекты» и т.д. Vikunja поддерживает вложенные проекты, так что можно не плодить плоский список.
• Метки (labels) — заведите цветовые метки под приоритет или контекст (#срочно, #ждёт-ответа), они фильтруются и ищутся отдельно от текста задачи.
• Напоминания — чтобы они приходили на почту, добавьте в api-сервис блок SMTP:

      VIKUNJA_MAILER_ENABLED: "true"
      VIKUNJA_MAILER_HOST: "smtp.example.com"
      VIKUNJA_MAILER_PORT: "587"
      VIKUNJA_MAILER_USERNAME: "vikunja@example.com"
      VIKUNJA_MAILER_PASSWORD: "пароль_от_smtp"
      VIKUNJA_MAILER_FROMEMAIL: "vikunja@example.com"

После изменения переменных пересоздайте контейнер: docker compose up -d api.

• CalDAV — задачи с дедлайнами можно синхронизировать в календарь телефона: адрес CalDAV имеет вид https://vikunja.example.com/dav/principals/ваш_логин/, подключается как обычный CalDAV-аккаунт в iOS/Android/Thunderbird. Так напоминания приходят системными пуш-уведомлениями, а не только письмом.
• Команды — если работаете не в одиночку, создайте команду в разделе «Teams» и дайте ей доступ к нужным проектам с правами read/write/admin — это удобнее, чем расшаривать проекты каждому человеку по отдельности.

Резервное копирование и обновление

Данные Vikunja — это база (MySQL/Postgres/SQLite) и папка с файлами вложений. Бэкапить нужно оба места.

Дамп MySQL из контейнера:

docker compose exec db mariadb-dump -u vikunja -p vikunja > /opt/vikunja/backup/vikunja-$(date +%F).sql

Файлы вложений — обычным rsync или tar директории ./files, так как это просто файловая система на хосте:

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

Общие подходы к автоматизации дампов и ротации бэкапов — в статье про резервное копирование баз данных: те же принципы (cron, ротация, вынос копий за пределы сервера) применимы и к Vikunja.

Обновление сводится к смене тегов образов и перезапуску:

docker compose pull
docker compose up -d

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

Безопасность и продакшн-нюансы

• Закройте прямой доступ к портам БД и API наружу — в примере выше это уже сделано через 127.0.0.1 и отсутствие внешнего порта у api, но проверьте это через docker compose ps и ss -tlnp на сервере.
• Отключите регистрацию (VIKUNJA_SERVICE_ENABLEREGISTRATION: "false") сразу после создания первого аккаунта, если сервис публичный.
• Настройте файрвол (ufw/iptables) так, чтобы наружу смотрели только 80/443 — остальное только через SSH-туннель при необходимости отладки.
• Логи API стоит поглядывать периодически (docker compose logs api --tail 100) — там же будут видны неудачные попытки логина, если кто-то подбирает пароль.
• Для небольших инсталляций (до пары десятков пользователей) SQLite снимает необходимость держать отдельный контейнер БД и упрощает бэкап до копирования одного файла — разумный выбор, если не планируете большую команду.

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