Самостоятельно размещённый стек продуктивности разработчика: замена GitHub, Vercel и Sentry на одном VPS в 2026 году

По текущим прейскурантным ценам команда из 3 человек, использующая GitHub Team, Vercel Pro, Sentry Team, Linear Basic и Notion Plus, начинает примерно со 158 $ в месяц, не считая 1Password, платы за потребление и дополнений. Аккуратно очерченный самостоятельно размещённый стек способен заметно сократить этот счёт, но честное сравнение включает VPS крупнее лабораторного минимума в 4 ГБ и время на обслуживание, о котором все забывают.

Это руководство для разработчика или небольшой команды, которые уже решили, что «счёт за SaaS раздражает» и что «держать закрытый код и рабочие процессы разработки на чужой инфраструктуре некомфортно», и теперь хотят понять, что конкретно запускать. Стек состоит из четырёх слоёв: код, сборка и развёртывание, запуск и документация. Каждый слой получает один рекомендованный инструмент, одну альтернативу, стоимость в ресурсах и сценарий отказа. Область охвата — частное и командное использование на одном VPS. Хостинг почты, DNS, аутентификация конечных клиентов и Kubernetes остаются за рамками по причинам, которые мы назовём там, где им место.

Кратко

Если читать только по пунктам:

• Код: Forgejo по умолчанию. Берите GitLab CE только если хотите git, CI/CD, реестр и задачи в одном продукте; текущая базовая конфигурация GitLab на одном узле — 16 ГБ ОЗУ, а 8 ГБ отведены для сред с ограниченной памятью.
• Сборка и развёртывание: Coolify on the current stable release (v4.3.0 at QC time), with the dashboard kept off the public internet. Dokku suits solo developers; pure Docker Compose suits teams that prefer visible moving parts.
• Выполните: Vaultwarden для общих учётных данных, Uptime Kuma для мониторинга, GlitchTip для отслеживания ошибок и Portainer или Dockge для управления контейнерами. GlitchTip разворачивается куда компактнее, чем самостоятельно размещённый Sentry, официальный минимум которого — 16 ГБ ОЗУ плюс 16 ГБ подкачки.
• Документация: Docmost для документации и OpenProject (или Plane) для отслеживания задач. AFFiNE подойдёт командам, которым ближе модель Notion в виде холста.
• Подбор ресурсов: Считайте 4 ГБ лабораторным размером для нескольких лёгких сервисов, 8 ГБ — урезанным пилотом без OpenProject, Plane и локальных сборок, а 16 ГБ — практичной отправной точкой для полного стека на базе Forgejo из этого руководства. База GitLab в 8 vCPU и 16 ГБ относится к самому GitLab, поэтому стек «всё в одной коробке» на GitLab потребует дополнительной ёмкости или отдельного нагрузочного тестирования.
• Где проигрывает: Публичные open-source проекты с внешними участниками. Сетевой эффект GitHub реален, и самостоятельный хостинг стоит вам обнаружимости.

Требования

Прежде чем читать дальше, руководство предполагает:

• Linux-VPS с установленными Docker и Docker Compose. Заложите около 16 ГБ ОЗУ для полного стека на базе Forgejo; 8 ГБ хватит для урезанного пилота без тяжёлых инструментов управления проектами и локальных сборок.
• От 30 до 60 минут внимания на каждый слой при первом развёртывании.
• Уверенность в чтении Compose-файла и правке переменных окружения.
• Готовность держать регулярное окно обновлений, оперативно ставить исправления безопасности и проверять резервные копии, а не просто настраивать их.

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

Слой 1, код: Forgejo, Gitea или GitLab CE

Три жизнеспособных варианта, три разные точки на кривой ресурсов и управления. Тем, кто начинает самостоятельно хостить в 2026 году, рекомендуется сначала Forgejo.

Forgejo рассчитан на скромную инфраструктуру и даёт pull request'ы, трекер задач, проектные доски, вики, реестры пакетов и Forgejo Actions. Его workflow используют формат в духе GitHub Actions, но совместимость не абсолютна: проверьте все сторонние actions, от которых зависит ваш конвейер.

Выбирайте Gitea только если уже зависите от специфичной для Gitea функции или ваш инструментарий закреплён за версией Gitea. С кодовой базой всё в порядке. официальное сравнение Forgejo говорит, что форк последовал за передачей в октябре 2022 года доменов и товарного знака Gitea коммерческой компании без одобрения сообщества; объявление о лицензировании Forgejo фиксирует лицензию GPL v3+ для версий начиная с v9.0.

