Jak Samodzielnie Hostować GitLab CE na VPS

Jest piątkowe popołudnie, pull request twojego zespołu czeka na recenzję, a twój laptop sygnalizuje znany komunikat: GitHub znów ma problemy.

Może działania utknęły.

Może `git push` zwraca błąd 500 po raz trzeci w tym miesiącu.

Wątek na czacie twojego zespołu ma już osiem wiadomości.

Pierwszym razem się z tego śmiejesz. Drugim razem ktoś podaje link do strony statusu GitHub, i wszyscy idziecie na kawę. Trzecim razem, zazwyczaj tuż przed oknem wydania, ktoś w końcu zadaje pytanie na głos: „Może po prostu uruchomić własne?”

Dla większości zespołów, szczerze mówiąc, odpowiedź brzmi nie. GitLab.com Free wystarcza małym zespołom, a koszt operacyjny prowadzenia własnego serwera kontroli wersji nie jest zerowy.

To rodzaj transakcji, którą przeprowadza się tylko z prawdziwego powodu.

Jeśli Twój zespół ma jeden z tych powodów, takich jak umowa z klientem zabraniająca korzystania z usług SaaS przez strony trzecie, granica zgodności lub rachunek za licencję, który zaczyna wyglądać absurdalnie, samodzielne hostowanie GitLab CE to najczystsze rozwiązanie, które możesz wybrać. Jest to oprogramowanie open source, działa na pojedynczym VPS i po odpowiednim skonfigurowaniu, utrzymanie zajmuje około godziny miesięcznie.

W DreamHost hostowaliśmy już niezliczone serwery zarządzane samodzielnie, i widzimy pewien wzorzec: programiści, którzy odnoszą sukces z samodzielnie hostowanym GitLab, wybierają odpowiedni plan na początku, dobrze przygotowują Protokół Secure Shell (SSH) oraz DNS, a następnie powstrzymują się od nieustannego modyfikowania, gdy system jest stabilny.

Dlaczego warto samodzielnie hostować GitLab zamiast korzystać z GitLab.com?

Hostujesz samodzielnie GitLab, gdy GitLab.com lub GitHub.com nie spełniają twoich wymagań dotyczących prywatności, zgodności lub kontroli kosztów. Dla większości innych zespołów lepszym rozwiązaniem jest opcja hostowana.

Trzy prawdziwe powody wytrzymują krytykę:

1. Prywatność I Suwerenność Danych: Twój kod źródłowy znajduje się na infrastrukturze, którą zarządzasz i aktualizujesz według własnego harmonogramu. Bez dostępu osób trzecich, bez współdzielonej platformy, bez ryzyka naruszenia danych poza własnym serwerem.
2. Zgodność: Regulowane branże takie jak opieka zdrowotna, finanse i administracja publiczna często wymagają kontroli rezydencji danych. Samodzielnie hostowane GitLab CE to najprostszy sposób, aby utrzymać kod w kontrolowanej przestrzeni. 
3. Kontrola Kosztów Na Dużą Skalę: GitLab.com pobiera opłaty za każdego aktywnego użytkownika. Zgodnie ze stroną cenową GitLab, Premium kosztuje 29 dolarów za użytkownika miesięcznie, a ceny Ultimate są dostępne tylko na życzenie. Zespół 50-osobowy na Premium kosztuje 17 400 dolarów rocznie przed dodatkami. Samodzielnie zarządzany VPS plus godzina miesięcznej konserwacji często kosztuje mniej.

Jeśli jesteście dwuosobowym zespołem bez powodów związanych z prywatnością czy przestrzeganiem przepisów, odpowiedzią jest darmowa wersja GitLab. (Tak, wiemy, że to brzmi śmiesznie, jak na firmę hostingową).

Decydując się na samodzielny hosting, zamieniasz miesięczny rachunek za SaaS na stały czas operacyjny. To się opłaca tylko, jeśli masz dobry powód, by dokonać zmiany.

