Wybór między GitHub Enterprise Server a GitHub Enterprise Cloud to jedna z tych decyzji architektonicznych, które mają wieloletnie konsekwencje dla organizacji. Nie chodzi tylko o koszt — stawką jest sposób, w jaki zespoły współpracują, jak szybko dostarczają kod na produkcję i jak spełniają wymogi regulacyjne. W tym artykule przeprowadzam szczegółowe porównanie obu wariantów według stanu na maj 2026 roku, uwzględniając najnowsze zmiany w obu platformach.
Architektura i miejsce przetwarzania danych
GitHub Enterprise Cloud działa w modelu SaaS na infrastrukturze Microsoft Azure. Całe przetwarzanie — kompilacja Actions, hostowanie repozytoriów, zarządzanie użytkownikami — odbywa się po stronie GitHub, a klient otrzymuje dostęp przez przeglądarkę lub API. Enterprise Server natomiast to samodzielnie zarządzana instancja wdrażana na własnym sprzęcie (bare metal) lub w chmurze prywatnej, działająca jako wirtualne urządzenie (appliance) oparte na systemie Linux.
Kluczową różnicą architektoniczną pozostaje suwerenność danych. W Cloud kod spoczywa na serwerach zarządzanych przez GitHub (obecnie Microsoft), natomiast w Server całość pozostaje w granicach infrastruktury organizacji. Dla wielu branż regulowanych to właśnie ten aspekt przesądza o wyborze, zanim jeszcze analiza przejdzie do funkcji czy kosztów.
Porównanie funkcji i aktualność platformy
Historycznie GitHub dostarczał nowe funkcje najpierw do Cloud, a do Server trafiały one z opóźnieniem, zazwyczaj w ramach kwartalnych wydań zbiorczych. W 2025 i 2026 roku różnica ta znacząco się zmniejszyła. GitHub wprowadził mechanizm GitHub Connect, który umożliwia instancjom Server korzystanie z wybranych funkcji Cloud bez pełnej migracji — mowa tu między innymi o Dependabot, skanowaniu kodu (code scanning) czy GitHub Actions shared runners.
W maju 2026 roku GitHub Enterprise Server w wersji 3.17 oferuje praktycznie pełny zestaw funkcji znanych z Cloud, w tym:
- GitHub Actions z obsługą runnerów samoobsługowych i współdzielonych,
- Advanced Security: CodeQL, secret scanning, push protection,
- GitHub Copilot Enterprise z możliwością indeksowania wiedzy organizacyjnej,
- wsparcie dla fine-grained personal access tokens,
- Custom models dla Copilot (w tym modele Anthropic Claude i Google Gemini),
- organizacje na poziomie enterprise (EMU) z synchronizacją SCIM.
Różnice pozostają w dwóch obszarach. Po pierwsze, nowości eksperymentalne — funkcje w publicznej becie trafiają wyłącznie do Cloud, gdzie GitHub może szybciej zbierać dane telemetryczne i iterować. Server otrzymuje je dopiero po stabilizacji w wydaniu oznaczonym jako GA. Po drugie, integracje natywne, takie jak GitHub Models (marketplace modeli AI dostępny bezpośrednio z interfejsu) oraz Azure-native powiązania (np. Microsoft Entra ID bez dodatkowej konfiguracji), pozostają ekskluzywne dla Cloud.
Bezpieczeństwo, zgodność i modele odpowiedzialności
W GitHub Enterprise Cloud model odpowiedzialności jest współdzielony. GitHub odpowiada za bezpieczeństwo fizyczne centrów danych, hardening systemu operacyjnego, łatanie hypervisorów i warstwę sieciową. Klient odpowiada za konfigurację uprawnień, polityki dostępu, rotację kluczy i zarządzanie sekretami w repozytoriach. GitHub utrzymuje certyfikaty SOC 1, SOC 2, ISO 27001, FedRAMP Moderate oraz zgodność z GDPR.
W GitHub Enterprise Server odpowiedzialność za cały stos — od fizycznego bezpieczeństwa serwerowni po konfigurację TLS i polityki backupu — spoczywa na organizacji. Daje to pełną kontrolę, ale wymaga dedykowanego zespołu DevOps znającego się na administracji appliance'ami Linux, wysokiej dostępności (HA) z replikacją MySQL i Redis oraz procedurach disaster recovery. Server wspiera tryby air-gapped wdrożeń (całkowicie odcięte od internetu), co jest wymogiem w sektorach obronnym, energetycznym i niektórych instytucjach finansowych.
W obszarze szyfrowania: Cloud domyślnie szyfruje dane w spoczynku (AES-256) i w tranzycie (TLS 1.3). Server wymaga ręcznej konfiguracji — administrator musi dostarczyć własne certyfikaty, skonfigurować polityki TLS i opcjonalnie zintegrować z firmowym HSM (hardware security module) do zarządzania kluczami.
W 2026 roku GitHub rozszerzył Enterprise Cloud o funkcję customer-managed encryption keys (CMEK) dostępną w planie Enterprise, co zbliża Cloud do wymogów organizacji, które wcześniej wybierały wyłącznie Server ze względu na kontrolę kluczy szyfrujących.
Wydajność, skalowalność i wysokie dostępność
Enterprise Cloud automatycznie skaluje zasoby — organizacja nie martwi się o limit jednoczesnych użytkowników, pojemność storage dla repozytoriów Git LFS ani o przepustowość runnerów Actions (przy użyciu GitHub-hosted runners). Dla większości zespołów to eliminuje całą klasę problemów operacyjnych.
Enterprise Server ma określone limity sprzętowe. Pojedyncza instancja (single appliance) obsługuje do około 100 tysięcy użytkowników w konfiguracji referencyjnej, ale rzeczywista wydajność zależy od dostarczonego sprzętu: liczby vCPU, RAM (zalecane minimum 64 GB dla średniej instancji) oraz wydajności podsystemu dyskowego (NVMe SSD to obecnie standard de facto dla replikacji MySQL). HA wymaga konfiguracji klastra z dwoma węzłami aplikacyjnymi, repliką bazy danych MySQL oraz repliką Redis — łącznie minimum cztery maszyny wirtualne lub fizyczne.
Backup i disaster recovery w Server to obowiązek administratora. GitHub dokumentuje procedury oparte na ghe-backup, które wymagają dedykowanego hosta backupowego z wystarczającą przestrzenią dyskową. W Cloud kopie zapasowe są zarządzane przez GitHub z RPO (Recovery Point Objective) na poziomie kilku minut i RTO (Recovery Time Objective) mierzonym w minutach dla całej platformy.
Wydajność Actions różni się fundamentalnie. Cloud oferuje GitHub-hosted runners z automatycznym skalowaniem — od standardowych maszyn 2 vCPU po GPU-enabled runners dla obciążeń AI/ML (wprowadzone w 2025 roku). Server wymaga własnych runnerów (self-hosted), co daje pełną kontrolę nad środowiskiem — dostęp do wewnętrznych rejestrów artefaktów, prywatnych sieci, specyficznych wersji SDK — ale wymaga utrzymania floty maszyn i zarządzania ich skalowaniem.
Całkowity koszt posiadania (TCO)
Koszty licencyjne w obu modelach opierają się na cenie za użytkownika miesięcznie i są zbliżone w sugerowanych cenach detalicznych, ale TCO różni się dramatycznie ze względu na koszty ukryte.
GitHub Enterprise Cloud:
- Opłata per user/month (około 21-25 USD za użytkownika w zależności od planu i negocjacji),
- Dodatkowe opłaty za GitHub Actions ponad darmowy limit minut (2000 minut/miesiąc w planie Enterprise),
- Opcjonalnie: GitHub Advanced Security (ok. 49 USD za committera),
- Copilot Enterprise jako osobna licencja (ok. 39 USD za użytkownika).
GitHub Enterprise Server:
- Opłata per user/month (porównywalna z Cloud, zazwyczaj 10-15% niższa przy umowach wieloletnich),
- Koszt infrastruktury: serwery fizyczne lub instancje cloud (minimum 4 maszyny dla HA),
- Koszt administracji: DevOps engineer dedykowany utrzymaniu appliance (szacunkowo 0.5-1 FTE dla średniej organizacji),
- Backup storage, licencje na system operacyjny hosta, monitoring,
- Runner fleet: własne maszyny dla Actions,
- Energia elektryczna, chłodzenie (przy on-premise).
Organizacje często nie doceniają kosztu administracji Server. Utrzymanie appliance w trybie HA z regularnymi aktualizacjami (kwartalne wydania główne plus łaty bezpieczeństwa), testowaniem upgrade'ów na środowisku staging, monitorowaniem wykorzystania zasobów i zarządzaniem backupami to znaczące obciążenie operacyjne, które w modelu Cloud po prostu nie istnieje.
Z drugiej strony, przy bardzo dużej liczbie użytkowników (powyżej 5000) i intensywnym wykorzystaniu GitHub Actions, Server może być tańszy w perspektywie 3-5 letniej, ponieważ eliminuje opłaty za minuty Actions i daje większe pole do negocjacji cenowych przy odnowieniu umowy.
Migracja między modelami
GitHub dostarcza narzędzia wspierające migrację w obie strony, ale ścieżka Server → Cloud jest zdecydowanie bardziej przetarta i udokumentowana. GitHub Enterprise Importer umożliwia przenoszenie repozytoriów, historii, pull requestów, issues, wiki, a od wersji z początku 2026 roku także secret scanning alerts i konfiguracji Dependabot. Migracja Cloud → Server jest możliwa, ale wymaga ręcznego eksportu i może wiązać się z utratą niektórych metadanych (szczególnie tych związanych z funkcjami Cloud-only, jak GitHub Models czy niektóre integracje Actions).
W praktyce większość organizacji migruje z Server do Cloud, a nie odwrotnie. GitHub aktywnie zachęca do tego kierunku, oferując programy incentywizacyjne i dedykowane wsparcie inżynieryjne dla dużych migracji. Trend rynkowy w 2026 roku jest jednoznaczny: nowe wdrożenia Enterprise są w przeważającej większości Cloud-native, a instancje Server utrzymują organizacje z twardymi wymogami regulacyjnymi lub istniejącą infrastrukturą on-premise.
Kiedy wybrać GitHub Enterprise Server
Server pozostaje właściwym wyborem w następujących scenariuszach:
- Wymogi suwerenności danych: przepisy krajowe lub branżowe wymagają, aby kod źródłowy nie opuszczał granic kraju lub infrastruktury organizacji.
- Air-gapped środowiska: organizacje pracujące w sieciach całkowicie odizolowanych od internetu (np. wojsko, energetyka jądrowa, krytyczna infrastruktura państwowa).
- Istniejąca infrastruktura: duże przedsiębiorstwa, które już posiadają własne data center, zespół DevOps i procedury compliance dla on-premise.
- Pełna kontrola nad wydajnością Actions: zespoły potrzebujące dedykowanego, przewidywalnego środowiska CI/CD bez limitów minut i zmiennej wydajności współdzielonych runnerów.
- Custom integracje na poziomie systemowym: potrzeba głębokiej integracji z wewnętrznymi systemami przez bezpośredni dostęp do bazy danych appliance.
Kiedy wybrać GitHub Enterprise Cloud
Cloud jest rekomendowany w większości pozostałych przypadków:
- Brak zespołu DevOps dedykowanego do utrzymania platformy: organizacje, które chcą skupić się na pisaniu kodu, a nie na administrowaniu serwerami.
- Potrzeba natychmiastowego dostępu do najnowszych funkcji: GitHub Copilot, modele AI, integracje z ekosystemem Azure — to wszystko najpierw trafia do Cloud.
- Dynamiczne skalowanie: zespoły o zmiennym obciążeniu CI/CD, które nie chcą utrzymywać nadmiarowej floty runnerów.
- Rozproszone geograficznie zespoły: Cloud zapewnia niskolatencyjny dostęp z dowolnego miejsca na świecie bez konieczności budowania własnej sieci CDN czy punktów obecności.
- Startupy i scale-upy: organizacje rosnące od kilku do kilkuset programistów, dla których przewidywalność kosztów i zerowy nakład administracyjny są kluczowe.
- Chęć skorzystania z oferty kluczesoft.pl: jako autoryzowany partner GitHub, oferujemy licencje GitHub Enterprise Cloud z pełnym wsparciem wdrożeniowym i szkoleniowym, pomagając zespołom przejść na platformę bez przestojów i z pełnym wykorzystaniem dostępnych funkcji.
Częste pytania
Czy GitHub Enterprise Server działa bez połączenia z internetem?
Tak, GitHub Enterprise Server wspiera tryb air-gapped (całkowicie odcięty od internetu). W tym trybie funkcje zależne od łączności z github.com (takie jak GitHub-hosted runners czy Dependabot) są niedostępne, ale core platformy — repozytoria, pull requesty, Actions z self-hosted runnerami, Packages — działa w pełni. Copilot w trybie air-gapped wymaga dodatkowej konfiguracji z lokalnym endpointem.
Czy mogę korzystać z GitHub Copilot na Enterprise Server?
Tak, GitHub Copilot Enterprise jest dostępny dla GitHub Enterprise Server od wersji 3.14 (wydanej w 2024 roku) i był systematycznie rozszerzany. W maju 2026 roku Server wspiera Copilot Chat, Copilot Coding, knowledge bases indeksujące dokumentację organizacji oraz Custom Models umożliwiające wybór modelu AI (Anthropic Claude, Google Gemini, modele Microsoft). W trybie air-gapped wymagane jest wdrożenie lokalnego endpointu inferencyjnego.
Jak często GitHub Enterprise Server otrzymuje aktualizacje?
GitHub wydaje nową wersję główną Enterprise Server co kwartał, wraz z łatkami bezpieczeństwa i poprakami krytycznymi między wydaniami. Każda wersja jest wspierana przez minimum 12 miesięcy od daty wydania, co daje administratorom czas na zaplanowanie i przetestowanie upgrade'u. Proces aktualizacji jest zautomatyzowany przez mechanizm ghe-upgrade, ale GitHub zaleca testowanie na instancji staging przed wdrożeniem produkcyjnym.
Czy GitHub Actions w Cloud ma limity?
Tak. Plan Enterprise Cloud zawiera 50 000 minut GitHub Actions miesięcznie w puli współdzielonej dla organizacji. Ponad ten limit naliczane są opłaty za minutę, których stawka zależy od typu runnera (Linux, Windows, macOS, GPU). Alternatywnie można używać self-hosted runners — są one nielimitowane i darmowe pod względem minut Actions, ale organizacja ponosi koszt ich utrzymania.
Czy mogę migrować z Server do Cloud bez utraty danych?
Tak, GitHub Enterprise Importer umożliwia migrację repozytoriów, pull requestów, issues, wiki, ustawień ochrony branchy, webhooków, a od 2026 roku także alertów secret scanning i konfiguracji Dependabot. Historia commitów i metadane (autor, data) są zachowywane. Migracja wymaga czasowego wyłączenia dostępu do migrowanych repozytoriów (okno maintenance), ale przy dobrym zaplanowaniu przestój może być ograniczony do minut.
Który model jest bezpieczniejszy?
Oba modele są bezpieczne, ale na różne sposoby. Cloud korzysta z infrastruktury Microsoft Azure z certyfikacjami SOC, ISO, FedRAMP i zespołami security engineering pracującymi 24/7. Server daje pełną kontrolę nad każdym aspektem bezpieczeństwa — od fizycznego dostępu do serwera po algorytmy szyfrowania — ale wymaga, aby organizacja samodzielnie wdrożyła i utrzymała te zabezpieczenia. Dla organizacji bez dojrzałego zespołu security, Cloud jest zazwyczaj bezpieczniejszy w praktyce.
Czy GitHub Enterprise Cloud obsługuje własne klucze szyfrowania?
Tak, od 2026 roku GitHub Enterprise Cloud wspiera customer-managed encryption keys (CMEK). Organizacje mogą używać własnych kluczy zarządzanych przez Azure Key Vault do szyfrowania danych w spoczynku. To rozwiązanie adresuje potrzeby organizacji, które wcześniej wybierały Server wyłącznie ze względu na wymóg kontroli kluczy szyfrujących.
Jaka jest różnica w dostępności między Cloud a Server?
GitHub Enterprise Cloud ma gwarantowaną dostępność 99,9% SLA i historycznie utrzymuje się powyżej 99,95%. Enterprise Server nie ma zewnętrznego SLA — dostępność zależy wyłącznie od infrastruktury i procedur wdrożonych przez organizację. Poprawnie skonfigurowany klaster HA z monitorowaniem i automatyzacją failover może osiągać porównywalne wskaźniki, ale wymaga to znaczących inwestycji w infrastrukturę i kompetencje.
Czy mogę używać GitHub Enterprise Server w chmurze publicznej?
Tak, GitHub Enterprise Server może być wdrożony na maszynach wirtualnych w AWS, Azure lub Google Cloud. Wspierane są obrazy maszyn dla głównych dostawców chmury. Wdrożenie w chmurze publicznej daje pewne korzyści Cloud (elastyczność infrastruktury) przy zachowaniu kontroli nad instancją Server, ale nie eliminuje obowiązków administracyjnych — nadal musisz zarządzać upgrade'ami, backupami i HA.
Ile kosztuje przejście z Server na Cloud?
Koszt przejścia to głównie koszt pracy inżynierów planujących i wykonujących migrację oraz potencjalny koszt przestoju w oknie maintenance. Same narzędzia migracyjne (GitHub Enterprise Importer) są bezpłatne dla klientów Enterprise. GitHub oferuje również programy incentywizacyjne dla organizacji migrujących z Server do Cloud, obejmujące zniżki na pierwszy rok subskrypcji i bezpłatne godziny konsultacji z inżynierami GitHub.