Выбирайте GitLab CE, если хотите один продукт для git, CI/CD, реестра контейнеров и трекера задач и можете позволить себе его нижнюю планку по ресурсам. Текущие требования GitLab задают 16 ГБ ОЗУ и 8 vCPU как базу для одного узла; 8 ГБ предназначены для сред с ограниченной памятью. Gitea достаточно лёгок, чтобы небольшой приватный экземпляр уместился примерно в 1-2 ГБ ОЗУ, Forgejo сопоставим, но продакшен-размер для обоих всё равно зависит от репозиториев, раннеров и числа одновременных пользователей.

Вопрос CI стоит отметить отдельно. Gitea Actions задуман как в основном совместимый с GitHub Actions, тогда как Forgejo Actions намеренно стремится к привычности, а не к полной совместимости. Многим workflow хватит небольших правок, но образы раннеров, права, контексты, метки и сторонние actions могут вести себя иначе. Проверьте каждый workflow и каждый action, от которого зависит ваш конвейер, до миграции.

Одна оговорка касается всех трёх вариантов. Руководство исходит из частного и командного использования, где административная поверхность спрятана за VPN или списком разрешённых IP. Публичные git-сервисы сталкиваются с ботами, злоупотреблениями и компромиссами по обнаружимости, которых у небольшого приватного развёртывания нет. Для публичного open source зеркальте на GitHub ради видимости, оставив Forgejo источником истины, если такая модель управления вам важна.

Подбирайте сервер по нагрузке, а не по названиям тарифов провайдера. Отдельный сервис Forgejo или Gitea для лёгкого частного использования может стартовать примерно с 1-2 vCPU и 1-2 ГБ ОЗУ. Урезанный стек без OpenProject, Plane и локальных сборок стартует примерно с 4 vCPU и 8 ГБ ОЗУ. Для полного стека на базе Forgejo, описанного здесь, начинайте примерно с 8 vCPU и 16 ГБ ОЗУ, а затем проверьте его под реальной нагрузкой CI и приложений. Официальная база GitLab в 8 vCPU и 16 ГБ относится к самому GitLab, так что не считайте её достаточной для GitLab плюс всё остальное из этого стека. Используйте SSD или NVMe, заложите отдельный бюджет на репозитории, образы контейнеров, журналы, базы данных и резервные копии и держите 20-30% ёмкости свободными под обновления и всплески нагрузки.

Ключевой вывод раздела: Forgejo — рекомендация по умолчанию для слоя кода в 2026 году; Gitea остаётся надёжным, а GitLab CE становится интегрированным выбором только если вы потянете его базу в 16 ГБ или осознанно работаете в стеснённой конфигурации на 8 ГБ.

Слой 2, сборка и развёртывание: Coolify (с оговорками), Dokku или чистый Docker Compose

Скажем честно: Coolify — рекомендованный вариант PaaS для этого стека, если вы работаете на последнем продакшен-выпуске, держите админ-панель вне публичного интернета и следите за бюллетенями безопасности. На момент проверки GitHub помечает Coolify v4.3.0 как последний. Считайте установку исправлений и изоляцию управляющего слоя эксплуатационными требованиями, а не необязательным усилением защиты.

Совет профессионала: Ограничьте панель и API Coolify межсетевым экраном, VPN или доверенным прокси доступа. Развёрнутые приложения по-прежнему могут принимать публичный трафик; цель — уменьшить открытость административного управляющего слоя.

Альтернатива для одиночных разработчиков — Dokku, компактный PaaS с развёртыванием по git push в духе Heroku и поддержкой buildpack'ов. Его поверхность меньше, чем у Coolify, и набор возможностей соответственно скромнее. Это делает его обоснованно «скучным выбором» для одного-двух разработчиков, которым панель не нужна.

Третий вариант, к которому тянутся опытные операторы, — вообще без PaaS, только Docker Compose. Если ваша команда уже пишет Compose-файлы и вы предпочитаете видеть движущиеся части, это вполне разумный ответ. Добавьте Dockge или Portainer как слой интерфейса для управления стеками, когда захочется перезапуска в один клик вместо docker compose restart. Компромисс здесь эксплуатационный: нет предпросмотровых окружений, нет встроенной автоматизации TLS, нет развёртываний без простоя без дополнительных усилий. Эти возможности зарабатываются написанием скриптов; в Coolify они уже готовы, вместе с прилагающейся историей уязвимостей.