Oto kiedy ta opcja ma sens, a kiedy nie:

Scenariusz	Najlepsze dopasowanie
Wymóg prywatności lub zgodności	Samodzielnie hostowany GitLab CE
Zespół większy niż około 30 aktywnych użytkowników	Samodzielne hostowanie jest często tańsze
Kod jest Twoją własnością intelektualną i chcesz go przechowywać lokalnie	Samodzielnie hostowany GitLab CE
Zespół 2-5 osób, brak potrzeb zgodności	GitLab.com (darmowe)
Nie chcesz aktualizować serwera	GitLab.com

Edycja społeczności GitLab jest dostępna za darmo na licencji open-source w stylu MIT. Nie ma limitu użytkowników, braku ograniczeń funkcjonalności podstawowych i braku zachęt do dokupowania. Cała platforma jest do twojej dyspozycji.

Jakie Są Wymagania Sprzętowe Dla GitLab CE?

GitLab CE ma jasno określone progi sprzętowe, a ich właściwe ustawienie to różnica między szybką instalacją a taką, która męczy się przez swap memory (przestrzeń dyskową, której używa system operacyjny, gdy pamięć RAM się zapełni).

Zgodnie z oficjalnymi wymaganiami instalacyjnymi GitLab, wielkość jest wyrażana w żądaniach na sekundę, a nie w stałych progach na użytkownika. Opublikowana specyfikacja to 8 vCPU i 16 GB RAM dla maksymalnie 1000 użytkowników (około 20 żądań na sekundę). Mniejsze zespoły mogą pracować na mniejszych zasobach, aż do dokumentowanego minimum 2 GB RAM plus 1 GB swap dla celów ewaluacyjnych, chociaż wydajność spada poniżej 4 GB.

Świeża instalacja GitLab zużywa około 4-6 GB w stanie bezczynności. Gdy zaczną działać zadania CI/CD, zużycie pamięci szybko wzrasta. Dlatego zaplanuj dodatkowe zasoby — lub przygotuj się na spowolnienie.

Jeśli chodzi o pamięć, oficjalne minimalne wymagania GitLab to 40 GB plus rozmiar repozytorium, ale 50 GB to bezpieczniejszy punkt wyjścia w praktyce. Repozytoria rosną, a artefakty budowy się nagromadzają. NVMe, szybszy typ pamięci SSD, znacząco wpływa na operacje Git i odczyty pamięci podręcznej CI.

Oto jak te progi odpowiadają poziomom hostingu VPS DreamHost:

Przypadek użycia	Zalecane RAM	Poziom VPS DreamHost
Ocena / osobiste	4 GB RAM	Stack 4
Mały zespół, niewielkie użycie	8 GB RAM	Stack 8
Do ~1,000 użytkowników (opublikowana bazowa wartość GitLab)	16 GB RAM	Stack 16
Uruchamianie CI/CD runnerów na tej samej maszynie	+ 2-8 GB RAM na dodatek do Twojego poziomu	Zwiększ rozmiar (np. Stack 16 → Stack 32)

Właściwym punktem wyjścia dla większości zespołów uruchamiających rzeczywiste potoki CI/CD jest Stack 16. Może się to wydawać nadmiernym rozwiązaniem, dopóki nie zobaczysz, jak uruchamia się pierwsza kompilacja i naraz wzrasta obciążenie Sidekiq, Postgres i runnera.

16 GB RAM zapewnia wystarczającą ilość miejsca na stos usług GitLab (około 4 do 6 GB w stanie bezczynności przy domyślnej instalacji) oraz na kilku pracowników CI (1-2 GB każdy), aby mogli pracować jednocześnie bez zauważalnych opóźnień w komunikatorze zespołu.

Jak Przygotować Swoje VPS Przed Instalacją GitLab?

Poświęć 10 minut na przygotowanie — opłaca się za pierwszym razem, gdy uruchomisz ponownie. Po prostu wykonaj te kroki:

