Самостійно розміщений стек продуктивності розробника: заміна 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 потребує додаткової потужності або окремого навантажувального тестування.
• Де програє: Публічні проєкти з відкритим кодом із зовнішніми учасниками. Мережевий ефект 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. Із самою кодовою базою все гаразд. офіційне порівняння 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-сервіси стикаються з ботами, зловживаннями та компромісами щодо помітності, яких немає в невеликого приватного розгортання. Для публічного відкритого коду робіть дзеркало на 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 для публічних проєктів із відкритим кодом. Самостійно розміщений git — правильне рішення для приватного коду. І неправильне для проєктів, уся цінність яких залежить від того, чи знайдуть вас зовнішні учасники. GitHub — перше місце, куди дивляться розробники. Pull request'и, форки, зірки, неявний сигнал довіри від того, що ви на github.com, інтеграції зі сторонніми інструментами, усе це. Якщо ваш проєкт — публічний відкритий код, чесна схема така: дзеркало на 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 як клей між процесами), але заміни не завжди один до одного. Зберіть прототип найважливішого робочого процесу, перш ніж вести команду на міграцію. Саме та інтеграція, яку ви вважаєте самозрозумілою, найімовірніше вас і здивує.

Ключовий висновок розділу: Цей стек працює для приватного коду, невеликих команд і готових до роботи операторів; він не працює для видимості публічного відкритого коду, для команд, які не хочуть ні в що вникати, і для очікувань нульового обслуговування.

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

Чотири шари, чотири рекомендації, названі чесно. Код: 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, плати за використання, податків і доповнень. Власний хостинг може вийти відчутно дешевшим, але час оператора та інфраструктура резервного копіювання — цілком реальні витрати.