ЧИТАТЬ

Лучшие самостоятельно размещаемые альтернативы Heroku и Vercel: Coolify, Dokku и другие

Руководство Cloudzy по лучшим инструментам CI/CD подробнее разбирает конвейер сборки для команд, которым нужен отдельный раннер, а многим небольшим командам он не нужен, когда уже есть Forgejo Actions или CI/CD GitLab.

Ключевой вывод раздела: Coolify — рекомендованный PaaS только на текущем стабильном выпуске и с ограниченным управляющим слоем; Dokku — консервативный выбор одиночки; чистый Docker Compose остаётся обоснованным третьим вариантом.

Слой 3, запуск: Vaultwarden, Uptime Kuma, GlitchTip и управление контейнерами

Именно здесь живёт самый резкий разрыв в ресурсах во всём стеке. Официальные требования Sentry для самостоятельного размещения указывают минимум 4 ядра процессора, 16 ГБ ОЗУ, 16 ГБ подкачки и 20 ГБ свободного диска, а рекомендуют 32 ГБ ОЗУ. Руководство по установке GlitchTip рекомендует 512 МБ ОЗУ, требует PostgreSQL и делает Valkey необязательным. Для небольшой команды на одном VPS GlitchTip — практичный выбор по умолчанию.

Об остальных четырёх инструментах этого слоя рассказ будет коротким.

Vaultwarden — совместимый с Bitwarden менеджер паролей, который поддерживает мобильные приложения и браузерные расширения Bitwarden, а также командный доступ. Его реальный след зависит от числа пользователей, вложений и выбранной базы данных. Сравнение самостоятельно размещаемых менеджеров паролей от Cloudzy разбирает более глубокий компромисс, когда вам нужны более структурированные права, средства аудита или иная модель безопасности.

Uptime Kuma — небольшой инструмент мониторинга и оповещений: проверки HTTP, TCP, ping, push, срока действия сертификатов и опциональные страницы статуса. Уведомления можно направлять в чат, на почту или через вебхуки. Расход ресурсов зависит от числа проверок и глубины хранения; оповещать по второму подряд сбою — практичный способ подавить кратковременные скачки.

GlitchTip — трекер ошибок. Большинство интеграций Sentry SDK умеют слать данные на DSN GlitchTip, но паритет возможностей неполный: проверьте мониторинг производительности, source maps, оповещения и любую интеграцию, которую команда считает критичной.

Для интерфейса контейнеров выберите Portainer или Dockge. Portainer охватывает более широкий круг задач управления, Dockge держится Docker Compose. Для небольшого стека только на Compose Dockge садится аккуратнее. Переходите на Portainer, лишь когда понадобится больший охват.

Полезный приём Compose для этого слоя: держите каждый инструмент в своём подкаталоге с собственным compose.yml, делите общую сеть Docker только там, где нужен трафик между инструментами, и поставьте впереди один обратный прокси для терминации TLS.

# /opt/stack/glitchtip/compose.yml (excerpt)
services:
  web:
    image: "glitchtip/glitchtip:${GLITCHTIP_VERSION:?Set GLITCHTIP_VERSION in .env}"
    environment:
      DATABASE_URL: "${DATABASE_URL:?Set DATABASE_URL in .env}"
      SECRET_KEY: "${GLITCHTIP_SECRET_KEY:?Set GLITCHTIP_SECRET_KEY in .env}"
      GLITCHTIP_DOMAIN: "https://errors.example.com"
      DEFAULT_FROM_EMAIL: "[email protected]"
    ports:
      - "127.0.0.1:8000:8000"

Совет профессионала: Резервная копия считается доказанной только тогда, когда сервис удаётся восстановить, а данные проверить. Раз в месяц восстанавливайте один показательный сервис в изолированную тестовую среду, запускайте его, входите в систему, просматривайте записи и вложения и убеждайтесь, что приложение ведёт себя нормально. Список восстановленных файлов доказывает лишь читаемость архива, но не то, что база данных, тома, права и состояние приложения удастся восстановить.

Ключевой вывод раздела: GlitchTip делает основную работу по отслеживанию ошибок при куда меньшем развёртывании, чем самостоятельно размещённый Sentry, но проверьте те функции и интеграции Sentry, которыми ваша команда действительно пользуется.