1. Skonfiguruj VPS: Wybierz Ubuntu 22.04 LTS lub 24.04 LTS. Oba są obsługiwane przez oficjalne pakiety Omnibus GitLab (zestaw instalacyjny wszystko w jednym dostarczany przez GitLab) i mają przed sobą wiele lat darmowych aktualizacji bezpieczeństwa.
   
2. Skieruj domenę na IP serwera: Utwórz rekord A (typ rekordu DNS, który mapuje domenę na adres IP) i pozwól mu się rozejść przez co najmniej 15-30 minut przed instalacją. Bez tego automatyczna konfiguracja SSL zawiedzie, ponieważ organ certyfikujący nie będzie miał skąd dokonać weryfikacji.
   
3. Aktualizuj pakiety: Połącz się z VPS używając `ssh root@twoje-ip-serwera` i wykonaj `sudo apt update && sudo apt upgrade -y`.
   
4. Zainstaluj zależności: Uruchom `sudo apt install -y curl openssh-server ca-certificates perl postfix`. Pakiet `postfix` to serwer pocztowy, który obsługuje pocztę wychodzącą, dzięki czemu GitLab może wysyłać powiadomienia o scaleniach żądań i resetowania haseł.
   Kiedy instalator zapyta o konfigurację poczty, wybierz Internet Site i użyj swojej domeny. To pozwoli GitLabowi natychmiast rozpocząć wysyłanie poczty.
   Do użytku produkcyjnego: pomiń lokalny postfix i skonfiguruj przekaz SMTP w gitlab.rb. Adresy IP VPS są często na listach blokowania spamu, a e-maile resetujące hasło wysyłane przez lokalny postfix często trafiają do spamu. SendGrid, Mailgun i zewnętrzny przekaźnik DreamHost działają — zobacz dokumentację konfiguracji SMTP GitLab SMTP configuration docs.
   
5. Otwórz odpowiednie porty: Skonfiguruj zaporę ogniową za pomocą UFW (wbudowane narzędzie firewalla Ubuntu) i zezwól na porty 80, 443, i 22.

sudo ufw allow http
sudo ufw allow https
sudo ufw allow ssh
sudo ufw enable

Jak Zainstalować GitLab CE Na Ubuntu Korzystając Z Pakietu Omnibus?

Dodaj repozytorium GitLab CE:

curl -sSL https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash

Następnie zainstaluj GitLab CE z ustawionym Twoim domeną jako zewnętrzny URL:

sudo EXTERNAL_URL="https://gitlab.example.com" apt install gitlab-ce

Ustawienie `https://` tutaj informuje GitLab o automatycznym żądaniu certyfikatu Let’s Encrypt podczas instalacji, pod warunkiem, że porty 80 i 443 są otwarte oraz DNS jest poprawnie skierowany. Jeśli którekolwiek z tych nie jest gotowe, instalacja zostaje zakończona, ale SSL zawodzi — i spędzasz następne trzydzieści minut na rozwiązywaniu problemu, który tak naprawdę nie istnieje.

Następnie poczekaj na krok rekonfiguracji.

GitLab uruchamia `gitlab-ctl reconfigure` (polecenie, które stosuje wszelkie zmiany w konfiguracji GitLab) automatycznie na końcu instalacji. Trwa to od pięciu do 10 minut. I tak, krok rekonfiguracji naprawdę trwa tak długo.

Pobierz początkowe hasło root:

sudo cat /etc/gitlab/initial_root_password

Ten plik jest generowany automatycznie i zostanie usunięty po 24 godzinach, więc zapisz hasło i zaloguj się. Odwiedź swoją domenę w przeglądarce, zaloguj się jako `root` i natychmiast zmień hasło.

Na koniec, zweryfikuj instalację.

