Przy obecnych cenach katalogowych trzyosobowy zespół korzystający z GitHub Team, Vercel Pro, Sentry Team, Linear Basic i Notion Plus zaczyna od około 158 $ miesięcznie, jeszcze bez 1Password, opłat za zużycie i dodatków. Starannie zakrojony stos hostowany samodzielnie potrafi znacząco obniżyć ten rachunek, ale uczciwe porównanie obejmuje większy VPS niż laboratoryjne minimum 4 GB oraz czas na utrzymanie, o którym wszyscy zapominają.
Ten przewodnik jest dla programisty lub małego zespołu, który już uznał, że „rachunek za SaaS irytuje” i że „trzymanie prywatnego kodu oraz deweloperskich przepływów pracy na cudzej infrastrukturze jest niekomfortowe”, a teraz chce wiedzieć, co konkretnie uruchomić. Stos ma cztery warstwy: kod, budowanie i wdrażanie, uruchamianie oraz dokumentację. Każda warstwa dostaje jedno rekomendowane narzędzie, jedną alternatywę, koszt zasobów i tryb awarii. Zakresem jest użycie prywatne i zespołowe na jednym VPS. Hosting poczty, DNS, uwierzytelnianie klientów końcowych i Kubernetes pozostają poza zakresem, z powodów, które wskażemy we właściwym miejscu.
Krótka wersja
Jeśli czytasz tylko punkty:
- Kod: Domyślnie Forgejo. Po GitLab CE sięgnij tylko wtedy, gdy chcesz git, CI/CD, rejestr i zgłoszenia w jednym produkcie; obecna podstawa GitLaba dla pojedynczego węzła to 16 GB RAM, a 8 GB zarezerwowano dla środowisk z ograniczoną pamięcią.
- Budowanie i wdrażanie: 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.
- Uruchom: Vaultwarden do współdzielonych poświadczeń, Uptime Kuma do monitoringu, GlitchTip do śledzenia błędów oraz Portainer lub Dockge do zarządzania kontenerami. GlitchTip to znacznie mniejsze wdrożenie niż samodzielnie hostowany Sentry, którego oficjalne minimum to 16 GB RAM plus 16 GB przestrzeni wymiany.
- Dokumentacja: Docmost do dokumentacji i OpenProject (albo Plane) do śledzenia zgłoszeń. AFFiNE pasuje zespołom, które wolą model Notion w stylu płótna.
- Dobór rozmiaru: Traktuj 4 GB jako rozmiar laboratoryjny dla kilku lekkich usług, 8 GB jako okrojony pilotaż bez OpenProject, Plane i lokalnych buildów, a 16 GB jako praktyczny punkt wyjścia dla pełnego stosu opartego na Forgejo z tego przewodnika. Podstawa GitLaba, 8 vCPU i 16 GB, dotyczy samego GitLaba, więc stos w jednej maszynie oparty na GitLabie wymaga dodatkowej mocy albo osobnych testów obciążeniowych.
- Gdzie przegrywa: Publiczne projekty open source z zewnętrznymi współtwórcami. Efekt sieciowy GitHuba jest realny, a samodzielny hosting kosztuje cię wykrywalność.
Wymagania wstępne
Zanim przeczytasz dalej, ten przewodnik zakłada:
- VPS z Linuksem oraz zainstalowanym Dockerem i Docker Compose. Zaplanuj około 16 GB RAM na pełny stos oparty na Forgejo; 8 GB wystarczy na okrojony pilotaż bez cięższych narzędzi do zarządzania projektami i bez lokalnych buildów.
- Od 30 do 60 minut uwagi na warstwę przy pierwszym wdrożeniu.
- Swoboda w czytaniu pliku Compose i modyfikowaniu zmiennych środowiskowych.
- Gotowość do utrzymywania regularnego okna aktualizacji, szybkiego wgrywania poprawek bezpieczeństwa i weryfikowania kopii zapasowych, a nie tylko ich konfigurowania.
Jeśli którykolwiek z tych punktów jest nie do przyjęcia, pakiet SaaS naprawdę jest właściwą odpowiedzią dla twojego zespołu. To stanowisko do obrony, a nie porażka.
Twórz na VPS Linux z dostępem root, NVMe i mocą AMD EPYC.
Zobacz plany LinuxWarstwa 1, kod: Forgejo, Gitea lub GitLab CE
Trzy realne opcje, trzy różne punkty na krzywej zasobów i zarządzania. Dla zaczynających samodzielny hosting w 2026 roku rekomendacja brzmi najpierw Forgejo.
Forgejo powstało z myślą o skromnej infrastrukturze i oferuje pull requesty, śledzenie zgłoszeń, tablice projektów, wiki, rejestry pakietów oraz Forgejo Actions. Jego przepływy pracy korzystają z formatu w stylu GitHub Actions, ale zgodność nie jest pełna; przetestuj każdą zewnętrzną akcję, od której zależy twój potok.
Gitea wybierz tylko wtedy, gdy już zależysz od funkcji dostępnej wyłącznie w nim albo twoje narzędzia są przypięte do konkretnej wersji Gitea. Samej bazie kodu nic nie brakuje. oficjalne porównanie Forgejo podaje, że fork był następstwem przekazania w październiku 2022 roku domen i znaku towarowego Gitea firmie nastawionej na zysk bez zgody społeczności; ogłoszenie licencyjne Forgejo odnotowuje GPL v3+ dla wersji od v9.0.
GitLab CE wybierz, jeśli chcesz jeden produkt do git, CI/CD, rejestru kontenerów i śledzenia zgłoszeń, a jego próg zasobów jest dla ciebie do udźwignięcia. Aktualne wymagania GitLaba ustalają 16 GB RAM i 8 vCPU jako podstawę dla pojedynczego węzła; 8 GB dotyczy środowisk z ograniczoną pamięcią. Gitea jest na tyle lekkie, że mała prywatna instancja zmieści się w mniej więcej 1-2 GB RAM, a Forgejo wypada podobnie, ale dobór zasobów produkcyjnych w obu przypadkach nadal zależy od repozytoriów, runnerów i liczby jednoczesnych użytkowników.
| Narzędzie | Zasoby startowe | Zarządzanie | Licencja | Wbudowane CI/CD | Kiedy wybrać |
|---|---|---|---|---|---|
| Forgejo | 1-2 vCPU / 1-2 GB RAM (szacunek dla lekkiego użycia) | Prowadzony przez społeczność (Codeberg e.V.) | GPL v3+ (v9.0+) | Forgejo Actions; przetestuj zgodność | Domyślny wybór dla zaczynających samodzielny hosting w 2026 roku |
| Gitea | 1-2 vCPU / 1-2 GB RAM (szacunek dla lekkiego użycia) | Nastawiony na zysk (Gitea Ltd, od października 2022) | MIT | Gitea Actions; przetestuj zgodność | Istniejąca zależność od Gitea albo narzędzia przypięte do konkretnej wersji |
| GitLab CE | 8 vCPU / 16 GB RAM baseline; 8 GB constrained | GitLab Inc | MIT (Community Edition) | Natywne, w pełni funkcjonalne | Chcesz jednej platformy do git, CI/CD, rejestru i zgłoszeń i masz na to RAM |
Kwestię CI warto podkreślić. Gitea Actions zaprojektowano tak, by było w większości zgodne z GitHub Actions, podczas gdy Forgejo Actions celowo stawia na znajome wzorce, a nie na pełną zgodność. Wiele przepływów wymaga tylko drobnych zmian, ale obrazy runnerów, uprawnienia, konteksty, etykiety i akcje zewnętrzne mogą zachowywać się inaczej. Przed migracją przetestuj każdy przepływ i każdą akcję, od której zależy twój potok.
Jedno zastrzeżenie dotyczy wszystkich trzech opcji. Ten przewodnik zakłada użycie prywatne i zespołowe, z powierzchnią administracyjną schowaną za VPN lub listą dozwolonych adresów IP. Publiczne usługi git mierzą się z ruchem botów, nadużyciami i kompromisami wokół wykrywalności, których małe prywatne wdrożenie nie zna. Przy publicznym open source rób mirror na GitHubie dla widoczności, zachowując Forgejo jako źródło prawdy, jeśli ten model zarządzania ma dla ciebie znaczenie.
Serwer dobieraj według obciążenia, a nie według nazw planów dostawcy. Samodzielna usługa Forgejo lub Gitea do lekkiego użytku prywatnego może startować od około 1-2 vCPU i 1-2 GB RAM. Okrojony stos bez OpenProject, Plane i lokalnych buildów może startować od około 4 vCPU i 8 GB RAM. Dla opisanego tu pełnego stosu opartego na Forgejo zacznij od około 8 vCPU i 16 GB RAM, a potem zweryfikuj go pod prawdziwym obciążeniem CI i aplikacji. Oficjalna podstawa GitLaba, 8 vCPU i 16 GB, dotyczy samego GitLaba, więc nie uznawaj jej za wystarczającą dla GitLaba plus reszty tego stosu. Użyj pamięci SSD lub NVMe, osobno zaplanuj budżet na repozytoria, obrazy kontenerów, logi, bazy danych i kopie zapasowe, i zostaw 20-30% wolnej pojemności na aktualizacje i skoki obciążenia.
Kluczowy wniosek z sekcji: Forgejo to domyślna rekomendacja dla warstwy kodu w 2026 roku; Gitea pozostaje solidne, a GitLab CE jest zintegrowanym wyborem tylko wtedy, gdy udźwigniesz jego podstawę 16 GB albo świadomie pracujesz w ograniczonej konfiguracji 8 GB.
Warstwa 2, budowanie i wdrażanie: Coolify (z zastrzeżeniami), Dokku albo czyste Docker Compose
Ujmijmy to uczciwie: Coolify jest rekomendowaną opcją PaaS dla tego stosu, jeśli działasz na najnowszym wydaniu produkcyjnym, trzymasz panel administracyjny poza publicznym internetem i śledzisz komunikaty bezpieczeństwa. W chwili kontroli jakości GitHub oznacza Coolify v4.3.0 Coolify v4.1.2 jako najnowsze. Traktuj łatanie i izolację płaszczyzny administracyjnej jako wymogi eksploatacyjne, a nie opcjonalne utwardzanie.
Wskazówka: Ogranicz panel i API Coolify zaporą sieciową, VPN-em albo zaufanym proxy dostępowym. Wdrożone aplikacje mogą dalej przyjmować ruch publiczny; celem jest zmniejszenie ekspozycji administracyjnej płaszczyzny sterowania.
Alternatywą dla samodzielnych programistów jest Dokku, zwarty PaaS z wdrożeniami przez git push w stylu Heroku i obsługą buildpacków. Ma mniejszą powierzchnię niż Coolify i odpowiednio mniejszy zestaw funkcji. To czyni z niego dający się obronić „nudny wybór” dla jednego czy dwóch programistów, którzy nie potrzebują panelu.
Trzecia opcja, po którą sięgają doświadczeni operatorzy, to żadnego PaaS, tylko Docker Compose. Jeśli twój zespół i tak pisze pliki Compose, a ty wolisz widzieć ruchome części, to całkowicie rozsądna odpowiedź. Dodaj Dockge albo Portainer jako warstwę interfejsu do zarządzania stosami, gdy zechcesz restartu jednym kliknięciem zamiast docker compose restart. Kompromis jest operacyjny: brak środowisk podglądu, brak wbudowanej automatyzacji TLS, brak wdrożeń bez przestoju bez dodatkowej pracy. Te funkcje zdobywa się, pisząc skrypty; w Coolify są gotowe, wraz z dołączoną do nich historią bezpieczeństwa.
Przewodnik Cloudzy po najlepszych narzędziach CI/CD omawia potok budowania głębiej dla zespołów, które potrzebują osobnego runnera, a wiele małych zespołów go nie potrzebuje, gdy działa już Forgejo Actions albo CI/CD GitLaba.
Kluczowy wniosek z sekcji: Coolify jest rekomendowanym PaaS tylko na aktualnym wydaniu stabilnym i z ograniczoną płaszczyzną administracyjną; Dokku to zachowawczy wybór dla samodzielnych; czyste Docker Compose pozostaje dającą się obronić trzecią opcją.
Warstwa 3, uruchamianie: Vaultwarden, Uptime Kuma, GlitchTip i zarządzanie kontenerami
To tutaj mieszka najostrzejsza różnica w zapotrzebowaniu na zasoby w całym stosie. Oficjalne wymagania Sentry przy samodzielnym hostowaniu podają jako minimum 4 rdzenie procesora, 16 GB RAM, 16 GB przestrzeni wymiany i 20 GB wolnego dysku, a zalecają 32 GB RAM. Przewodnik instalacji GlitchTip zaleca 512 MB RAM, wymaga PostgreSQL i pozostawia Valkey jako opcjonalne. Dla małego zespołu na jednym VPS GlitchTip jest praktycznym wyborem domyślnym.
| Narzędzie | RAM (typowo) | Liczba kontenerów | Zgodność API |
|---|---|---|---|
| Samodzielnie hostowany Sentry | 16 GB RAM plus 16 GB swap minimum; 32 GB recommended | Duże wdrożenie z wieloma usługami | Natywny |
| GlitchTip | 512 MB recommended; 256 MB minimum for the all-in-one setup | 2 usługi podstawowe; Valkey opcjonalnie | Ruch z Sentry SDK; sprawdź parzystość funkcji |
Pozostałe cztery narzędzia w tej warstwie to krótkie historie.
Vaultwarden to menedżer haseł zgodny z Bitwardenem, obsługujący aplikacje mobilne i rozszerzenia przeglądarki Bitwarden oraz udostępnianie w zespole. Jego rzeczywisty ślad zależy od liczby użytkowników, załączników i wyboru bazy danych. Porównanie samodzielnie hostowanych menedżerów haseł od Cloudzy zagłębia się w kompromis, gdy potrzebujesz bardziej ustrukturyzowanych uprawnień, kontroli audytowych albo innego modelu bezpieczeństwa.
Uptime Kuma to niewielkie narzędzie do monitoringu i alertów: kontrole HTTP, TCP, ping, push i wygasania certyfikatów oraz opcjonalne strony statusu. Powiadomienia mogą iść czatem, e-mailem albo webhookami. Zużycie zasobów zmienia się wraz z liczbą monitorów i długością retencji; alarmowanie dopiero przy drugiej awarii z rzędu to praktyczny sposób na wyciszenie krótkich zakłóceń.
GlitchTip to tropiciel błędów. Większość integracji Sentry SDK potrafi raportować do DSN GlitchTipa, ale parzystość funkcji nie jest pełna; przetestuj monitorowanie wydajności, source mapy, alerty i każdą integrację, którą twój zespół uznaje za krytyczną.
Na interfejs kontenerów wybierz Portainer albo Dockge. Portainer obejmuje szerszy zakres zarządzania kontenerami; Dockge trzyma się Docker Compose. Do małego stosu opartego wyłącznie na Compose Dockge pasuje czyściej. Na Portainer przejdź dopiero wtedy, gdy potrzebujesz tego szerszego zasięgu.
Przydatna ergonomia Compose dla tej warstwy: trzymaj każde narzędzie w osobnym podkatalogu z własnym compose.yml, współdziel sieć Dockera tylko tam, gdzie ruch między narzędziami jest potrzebny, i postaw z przodu jedno odwrotne proxy do terminacji 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"Wskazówka: Kopia zapasowa jest udowodniona dopiero wtedy, gdy usługę da się odtworzyć, a jej dane zweryfikować. Raz w miesiącu odtwórz jedną reprezentatywną usługę w odizolowanym środowisku testowym, uruchom ją, zaloguj się, przejrzyj rekordy i załączniki i potwierdź, że aplikacja zachowuje się normalnie. Wypisanie odtworzonych plików dowodzi tylko tego, że archiwum daje się odczytać, a nie że bazę danych, wolumeny, uprawnienia i stan aplikacji da się skutecznie odzyskać.
Kluczowy wniosek z sekcji: GlitchTip wykonuje sedno pracy przy śledzeniu błędów przy drastycznie mniejszym wdrożeniu niż samodzielnie hostowany Sentry, ale zweryfikuj te funkcje i integracje Sentry, z których twój zespół faktycznie korzysta.
Warstwa 4, dokumentacja: Docmost, AFFiNE i śledzenie zgłoszeń z OpenProject albo Plane
Interfejs Notion jest w porządku, dopóki rosnące wiki nie sprawi, że nawigacja i wyszukiwanie zaczną wlec się w nieskończoność. Dla małego zespołu rekomendowany podział to Docmost na dokumentację i wiki oraz OpenProject na śledzenie zgłoszeń. Zamień OpenProject na Plane, jeśli twój zespół chce konkretnie modelu wizualnego w stylu Lineara i nie boi się zarządzać jego wspieranym wdrożeniem hostowanym samodzielnie.
Docmost jest tu najbliższym samodzielnie hostowanym zamiennikiem Notion, nie udając przy tym Notion. Jego edytor blokowy, hierarchia stron i uprawnienia zespołowe pasują do klasycznego wiki wewnętrznego. Tę warstwę dobierz według liczby jednoczesnych edytujących, załączników oraz tego, czy PostgreSQL i Redis dzielą ten sam host. AFFiNE to alternatywa dla zespołów, które wolą model płótna i tablicy od zagnieżdżonych stron. Oba są sensowne; wybierz jedno.
OpenProject obsługuje śledzenie zgłoszeń dla zespołów, którym odpowiada przepływ w stylu Jira: epiki, pakiety pracy, sprinty i ewidencja czasu. Plane to alternatywa w kształcie Lineara, z szybszym interfejsem skupionym na zgłoszeniach i innym profilem eksploatacyjnym.
Przyznajmy uczciwie: szybkość Lineara opartego na klawiaturze jest naprawdę dobra, a Plane nie odtwarza każdej interakcji. Jeśli przepływ pracy twojego zespołu stoi na pamięci mięśniowej menu poleceń Lineara, tarcie migracyjne jest realne. Niekoniecznie przekreśla to sprawę, ale to prawdziwy koszt.
Kluczowy wniosek z sekcji: Docmost obejmuje rolę dokumentacji wewnętrznej, a OpenProject albo Plane śledzenie zgłoszeń; luka w obsłudze klawiaturowej względem Lineara to jedyne miejsce, w którym ta warstwa prosi cię o ustępstwo.
Ile kosztuje ten stos i na czym działa
Praktyczny punkt wyjścia dla pełnego stosu opartego na Forgejo w jednej maszynie to około 8 vCPU i 16 GB RAM. Traktuj 2 vCPU i 4 GB RAM jako rozmiar laboratoryjny dla kilku lekkich usług, a 4 vCPU i 8 GB RAM jako okrojony pilotaż bez OpenProject, Plane i lokalnych buildów. Rzeczywiste wymagania zależą od liczby jednoczesnych użytkowników, aktywności CI, przyrostu baz danych, załączników, magazynu obrazów, logów i retencji, więc zweryfikuj stos pod prawdziwym obciążeniem i zostaw 20-30% wolnej pojemności. Poziom startowy 16 GB pomieści następujące usługi dla lekko obciążonego zespołu 2-3 programistów, z zastrzeżeniem testów obciążeniowych:
- Forgejo
- Coolify
- Vaultwarden
- Uptime Kuma
- GlitchTip
- Docmost
- OpenProject
- Dockge
Serwer 4 GB nadaje się tylko do kilku lekkich usług. Serwer 8 GB lepiej traktować jako okrojony pilotaż bez OpenProject, Plane i lokalnych buildów. Pełny stos oparty na Forgejo zacznij od 16 GB i dokładaj mocy, gdy dojdzie GitLab, równoległe buildy, Plane, długie okresy retencji albo cięższe obciążenia baz danych. Pakiet SaaS tego samego zespołu obejmuje:
- GitHub Team
- Vercel Pro
- Sentry
- Linear
- Notion
- 1Password
Na podstawie opublikowanych stawek bazowych z każdej strony cennika (w tym stawek przy rozliczeniu rocznym, gdzie mają zastosowanie). Pięć płatnych produktów daje razem około 158 $ miesięcznie dla trzech osób: GitHub Team po 4 $ za użytkownika przez pierwsze 12 miesięcy, trzy stanowiska deweloperskie w Vercel Pro po 20 $ każde, Sentry Team od 26 $, Linear Basic po 10 $ za użytkownika oraz Notion Plus po 10 $ za użytkownika. Opłaty za zużycie, podatki, dodatki i 1Password dochodzą osobno. Infrastruktura wciąż może wyjść zauważalnie taniej, ale bez czasu operatora porównanie nic nie znaczy.
Kiedy dołożyć zasobów: podstawa GitLaba dla jednego węzła to 8 vCPU i 16 GB RAM. Kilka równoległych buildów może wymagać dodatkowej mocy nawet bez GitLaba. Samodzielnie hostowany Sentry też startuje od 16 GB RAM plus 16 GB przestrzeni wymiany i zaleca 32 GB, i właśnie dlatego ten przewodnik poleca GlitchTipa do stosu w jednej maszynie.
Nieujętym w cenniku kosztem jest czas eksploatacji. Na potrzeby planowania załóż 1-2 godziny miesięcznie na aktualizacje i weryfikację kopii zapasowych, plus krótki cotygodniowy przegląd komunikatów bezpieczeństwa dla projektów, które prowadzisz. Prawdziwa liczba zależy od wolumenu zmian, reagowania na incydenty i stopnia automatyzacji. Nie jest zerowa i ma swoje miejsce w modelu kosztów.
Metoda wdrożenia zmienia wygodę, a nie wymogi eksploatacyjne. Czy używasz oficjalnego pliku Compose, czy szablonu z marketplace: przypnij wersje obrazów, ustaw limity procesora i pamięci, trzymaj dane usług w nazwanych wolumenach i testuj zarówno kopie zapasowe, jak i odtwarzanie. Zebranie całego stosu na jednym hoście tworzy też wspólną domenę awarii, więc izoluj usługi krytyczne tam, gdzie przestój albo wyciek poświadczeń mocno zaboli.
Jeśli chcesz wdrożyć ten stos, porównaj nasze plany cloud VPS według procesora, RAM, magazynu SSD lub NVMe, limitu transferu i regionu, a potem zastosuj powyższe ramy doboru zasobów. Aby uruchomić to szybciej, przejrzyj nasz katalog aplikacji na jedno kliknięcie, ale i tak przypnij wersje, ustaw limity zasobów i zweryfikuj kopie zapasowe przed produkcją.
Kluczowy wniosek z sekcji: Weź 4 GB na małe laboratorium, 8 GB na okrojony pilotaż i około 8 vCPU z 16 GB RAM jako praktyczny punkt wyjścia dla pełnego stosu opartego na Forgejo. Dołóż mocy pod GitLaba, równoległe buildy, cięższe narzędzia do zarządzania projektami i rosnące bazy danych.
Gdzie samodzielne hostowanie tego stosu naprawdę zawodzi
Cztery tryby awarii, nazwane wprost, bo reszta tego przewodnika była argumentacją za tym podejściem.
Tryb awarii 1: efekt sieciowy GitHuba przy publicznych projektach open source. Samodzielnie hostowany git jest właściwy dla kodu prywatnego. Jest niewłaściwy dla projektów, których cała wartość zależy od tego, czy znajdą cię zewnętrzni współtwórcy. GitHub to miejsce, w które programiści zaglądają najpierw. Pull requesty, forki, gwiazdki, dorozumiany sygnał zaufania płynący z bycia na github.com, integracje z narzędziami zewnętrznymi, wszystko to. Jeśli twój projekt jest publicznym open source, uczciwy wzorzec brzmi: rób mirror na GitHubie dla widoczności, a źródło prawdy trzymaj na Forgejo. Nie licz, że instancja hostowana samodzielnie zastąpi wykrywalność GitHuba w pracy publicznej. Nie zastąpi.
Tryb awarii 2: ruch botów i scraperów na publicznych instancjach Gita. Publicznie dostępne usługi Forgejo i Gitea potrzebują zabezpieczeń przed nadużyciami, limitów żądań, monitoringu i zapasu mocy na nieprzewidywalny ruch. Ten przewodnik zakłada użycie prywatne i zespołowe, z powierzchnią administracyjną za VPN-em albo listą dozwolonych IP. Naprawdę publiczna kuźnia ma inny model zagrożeń i inny model pojemności.
Tryb awarii 3: ciężar utrzymania. „To ty jesteś działem IT” to komunał, i w większości prawdziwy. Aktualizacje coś psują. Pliki Compose się rozjeżdżają. Certyfikaty wygasają. Kopie zapasowe zawodzą po cichu, w najmniej godny sposób. Komunikaty bezpieczeństwa Coolify z 2026 roku dobrze przypominają, że tempo łatania ma znaczenie. Jeśli nie potrafisz z góry zobowiązać się do okna serwisowego, uczciwą odpowiedzią jest pakiet SaaS.
Tryb awarii 4: utrata integracji. Zewnętrzne akcje GitHuba, wdrożenia podglądowe Vercela powiązane z pull requestami na GitHubie, hostowane integracje alertów Sentry z PagerDuty i Linearem, szeroki katalog integracji Notion. Większość ma samodzielnie hostowane odpowiedniki (Forgejo Actions, wdrożenia Coolify przez webhooki, powiadomienia GlitchTipa, n8n jako klej między przepływami), ale zamienniki nie zawsze są jeden do jednego. Zanim zwiążesz zespół migracją, zrób prototyp tego przepływu, który liczy się najbardziej. Integracja, którą uznajesz za oczywistą, najpewniej cię zaskoczy.
Kluczowy wniosek z sekcji: Ten stos działa dla kodu prywatnego, małych zespołów i chętnych operatorów; nie działa dla widoczności publicznego open source, dla zespołów, które nie chcą przy niczym grzebać, ani dla oczekiwań zerowego utrzymania.
Stos operatora
Cztery warstwy, cztery rekomendacje, nazwane wprost. Kod: Forgejo. Budowanie i wdrażanie: Coolify z ograniczoną płaszczyzną administracyjną, albo Dokku, albo Compose. Uruchamianie: Vaultwarden, Uptime Kuma, GlitchTip, Portainer lub Dockge. Dokumentacja: Docmost i OpenProject (albo Plane). Okrojony pilotaż zacznij od 8 GB, a pełny stos oparty na Forgejo od 16 GB. Dołóż mocy pod GitLaba, równoległe buildy, cięższe bazy danych albo stałe obciążenie aplikacji.
Jeśli migrujesz, zacznij od Uptime Kuma i niekrytycznej usługi wewnętrznej. Dają mniej ryzykowny sposób na nauczenie się rytmu eksploatacji (aktualizacje, monitoring, weryfikacja kopii zapasowych i odnawianie certyfikatów), zanim przeniesiesz zespołowy przepływ pracy albo skarbiec poświadczeń. Nie rób z Vaultwardena pierwszego wdrożenia testowego: przenieś go dopiero wtedy, gdy masz zaszyfrowane kopie poza hostem, udany test odtworzenia, ograniczoną administrację i uwierzytelnianie wieloskładnikowe. Gdy ten rytm będzie już pewny, przejdź do Forgejo, potem Coolify, potem reszty.
Zespoły, które wybierają akurat GitLab CE, niech rozstrzygną, czy jego natywne CI/CD zastępuje osobnego runnera, czy ich obciążenie nadal wymaga dedykowanej mocy do budowania.
Często zadawane pytania
Jaka jest najlepsza samodzielnie hostowana alternatywa dla Gitea w 2026 roku?
Forgejo to rekomendowany wybór dla zaczynających samodzielny hosting w 2026 roku. Przekazanie w październiku 2022 roku znaku towarowego i domeny Gitea firmie nastawionej na zysk, bez uprzedniej zgody społeczności, wywołało pod koniec 2022 roku fork Forgejo. Od v9.0 wydania Forgejo korzystają z GPL v3+; wcześniejsze wydania poprawkowe v8.0 i v7.0 pozostały na MIT. W codziennej pracy parzystość funkcji jest bliska.
Czy w 2026 roku można bezpiecznie uruchomić Coolify na produkcji?
Tak, ale wyłącznie przy aktywnym utrzymaniu i obronie w głąb. Uruchamiaj najnowsze przejrzane wydanie stabilne, śledź nowe komunikaty, ograniczaj uprawnienia zespołu i trzymaj panel oraz API za zaporą, VPN-em albo zaufaną warstwą dostępu. Nie traktuj beta.451, beta.474 ani żadnego innego historycznego poziomu poprawek jako trwale bezpiecznego progu.
Ile RAM naprawdę potrzebuje pełny samodzielnie hostowany stos deweloperski?
Dla zespołu 2-3 programistów traktuj 4 GB jako rozmiar laboratoryjny dla kilku lekkich usług, a 8 GB jako okrojony pilotaż bez OpenProject, Plane i lokalnych buildów. Około 8 vCPU i 16 GB RAM to praktyczny punkt wyjścia dla pełnego stosu opartego na Forgejo. Podstawa GitLaba, 8 vCPU i 16 GB, dotyczy samego GitLaba, podczas gdy samodzielnie hostowany Sentry wymaga 16 GB RAM plus 16 GB przestrzeni wymiany i zaleca 32 GB. Zweryfikuj ostateczną konfigurację w warunkach prawdziwego obciążenia.
Dlaczego GlitchTip zamiast samodzielnie hostowanego Sentry?
Chodzi o różnicę w zasobach i w eksploatacji. Samodzielnie hostowany Sentry wymaga co najmniej 16 GB RAM plus 16 GB przestrzeni wymiany i jest dużym wdrożeniem z wieloma usługami. GlitchTip zaleca 512 MB dla swojej usługi all-in-one, wymaga PostgreSQL i pozostawia Valkey jako opcjonalne. Przyjmuje ruch z Sentry SDK, ale parzystość funkcji nie jest pełna, więc przetestuj funkcje i integracje, od których zależysz.
Ile naprawdę kosztuje ten stos w porównaniu z odpowiednikami SaaS?
Traktuj 4 GB jako rozmiar laboratoryjny dla kilku lekkich usług, a 8 GB jako okrojony pilotaż bez OpenProject, Plane i lokalnych buildów. Około 8 vCPU i 16 GB RAM to praktyczny punkt wyjścia dla pełnego stosu opartego na Forgejo. W opublikowanych cenach bazowych GitHub Team, Vercel Pro, Sentry Team, Linear Basic i Notion Plus dają razem około 158 $ miesięcznie dla trzech osób, jeszcze bez 1Password, opłat za zużycie, podatków i dodatków. Samodzielny hosting może wyjść zauważalnie taniej, ale czas operatora i infrastruktura kopii zapasowych to koszty jak najbardziej realne.