Слой 4, документация: Docmost, AFFiNE и отслеживание задач с OpenProject или Plane

Интерфейс Notion хорош ровно до того момента, когда разрастающаяся вики делает навигацию и поиск тягучими. Для небольшой команды рекомендуемое разделение такое: Docmost для документации и вики, OpenProject для отслеживания задач. Замените OpenProject на Plane, если команде принципиально нужна визуальная модель в духе Linear и вы готовы управлять его поддерживаемым самостоятельным развёртыванием.

Docmost здесь — ближайшая самостоятельно размещаемая замена Notion, которая при этом не притворяется Notion. Его блочный редактор, иерархия страниц и командные права подходят обычной внутренней вики. Размер этого слоя считайте по числу одновременных редакторов, вложениям и тому, делят ли PostgreSQL и Redis один хост. AFFiNE — альтернатива для команд, которым модель холста и доски ближе вложенных страниц. Оба варианта разумны; выберите один.

OpenProject закрывает отслеживание задач для команд, которым привычен рабочий процесс в духе Jira: эпики, рабочие пакеты, спринты и учёт времени. Plane — альтернатива в духе Linear, с более быстрым интерфейсом вокруг задач и иным эксплуатационным следом.

Признаем честно: скорость Linear при работе с клавиатуры действительно хороша, и Plane повторяет не каждое взаимодействие. Если рабочий процесс вашей команды держится на мышечной памяти командного меню Linear, трение при переходе будет вполне реальным. Это не обязательно повод отказаться, но это настоящая цена.

Ключевой вывод раздела: Docmost берёт на себя внутреннюю документацию, а OpenProject или Plane — отслеживание задач; разрыв в клавиатурном удобстве по сравнению с Linear остаётся единственным местом, где этот слой требует компромисса.

Во что обходится этот стек и на чём он работает

Практичная отправная точка для полного стека на базе Forgejo в одной коробке — примерно 8 vCPU и 16 ГБ ОЗУ. Считайте 2 vCPU и 4 ГБ ОЗУ лабораторным размером для нескольких лёгких сервисов, а 4 vCPU и 8 ГБ ОЗУ — урезанным пилотом без OpenProject, Plane и локальных сборок. Реальные требования зависят от числа одновременных пользователей, активности CI, роста баз данных, вложений, хранилища образов, журналов и сроков хранения, поэтому проверьте стек под настоящей нагрузкой и держите 20-30% ёмкости свободными. Стартовый уровень в 16 ГБ вмещает следующие сервисы для слабо нагруженной команды из 2-3 разработчиков, при условии нагрузочного тестирования:

• Forgejo
• Coolify
• Vaultwarden
• Uptime Kuma
• GlitchTip
• Docmost
• OpenProject
• Dockge

Сервер на 4 ГБ годится лишь для нескольких лёгких сервисов. Сервер на 8 ГБ лучше воспринимать как урезанный пилот без OpenProject, Plane и локальных сборок. Полный стек на базе Forgejo начинайте с 16 ГБ и добавляйте ёмкость, когда запускаете GitLab, параллельные сборки, Plane, длительные сроки хранения или более тяжёлые нагрузки на базы данных. Набор SaaS у той же команды включает:

• GitHub Team
• Vercel Pro
• Sentry
• Linear
• Notion
• 1Password

По опубликованным базовым тарифам с каждой страницы цен (включая ставки при годовой оплате, где это применимо). Пять платных продуктов дают в сумме около 158 $ в месяц на трёх человек: GitHub Team по 4 $ за пользователя первые 12 месяцев, три места разработчика в Vercel Pro по 20 $ каждое, Sentry Team от 26 $, Linear Basic по 10 $ за пользователя и Notion Plus по 10 $ за пользователя. Плата за потребление, налоги, дополнения и 1Password идут сверх. Инфраструктура всё ещё может выйти ощутимо дешевле, но сравнение бессмысленно без учёта времени того, кто её обслуживает.

Когда наращивать: база GitLab на одном узле — 8 vCPU и 16 ГБ ОЗУ. Несколько параллельных сборок могут потребовать дополнительной ёмкости даже без GitLab. Самостоятельно размещённый Sentry тоже стартует с 16 ГБ ОЗУ плюс 16 ГБ подкачки и рекомендует 32 ГБ, поэтому в этом руководстве для стека в одной коробке рекомендован GlitchTip.