Z ekranu powitalnego GitLab, stwórz projekt testowy. Wyślij commit z lokalnego komputera. Jeśli wysyłka się powiedzie i plik pojawi się w interfejsie webowym, instalacja jest prawidłowa.

Jeśli krok rekonfiguracji utknie, sprawdź `tail -f /var/log/gitlab/reconfigure/*.log`. To tam znajduje się faktyczny błąd.

Jak Zabezpieczyć Samodzielnie Hostowaną Instancję GitLab?

GitLab jest dostarczany z rozsądnymi ustawieniami domyślnymi, ale są one dostosowane do serwera społeczności otwartej, a nie twojej prywatnej instancji zespołu. Poświęć tutaj godzinę.

1. Wyłącz Otwarte Zapisy. Domyślnie otwarte zapisy są włączone. W Obszarze Admina przejdź do Ustawień > Ogólne > Ograniczenia zapisów i wyłącz pole wyboru „Zapisy włączone”. W przeciwnym razie każdy, kto ma URL, może założyć konto.
2. Włącz uwierzytelnianie dwuskładnikowe. Przejdź do Obszaru Admina > Ustawień > Ogólne > Ograniczenia logowania i wymuś 2FA dla wszystkich użytkowników. Skróć okres łaski z domyślnych 48 godzin do 8 godzin.
3. Ogranicz tworzenie projektów. Ustaw Domyślne Tworzenie Projektu na Opiekunów lub Nikogo, w zależności od tego, jak bardzo chcesz to zablokować.
4. Sprawdź odnowienie certyfikatu SSL. Domyślnie GitLab automatycznie odnawia certyfikaty Let’s Encrypt. Aby potwierdzić, uruchom raz `sudo gitlab-ctl renew-le-certs` i sprawdź wynik.
5. Zablokuj SSH na samym VPS. Wyłącz logowanie hasłem root, zezwól tylko na uwierzytelnianie kluczem SSH i (jeśli możesz) przenieś SSH z portu 22. Samodzielnie hostowany serwer Git jest tak bezpieczny, jak serwer, na którym się znajduje.

Aby uzyskać bardziej szczegółowe informacje, GitLab opublikował Przewodnik Zabezpieczania obejmujący uwierzytelnianie, szyfrowanie i ustawienia instancji. Przeczytaj go raz, zastosuj to, co pasuje do twojego modelu zagrożeń i kontynuuj.

Jak Wykonać Kopię Zapasową i Przywrócić Samodzielnie Hostowaną Instancję GitLab?

GitLab zawiera wbudowane narzędzie do tworzenia kopii zapasowych. Pierwszym razem, gdy będziesz tego potrzebować, będziesz zadowolony, że je skonfigurowałeś.

Utwórz kopię zapasową:

sudo gitlab-backup create

To umieszcza plik tar w `/var/opt/gitlab/backups`. Zaplanuj to codziennie za pomocą Cron Job z oknem retencji siedmiu dni. Uruchom sudo crontab -e i dodaj te dwie linie:

0 2 * * * /opt/gitlab/bin/gitlab-backup create CRON=1
0 3 * * * find /var/opt/gitlab/backups -name "*.tar" -mtime +7 -delete

Flaga CRON=1 tłumi wyświetlanie postępów, aby nie zaśmiecać dzienników cron.

Porada: kopia zapasowa danych nie zawiera `/etc/gitlab/gitlab-secrets.json` ani `/etc/gitlab/gitlab.rb`.

Te pliki zawierają klucz szyfrowania bazy danych, ziarna dwuskładnikowe oraz zmienne CI/CD. Sekrety konfiguracyjne nie są częścią regularnej kopii zapasowej i muszą być zapisane osobno. Przywrócenie danych bez pliku sekretów powoduje, że konta dwuskładnikowe przestają działać, zaszyfrowane zmienne zamieniają się w śmieci, a ty spędzasz długi wieczór, próbując zrozumieć dlaczego.

Dodaj to do tego samego Cron Job:

sudo cp /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab.rb /var/opt/gitlab/backups/

Kopia zapasowa może być przywrócona tylko na tę samą wersję i edycję (CE-do-CE, nie CE-do-EE) GitLab, na której została utworzona.

Uaktualniaj ostrożnie: nie przywracaj starej kopii zapasowej na świeżo zainstalowanym GitLabie bez wcześniejszej zmiany planu instalacji.

Przetestuj proces przywracania przynajmniej raz. Kopia zapasowa, której nigdy nie testowałeś, to tylko plik.

Czy Samodzielne Hostowanie GitLab Jest Naprawdę Warte Tego Dla Twojego Zespołu?

Samodzielne hostowanie GitLab to decyzja kontrolna dla większości zespołów. Rachunek kosztów czasami się zgadza, ale powód, dla którego ludzie pozostają przy samodzielnym hostowaniu, rzadko wynika z kosztorysu.

Oto rzeczywisty miesięczny koszt czasowy dla instalacji małego zespołu:

• ~30 minut aktualizacji – apt upgrades, GitLab minor releases
• ~15 minut weryfikacji kopii zapasowej – nie ufaj kopii, której nie przywróciłeś
• ~15 minut sprawdzania pojemności – użycie dysku, dostępna pamięć RAM
• ~2x jeśli CI/CD działa na serwerze – Intensywne użycie może podwoić obciążenie

To mniej więcej godzina miesięcznie w wolniejszym tygodniu lub dwie w bardziej zajętym.

Za około 150 dolarów za godzinę, 12 godzin pracy operacyjnej kosztuje około 1800 dolarów — mniej więcej pięć miejsc GitLab.com Premium.

Studium przypadku wykonane przez Mad Devs opisuje, jak ich zespół oszczędza ponad 10 000 dolarów rocznie, korzystając z samodzielnie hostowanego GitLab CE zamiast płacić za licencje Premium. Oszczędności stają się zauważalne, gdy zespół jest na tyle duży, że licencje na stanowiska dominują w budżecie.

Niemniej jednak, samo-hostowanie jest złym wyborem dla:

• Dwuosobowe I Trzyosobowe Zespoły Bez Wymogów Zgodności. GitLab.com Free Cię obejmuje. Czas operacyjny jest dłuższy niż oszczędność kosztów.
• Zespoły, W Których Nikt Nie Czuje Się Pewnie Przy Linii Poleceń. „Pewnie” nie oznacza umiejętności sysadmina. To znaczy, że możesz czytać błędy `/var/log/gitlab` bez paniki.
• Zespoły, Dla Których Największą Przeszkodą Jest Zatrudnianie, A Nie Narzędzia. Samo-hosting odciąga uwagę od produktu. Jeśli prędkość rozwoju produktu jest ograniczeniem, hosting jest właściwym wyborem.

Kiedy zatem ma sens samodzielny hosting? Poniżej kilka scenariuszy:

• Regulowane branże z wyraźnymi wymaganiami dotyczącymi rezydencji danych lub łańcucha dowodzenia
• Zespoły z UE/Wielkiej Brytanii z obawami o suwerenność w przypadku kodu hostowanego w USA
• Zespoły liczące 30+ osób, gdzie licencje na stanowiska dominują w budżecie
• Umowy z klientami, które zabraniają korzystania z zewnętrznych SaaS dla kodu źródłowego

Jeśli twoim powodem jest „GitHub pobiera opłaty za każde stanowisko,” prawdopodobnie wyjdziesz na plus. Jeśli twoim powodem jest „Chcę czuć kontrolę,” możesz odkryć, że rzeczywista eksploatacja jest mniej romantyczna, niż się spodziewałeś.

Czy Powinieneś Uruchamiać Runnery GitLab CI/CD Na Tym Samym VPS?

Do oceny, tak. Do produkcji, nie.