Незаявленная в прайсе статья — это время на эксплуатацию. Для планирования закладывайте 1-2 часа в месяц на обновления и проверку резервных копий, плюс короткий еженедельный просмотр бюллетеней безопасности по проектам, которые вы запускаете. Настоящая цифра зависит от объёма изменений, реакции на инциденты и степени автоматизации. Она не нулевая, и ей место в модели затрат.

Способ развёртывания меняет удобство, а не эксплуатационные требования. Используете ли вы официальный Compose-файл или шаблон из каталога, фиксируйте версии образов, задавайте лимиты процессора и памяти, храните данные сервисов в именованных томах и проверяйте как резервное копирование, так и восстановление. Собирая весь стек на одном хосте, вы создаёте общий домен отказа, поэтому изолируйте критичные сервисы там, где простой или утечка учётных данных обойдутся дорого.

Если хотите развернуть этот стек, сравните наши планы cloud VPS по процессору, ОЗУ, накопителю SSD или NVMe, объёму трафика и региону, а затем примените изложенную выше схему подбора. Для быстрого старта загляните в наш каталог приложений в один клик, но всё равно фиксируйте версии, задавайте лимиты ресурсов и проверяйте резервные копии до продакшена.

Ключевой вывод раздела: Берите 4 ГБ для небольшой лаборатории, 8 ГБ для урезанного пилота и около 8 vCPU с 16 ГБ ОЗУ как практичную отправную точку для полного стека на базе Forgejo. Добавляйте ёмкость под GitLab, параллельные сборки, более тяжёлые инструменты управления проектами и растущие базы данных.

Где самостоятельный хостинг этого стека действительно проваливается

Четыре сценария отказа, названные прямо, ведь всё остальное руководство было доводом в пользу подхода.

Сценарий отказа 1: сетевой эффект GitHub для публичных open-source проектов. Самостоятельно размещённый git — верное решение для закрытого кода. И неверное для проектов, вся ценность которых зависит от того, найдут ли вас внешние участники. GitHub — первое место, куда смотрят разработчики. Pull request'ы, форки, звёзды, неявный сигнал доверия от того, что вы на github.com, интеграции со сторонними инструментами, всё это. Если ваш проект — публичный open source, честная схема такова: зеркало на GitHub ради видимости, источник истины на Forgejo. Не ждите, что самостоятельный экземпляр заменит обнаружимость GitHub для публичной работы. Не заменит.

Сценарий отказа 2: трафик ботов и скраперов на публичных Git-серверах. Открытые наружу сервисы Forgejo и Gitea требуют средств против злоупотреблений, ограничения частоты запросов, мониторинга и запаса ёмкости под непредсказуемый трафик. Это руководство исходит из частного и командного использования, где административная поверхность спрятана за VPN или списком разрешённых IP. По-настоящему публичная кузница живёт по другой модели угроз и ёмкости.

Сценарий отказа 3: бремя обслуживания. «ИТ-отдел — это вы» — избитая фраза, и она по большей части верна. Обновления что-нибудь ломают. Compose-файлы расползаются. Сертификаты истекают. Резервные копии отказывают молча и самым нелепым образом. Бюллетени безопасности Coolify за 2026 год — полезное напоминание, что ритм установки исправлений важен. Если вы не готовы заранее взять на себя окно обслуживания, набор SaaS, честно говоря, и есть правильный ответ.

Сценарий отказа 4: потеря интеграций. Сторонние GitHub Actions, предпросмотровые развёртывания Vercel, привязанные к pull request'ам GitHub, размещённые интеграции оповещений Sentry с PagerDuty и Linear, обширный каталог интеграций Notion. У большинства есть самостоятельно размещаемые аналоги (Forgejo Actions, развёртывания Coolify по вебхукам, уведомления GlitchTip, n8n как клей между процессами), но замены не всегда один к одному. Соберите прототип самого важного рабочего процесса, прежде чем вести команду на миграцию. Та интеграция, которую вы считаете само собой разумеющейся, вероятнее всего вас и удивит.

Ключевой вывод раздела: Этот стек работает для закрытого кода, небольших команд и готовых к делу операторов; он не работает для видимости публичного open source, для команд, не желающих ни во что вникать, и для ожиданий нулевого обслуживания.

Стек оператора

Четыре слоя, четыре рекомендации, названные честно. Код: Forgejo. Сборка и развёртывание: Coolify с ограниченным управляющим слоем, либо Dokku, либо Compose. Запуск: Vaultwarden, Uptime Kuma, GlitchTip, Portainer или Dockge. Документация: Docmost и OpenProject (или Plane). Урезанный пилот начинайте с 8 ГБ, полный стек на базе Forgejo — с 16 ГБ. Добавляйте ёмкость под GitLab, параллельные сборки, более тяжёлые базы данных или устойчивую нагрузку приложений.

Если вы переезжаете, начните с Uptime Kuma и некритичного внутреннего сервиса. Они дают менее рискованный способ освоить эксплуатационный ритм (обновления, мониторинг, проверка резервных копий и обновление сертификатов), прежде чем переносить командный рабочий процесс или хранилище учётных данных. Не делайте Vaultwarden первым пробным развёртыванием: переносите его лишь после того, как появятся зашифрованные внешние резервные копии, успешный тест восстановления, ограниченный доступ к администрированию и многофакторная аутентификация. Когда ритм станет надёжным, переходите к Forgejo, затем к Coolify, затем к остальному.

Командам, которые целенаправленно выбирают GitLab CE, стоит решить: заменяет ли его встроенный CI/CD отдельный раннер или вашей нагрузке всё же нужны выделенные мощности под сборку.

Часто задаваемые вопросы

Какая самостоятельно размещаемая альтернатива Gitea лучшая в 2026 году?

Forgejo — рекомендованный выбор для тех, кто начинает самостоятельно хостить в 2026 году. Передача в октябре 2022 года товарного знака и домена Gitea коммерческой компании без предварительного одобрения сообщества и вызвала форк Forgejo в конце 2022 года. Начиная с v9.0 выпуски Forgejo идут под GPL v3+; более ранние патч-выпуски v8.0 и v7.0 остались под MIT. В повседневной работе паритет возможностей близок.

Можно ли безопасно запускать Coolify в продакшене в 2026 году?

Да, но только при активном обслуживании и эшелонированной защите. Работайте на последнем проверенном стабильном выпуске, следите за новыми бюллетенями, ограничивайте права команды и держите панель и API за межсетевым экраном, VPN или доверенным уровнем доступа. Не считайте beta.451, beta.474 или любой другой исторический уровень исправлений постоянно безопасным порогом.

Сколько на самом деле оперативной памяти нужно полному самостоятельно размещённому стеку разработчика?

Для команды из 2-3 разработчиков считайте 4 ГБ лабораторным размером для нескольких лёгких сервисов, а 8 ГБ — урезанным пилотом без OpenProject, Plane и локальных сборок. Примерно 8 vCPU и 16 ГБ ОЗУ — практичная отправная точка для полного стека на базе Forgejo. База GitLab в 8 vCPU и 16 ГБ относится к самому GitLab, а самостоятельно размещённый Sentry требует 16 ГБ ОЗУ плюс 16 ГБ подкачки и рекомендует 32 ГБ. Проверьте итоговую конфигурацию в условиях реальной нагрузки.

Почему GlitchTip, а не самостоятельно размещённый Sentry?

Дело в разрыве по ресурсам и эксплуатации. Самостоятельно размещённый Sentry требует минимум 16 ГБ ОЗУ плюс 16 ГБ подкачки и представляет собой крупное развёртывание из многих сервисов. GlitchTip рекомендует 512 МБ для своего всё-в-одном сервиса, требует PostgreSQL и делает Valkey необязательным. Он принимает трафик Sentry SDK, но паритет возможностей неполный, поэтому проверьте те функции и интеграции, от которых вы зависите.

Во сколько на самом деле обходится этот стек по сравнению с SaaS-аналогами?

Считайте 4 ГБ лабораторным размером для нескольких лёгких сервисов, а 8 ГБ — урезанным пилотом без OpenProject, Plane и локальных сборок. Примерно 8 vCPU и 16 ГБ ОЗУ — практичная отправная точка для полного стека на базе Forgejo. По опубликованным базовым ценам GitHub Team, Vercel Pro, Sentry Team, Linear Basic и Notion Plus дают около 158 $ в месяц на трёх человек, без учёта 1Password, платы за потребление, налогов и дополнений. Самостоятельный хостинг может выйти ощутимо дешевле, но время оператора и инфраструктура резервного копирования — вполне реальные затраты.