Uruchamianie CI na tej samej maszynie zabiera pamięć i CPU interfejsowi użytkownika GitLab. Klasycznym objawem jest „GitLab działa wolno o 9 rano”, co zazwyczaj sprowadza się do rozpoczęcia budowy pierwszej rury porannej i zagłodzenia frontendu internetowego. Czystszym rozwiązaniem jest oddzielny mały VPS (lub instancja DreamCompute) dla uruchamiającego, zarejestrowany w instancji GitLab przez sieć.

Jeśli musisz utrzymać biegaczy na tym samym urządzeniu, zwiększ VPS do 16 GB.

Zgodnie z wymaganiami systemowymi biegacza GitLab, proces biegacza sam w sobie jest lekki. Obciążenia, które wykonuje, nie są lekkie i dzielą procesor oraz dysk komputera z wszystkim innym, co robi GitLab.

Gotowy Do Zmiany?

Powrót do piątkowej popołudniowej rozmowy zespołowej.

Jeśli GitHub zmieni kolor na żółty i twój zespół znowu się z tego zaśmieje i pójdzie po kawę, to w porządku.

A co jeśli problemy z GitHubem zaczną wydawać się czymś poważnym?

Może zagraża umowie z klientem? Pojawia się podczas audytu zgodności? A może rachunek za licencje przekroczył granicę?

Samodzielne hostowanie GitLab CE zaczyna być całkiem rozsądną opcją. Wystarczy VPS, domena, instalacja Omnibus i godzina na zabezpieczenia.

Zanim strona statusu GitHuba znowu się zaświeci, twój kod będzie nadal sprawnie działał.

Najczęściej Zadawane Pytania o Samodzielnym Hostingu GitLab

Czy chcesz dowiedzieć się czegoś więcej na temat samodzielnego hostowania GitLab na VPS? Poniżej znajdziesz odpowiedzi na niektóre często zadawane pytania.

Czy GitLab CE jest darmowy do samodzielnego hostingu?

Tak, GitLab CE jest darmowy do samodzielnego hostowania na licencji open-source typu MIT. Nie ma limitu użytkowników ani ceny za poszczególne miejsca. Jedynymi kosztami są sam VPS oraz czas operacyjny potrzebny do jego utrzymania.

VPS Stack 4 firmy DreamHost to rozsądny punkt wyjścia do oceny. Zespoły produkcyjne zazwyczaj pracują na Stack 8 lub Stack 16.

Ile RAMu faktycznie potrzebuje GitLab CE?

Zaplanuj 16 GB RAM dla maksymalnie 1000 użytkowników, co jest podstawowym założeniem publikowanym przez GitLab (około 20 żądań na sekundę). Mniejsze zespoły mogą działać na mniejszej ilości, nawet do dokumentowanego minimum 2 GB plus 1 GB swap na potrzeby ewaluacji. Tak czy inaczej, jeśli uruchamiasz na tym samym serwerze łańcuchy CI/CD, zaplanuj 16 GB.

Czy mogę samodzielnie hostować GitLab na VPS z 4 GB RAM?

Tak, możesz uruchomić GitLab CE na 4 GB, ale będzie działał ociężale pod jakimkolwiek realnym obciążeniem. GitLab dokumentuje rezerwę 2 GB + 1 GB swap dla środowisk z ograniczoną pamięcią — ta ścieżka jest do ewaluacji, a nie produkcji. Dla zespołu aktywnie wdrażającego kod i uruchamiającego potoki, praktyczne minimum to 8 GB.

Jak długo trwa instalacja GitLab CE na VPS?

Zainstalowanie pakietu zajmuje około 10 do 15 minut, plus mniej więcej godzina na przygotowanie i zabezpieczenie, więc razem około 90 minut od początku do końca. Sam proces instalacji polega głównie na oczekiwaniu na krok rekonfiguracji.

Etapy zabezpieczania, które wymagają wyłączenia otwartej rejestracji, wprowadzenia dwuskładnikowego uwierzytelniania i zablokowania tworzenia projektów, zajmują pozostałą godzinę i są obowiązkowe dla każdej produkcyjnej instancji.

Czy warto hostować GitLab we własnym zakresie dla pięcioosobowego zespołu?

Prawdopodobnie nie, chyba że masz powód związany z prywatnością lub przestrzeganiem przepisów. GitLab.com Free obejmuje do pięciu użytkowników z nieograniczoną liczbą prywatnych projektów i 400 minutami CI/CD miesięcznie. Czas operacyjny samodzielnego hostingu przewyższa oszczędności na kosztach dla poszczególnych miejsc przy tej wielkości zespołu.

Samodzielny hosting zaczyna się opłacać, w czysto kosztowych terminach, przy około 30+ aktywnych użytkownikach.

Jaka jest różnica między GitLab CE a GitLab Community Edition?

GitLab CE i GitLab Community Edition to ten sam produkt. CE to standardowy skrót. Terminologia „Self-Managed” odnosi się do miejsca, w którym go uruchamiasz (twoja infrastruktura), a nie do konkretnej edycji.

GitLab Community Edition jest otwartoźródłowy. GitLab Enterprise Edition (EE) dodaje płatne funkcje do tej samej bazy kodów.

Czym różni się GitLab CE od GitLab EE?

GitLab CE to darmowa, otwartoźródłowa edycja. GitLab EE korzysta z tej samej bazy kodów, plus płatnych funkcji, które aktywują się po przesłaniu pliku licencyjnego.

Praktyczna różnica sprowadza się do następującego:

• CE jest licencjonowane na licencji MIT i w pełni funkcjonalne. Kontrola źródeł, scalanie żądań, zgłoszenia, podstawowe CI/CD, rejestr kontenerów, całość.
• EE dodaje funkcje przedsiębiorcze za pomocą licencji. Myśl o epickich projektach, zaawansowanych ramach zgodności, analityce wartości strumienia, wielokrotnych zasadach zatwierdzania i zaawansowanym skanowaniu bezpieczeństwa. Zgodnie z porównaniem funkcji zarządzanych przez GitLab, różnica ma znaczenie głównie dla organizacji z formalnymi procesami zarządzania zmianą.
• Możesz zainstalować EE bez licencji, i działa jako CE do momentu licencjonowania. Tak większość zespołów zabezpiecza się przed przyszłą potrzebą aktualizacji.
• Nie można czysto zdegradować EE do CE. Planuj odpowiednio.

Dla większości zespołów hostujących się samodzielnie, CE jest wystarczające. Jeśli powodem jest prywatność lub koszty, funkcje EE rzadko zmieniają kalkulację.

Jak utrzymać aktualność mojej samodzielnie hostowanej instancji GitLab?

Uruchom `sudo apt update && sudo apt upgrade gitlab-ce` aby zastosować aktualizacje bezpieczeństwa. Miesięczny rytm jest praktycznym minimum dla instancji produkcyjnej. Zawsze twórz kopię zapasową przed aktualizacją.

Aktualizacje głównych wersji muszą być przeprowadzane sekwencyjnie — nie można pominąć głównych wersji. Przejście z wersji 16.x do 18.x wymaga najpierw aktualizacji do 17.x, a następnie do 18.x. Pominięcie głównej wersji spowoduje problemy z migracjami bazy danych. Zawsze sprawdzaj narzędzie do ścieżki aktualizacji GitLab przed aktualizacją i utwórz kopię zapasową bezpośrednio przed każdym krokiem.

Jak DreamHost wpisuje się w samodzielnie hostowany GitLab?

Hosting VPS DreamHost dostarcza serwer Linux z dostępem Root, na który można zainstalować GitLab CE. Plan Stack 16 (16 GB RAM) spełnia oficjalne wymagania GitLab dla maksymalnie 1000 użytkowników, z zapasem mocy dla aktywnych łańcuchów CI/CD.