On premise — co to znaczy i kiedy własny serwer w firmie wygrywa z chmurą

On premise to model, w którym firma sama kupuje serwery, stawia je we własnej siedzibie i sama je utrzymuje — zamiast wynajmować moc obliczeniową i oprogramowanie w chmurze. Przez dekadę słyszeliśmy, że to model schodzący ze sceny. Tymczasem w 2026 roku wiele firm staje przed tym pytaniem od nowa: jedne dlatego, że kończy się wsparcie ich serwera, inne dlatego, że rachunek za chmurę urósł bardziej, niż zakładały.

Ten tekst nie jest obroną żadnej ze stron. To pomoc w decyzji: ile naprawdę kosztuje serwer w firmie, kiedy on-premise wygrywa, kiedy przegrywa i czy istnieje coś pomiędzy. Każda liczba ma źródło, a tam, gdzie liczby zależą od twojej firmy, zamiast wymyślonych kwot pokazujemy, jak je policzyć. Czym są modele IaaS, PaaS i SaaS, wyjaśniamy osobno w tekście o chmurze obliczeniowej — tu zakładamy, że te pojęcia są już znane.

On premise — co to znaczy

Angielskie on premises (w potocznym użyciu często skracane do on premise) znaczy dosłownie „na miejscu”, w lokalu firmy. W IT oznacza infrastrukturę, którą organizacja posiada i obsługuje sama: serwer stoi w jej budynku, jest jej własnością, a za jego działanie odpowiadają jej ludzie albo firma serwisowa, którą sama wynajęła.

Ciekawe, że najważniejsze definicje branżowe nie definiują tego pojęcia wprost. Amerykański NIST w definicji chmury (SP 800-145) i norma ISO/IEC 17788 używają zwrotu „on or off premises” tylko wewnątrz innej definicji — chmury prywatnej, która według NIST „may exist on or off premises”, czyli może znajdować się w siedzibie organizacji albo poza nią (tłumaczenie własne; NIST SP 800-145).

Najbardziej użyteczny opis daje IBM, zestawiając on-premise z chmurą: „traditional on-premises IT, where a company owns and maintains physical data centers and servers to access computing power, data storage and other resources” — tradycyjne IT on-premises, w którym firma posiada i utrzymuje fizyczne centra danych i serwery, żeby mieć dostęp do mocy obliczeniowej, pamięci masowej i innych zasobów (tłumaczenie własne; IBM, What is cloud computing?). Kluczowe są tu dwa czasowniki: posiada i utrzymuje.

Z tej definicji wynika też najważniejsza różnica w stosunku do chmury: w on-premise wszystkie warstwy — od prądu i klimatyzacji, przez sprzęt i system operacyjny, po aplikację i dane — są po twojej stronie. W chmurze część z nich przejmuje dostawca. Ile dokładnie, zależy od modelu, co rozpisuje schemat w tekście o chmurze obliczeniowej.

Pełny koszt własnego serwera

Porównania „on premise vs cloud” najczęściej psuje jedno: po stronie serwera ktoś wpisuje cenę sprzętu, a po stronie chmury — pełny rachunek miesięczny. Tymczasem cena zakupu to tylko pierwsza z kilku pozycji. Oto te, które trzeba policzyć.

Amortyzacja: jak serwer rozkłada się w kosztach

Serwer to środek trwały, więc — poza wyjątkiem opisanym niżej — trafia do kosztów przez odpisy amortyzacyjne, a nie jednorazowo. Załącznik nr 1 do ustawy o podatku dochodowym od osób prawnych, „Wykaz rocznych stawek amortyzacyjnych”, przewiduje dla grupy KŚT 487 „Zespoły komputerowe” stawkę 30% rocznie (poz. 04 załącznika; ustawa o CIT, t.j. Dz.U. 2026 poz. 554). Uwaga dla osób, które sprawdzają to w klasyfikacji KŚT z 2016 roku: załącznik posługuje się własnym numerem 487, a nie 491.

Stawka 30% oznacza, że przy amortyzacji liniowej wartość serwera trafia do kosztów w ciągu nieco ponad trzech lat. To ważne dla porównania z chmurą: rachunek za chmurę jest kosztem od razu, serwer — rozłożonym w czasie.

Dla tańszego sprzętu ustawa daje prostszą drogę. Według art. 16d ust. 1 podatnicy „mogą nie dokonywać odpisów amortyzacyjnych od składników majątku (…) których wartość początkowa (…) nie przekracza 10 000 zł” — taki wydatek można ująć w kosztach jednorazowo. Przepisy o PIT zawierają analogiczny załącznik, ale jego brzmienia nie sprawdzaliśmy — jeśli prowadzisz działalność opodatkowaną PIT, potwierdź stawkę z księgowym.

Licencja on premise: Windows Server i SQL Server

Drugą pozycją, często większą niż sam sprzęt, są licencje. Na przykładzie oprogramowania Microsoft, najczęściej spotykanego w polskich serwerowniach, widać, jak działa licencja on premise i dlaczego trudno ją policzyć „na oko”.

Windows Server 2025 jest licencjonowany na rdzenie procesora, z progami minimalnymi. Według zasad licencjonowania Microsoft trzeba kupić „a minimum of 8 core licenses per physical processor and a minimum of 16 core licenses per server” — co najmniej 8 licencji rdzeniowych na każdy fizyczny procesor i co najmniej 16 na serwer (tłumaczenie własne; Microsoft Licensing, Windows Server 2025). Do tego dochodzą licencje dostępowe: „Each user or device that accesses licensed servers requires a Windows Server CAL” — każdy użytkownik albo urządzenie korzystające z serwera wymaga licencji CAL (tłumaczenie własne).

Ceny katalogowe Microsoft podaje w dolarach: 1 176 USD za edycję Standard i 6 771 USD za edycję Datacenter, w obu przypadkach za pakiet 16 rdzeni, z zastrzeżeniem, że ceny mogą się różnić w zależności od kraju (Microsoft, cennik Windows Server). Różnica między edycjami dotyczy wirtualizacji: Standard daje prawo do dwóch środowisk systemowych (fizycznych lub wirtualnych), Datacenter — do dowolnej ich liczby. Jeśli planujesz na jednym serwerze kilka maszyn wirtualnych, to rozróżnienie przesądza o koszcie. Jest też rozliczenie „płać za użycie”: 33,58 USD za rdzeń miesięcznie.

SQL Server 2022, jeśli twoja aplikacja z niego korzysta, ma własne zasady: licencja na rdzenie wymaga „a minimum of four Licenses per Physical Processor” — co najmniej czterech licencji na fizyczny procesor (Microsoft Licensing, SQL Server), a tańszy model „serwer + CAL” jest dostępny tylko dla edycji Standard. Ceny katalogowe: 3 945 USD za pakiet 2 rdzeni w edycji Standard, 15 123 USD za pakiet 2 rdzeni w Enterprise, a w modelu serwer + CAL — 989 USD za serwer i 230 USD za każdą licencję CAL (Microsoft, cennik SQL Server 2022).

Nie sumujemy tych kwot w „typowy serwer”, bo wynik zależy od liczby rdzeni, użytkowników i maszyn wirtualnych. Zasada do zapamiętania: przy licencji na rdzenie mocniejszy procesor kupiony „na zapas” podnosi też koszt oprogramowania.

Serwis: co kupujesz w umowie serwisowej

Serwer się psuje, a pytanie brzmi: jak szybko ktoś go naprawi. Producenci sprzedają to jako osobną usługę. Dell w opisie usługi ProSupport for Infrastructure (wersja 17, lipiec 2026) rozróżnia dwa główne warianty. W wariancie 4-godzinnym „a technician typically arrives on-site within 4 hours after completion of troubleshooting and isolating the issue” — technik zwykle przyjeżdża w ciągu 4 godzin od zakończenia diagnozy i wyizolowania problemu (tłumaczenie własne). W wariancie następnego dnia roboczego technik jest wysyłany tak, by zwykle dotarł następnego dnia roboczego (Dell ProSupport for Infrastructure, opis usługi).

W tych zapisach są trzy rzeczy, które warto przeczytać uważnie. Po pierwsze, zegar 4 godzin rusza po diagnozie, nie po zgłoszeniu. Po drugie, słowo „zwykle” (typically) nie jest gwarancją. Po trzecie, w Europie serwis na miejscu jest dostępny w promieniu do 150 km od najbliższej lokalizacji logistycznej Dell, a przy częściach niestandardowych Dell domyślnie przechodzi na tryb następnego dnia roboczego. Jeśli firma stoi daleko od dużego miasta, warto to sprawdzić przed zakupem.

Prąd, miejsce i ludzie

Trzy ostatnie pozycje nie mają uniwersalnej ceny, ale nie wolno ich pominąć.

• Prąd i chłodzenie. Serwer pracuje całą dobę, a pomieszczenie, w którym stoi, zwykle wymaga klimatyzacji, która też pobiera energię. Moc znamionową serwera znajdziesz w jego specyfikacji; zużycie w kilowatogodzinach razy stawka z twojej faktury za prąd daje koszt roczny.
• Miejsce i zasilanie awaryjne. Wydzielone pomieszczenie, zasilacz UPS z bateriami do wymiany co kilka lat, zabezpieczenie dostępu.
• Ludzie. Ktoś musi instalować aktualizacje, pilnować kopii zapasowych, reagować na awarie — także w weekend. Albo jest to etat (lub jego część), albo umowa z zewnętrzną firmą. W obu przypadkach to koszt stały, niezależny od tego, czy w danym miesiącu coś się zepsuło.

Chmura nie zwalnia z tej pracy całkowicie, ale w modelach PaaS i SaaS przejmuje jej dużą część.

Termin, który wymusi decyzję: Windows Server 2016

Dla wielu firm pytanie „on-premise czy chmura” nie jest teoretyczne, bo ma konkretną datę. 12 stycznia 2027 roku kończy się rozszerzone wsparcie Windows Server 2016 (Microsoft Lifecycle, Windows Server 2016). To ostatni etap cyklu życia produktu, w którym Microsoft wydaje dla niego poprawki bezpieczeństwa w ramach standardowego wsparcia. Serwer, który po tej dacie dalej pracuje na tym systemie, przestaje dostawać łatki na nowo odkryte luki w ramach tego wsparcia.

Dla porównania: Windows Server 2025 ma wsparcie podstawowe do 13 listopada 2029, a rozszerzone do 14 listopada 2034 roku (Microsoft Lifecycle, Windows Server 2025). Kto dziś kupuje licencję na nowy system, kupuje więc około ośmiu lat wsparcia.

Serwer kupiony razem z tym systemem jest przy stawce 30% zwykle w pełni zamortyzowany. Firma ma trzy drogi: zaktualizować system na obecnym sprzęcie (jeśli sprzęt i licencje na to pozwalają), kupić nowy serwer z nowym systemem albo przenieść obciążenie gdzie indziej. Czy i na jakich warunkach można dokupić dalsze aktualizacje dla starszego systemu, sprawdź u Microsoft lub dostawcy licencji — to i tak tylko przesunięcie terminu.

Kiedy on-premise wygrywa

Stałe, duże i przewidywalne obciążenie. Chmura rozlicza się według zużycia, co jest zaletą przy wahaniach i wadą przy stałym obciążeniu: płacisz marżę dostawcy za elastyczność, z której nie korzystasz. Im większa i stabilniejsza skala, tym wyraźniej widać ten koszt.

Wymagania co do miejsca przechowywania danych. Gdy umowa, przepisy branżowe albo polityka firmy wymagają, żeby dane fizycznie zostały w określonym miejscu, własny serwer daje pewność bez negocjacji z dostawcą.

Brak zależności od jednego dostawcy. Własny sprzęt nie zmieni cennika z dnia na dzień i nie wycofa usługi, na której oparłeś system.

Najczęściej cytowanym przykładem pierwszej sytuacji jest 37signals, firma stojąca za Basecampem i pocztą HEY. Oto liczby podane przez samą firmę, we wpisach współzałożyciela Davida Heinemeiera Hanssona:

• luty 2023: „We spent $3.2m on cloud in 2022” — 3,2 mln USD na chmurę w 2022 roku, z czego około 1 mln na przechowywanie plików w S3. Plan zakładał zakup sprzętu „in the region of $600,000”, amortyzowanego „over a conservative five years”, i oszczędność 7 mln USD w pięć lat bez powiększania zespołu utrzymania (DHH, 21.02.2023);
• wrzesień 2023: wydatki na chmurę bez S3 spadły z około 180 tys. do mniej niż 80 tys. USD miesięcznie, a „our ops team stayed the same” (DHH, 15.09.2023);
• październik 2024: z pierwotnych 3,2 mln USD rocznie do 1,3 mln w 2024 roku, przy sprzęcie Dell za około 700 tys. USD; prognoza oszczędności to już „well over ten million dollars over five years” — znacznie ponad 10 mln USD w pięć lat (tłumaczenie własne; DHH, 17.10.2024);
• marzec 2025: ostatnim elementem był S3, na który firma wydawała „just shy of $1.5 million/year”; zastąpić go miała macierz Pure Storage o pojemności 18 PB za około 1,5 mln USD plus niecały milion za serwis w ciągu pięciu lat (DHH, 26.03.2025). Migrację opisał w styczniu 2026 inżynier firmy Jeremy Daer: dane przeniesiono w mniej niż 10 dni i „There was no downtime” — obyło się bez przestoju (37signals, 08.01.2026).

Dwa zastrzeżenia są tu konieczne. Po pierwsze, to liczby podane przez samą firmę, która publicznie promuje wyjście z chmury — nie audyt. Nawet ilość przenoszonych danych różni się między wpisami: w 2024 roku mowa o „almost 10 petabytes”, w 2025 o „nearly 6 PB”, a w opisie migracji z 2026 o „five petabytes”. Po drugie, i ważniejsze: to firma wydająca miliony dolarów rocznie na infrastrukturę, z własnym zespołem utrzymania, który już istniał. Przy skali małej firmy oszczędność może być mniejsza niż koszt osoby, która musiałaby pilnować sprzętu. Z przypadku 37signals wynika więc metoda — policz obie strony uczciwie — a nie wniosek, że każdy powinien wyjść z chmury.

Kiedy on-premise przegrywa

Zmienne obciążenie. Serwer kupuje się na szczyt. Jeśli szczyt trwa dwa tygodnie w roku — sezon w sklepie, zamknięcie roku w księgowości — przez resztę czasu sprzęt stoi w dużej części bezczynnie, a i tak się amortyzuje, zużywa prąd i wymaga serwisu.

Brak administratora. To najczęstszy powód, dla którego serwer lokalny w małej firmie staje się ryzykiem. Serwer bez aktualizacji, z kopią zapasową, której nikt nigdy nie próbował odtworzyć, działa dobrze — do pierwszej awarii dysku albo pierwszego ataku.

Kopie i zapasowa lokalizacja. Kopia zapasowa trzymana w tym samym budynku co serwer nie chroni przed pożarem, zalaniem ani kradzieżą. Druga lokalizacja to kolejny koszt i kolejna rzecz do utrzymania; w chmurze wiele usług ma ją wbudowaną. Jak zbudować rozsądny system kopii, opisujemy w tekście o kopii zapasowej.

Głośne przypadki „powrotu z chmury” sugerują masowy trend, ale dane analityków są ostrożniejsze. Według IDC „only 8-9% of companies plan full workload repatriation” — tylko 8–9% firm planuje pełne przeniesienie obciążeń z powrotem z chmury (tłumaczenie własne; IDC, blog, D. Saroff, 28.10.2024, na podstawie ankiety Server and Storage Workloads Survey). To wynik ankiety IDC, a nie spis firm, i dotyczy planów, nie wykonanych migracji. Pokazują jednak, że pełny powrót do własnej serwerowni jest wyjątkiem — częściej firmy przenoszą z powrotem wybrane systemy, a resztę zostawiają w chmurze.

Trzecia droga: VPS i self-hosting

Rozmowa „on premise vs cloud” często pomija rozwiązanie pośrednie, które dla wielu małych i średnich firm jest najrozsądniejsze: wynajęty serwer wirtualny (VPS) u dostawcy hostingu, na którym firma sama uruchamia swoje aplikacje. Sprzęt, prąd, łącze i fizyczne bezpieczeństwo należą do dostawcy — nie trzeba kupować serwera, klimatyzacji ani umowy serwisowej. Ale system operacyjny, aktualizacje, kopie zapasowe i wszystko, co na nim działa, zostaje po twojej stronie, tak jak w on-premise.

Formalnie to IaaS, czyli jeden z modeli chmury; w praktyce odpowiedzialność przypomina własny serwer. Ta strona działa właśnie w ten sposób. Porównaliśmy rachunek dla naszego stosu (Next.js i Payload CMS, zespół trzech osób, 2 TB transferu miesięcznie, ceny z cenników dostawców odczytane 5 października 2026, bez VAT): zarządzana platforma Vercel z bazą MongoDB Atlas to około 271 USD miesięcznie, a serwer VPS Hetzner CPX32 (4 vCPU, 8 GB RAM, 160 GB NVMe) z narzędziem Coolify — 35,99 EUR miesięcznie z adresem IPv4 (cennik Hetzner Cloud; liczony wcześniej CPX31 jest dziś dostępny tylko w lokalizacjach w USA). Pełny rachunek i założenia opisaliśmy w tekście o self-hostingu Next.js i Payload.

Różnica jest duża, ale uczciwość wymaga pokazania drugiej strony. Po przejściu na własny serwer przejęliśmy kopie zapasowe, łatki bezpieczeństwa i monitoring dostępności. I mieliśmy trzy awarie produkcyjne, których na zarządzanej platformie by nie było:

1. Pamięć i utracone pliki. Przetwarzanie obrazów zużywało tyle pamięci, że system zabijał proces aplikacji. Przy okazji okazało się, że dla jednej z kolekcji plików nie skonfigurowaliśmy trwałego wolumenu — po restarcie kontenera zniknęło 11 wgranych plików.
2. Zapełniony dysk. Pamięć podręczna renderowanych stron urosła do 89 GB, bo boty odpytywały nieistniejące adresy, a każda odpowiedź zapisywała się jako plik.
3. Budowanie zagłodziło bazę. Budowanie nowej wersji aplikacji na tym samym serwerze zabierało zasoby bazie danych. Rozwiązanie: budowanie w zewnętrznym systemie CI i 4 GB pamięci wymiany.

Wszystkie trzy wynikały z tego samego: na własnym serwerze każda warstwa poza sprzętem jest twoja. W tamtym tekście podajemy też regułę, która uczciwie ustawia rachunek: jeśli utrzymanie zajmuje 2 godziny miesięcznie po 150 zł, to 300 zł kosztu pracy trzeba odjąć od różnicy w abonamencie, zanim nazwie się ją oszczędnością. Innymi słowy, VPS opłaca się wtedy, gdy ktoś w zespole i tak ma te kompetencje i dzieli je między kilka projektów, a nie poświęca jednemu. Jak zabezpieczyć się przed awariami, których nikt nie zauważy, piszemy w tekście o monitoringu strony.

Polskie firmy a chmura: z czego naprawdę korzystają

Czy polskie firmy zostają przy on-premise? Eurostat nie mierzy, ile firm ma własne serwery — mierzy, ile kupuje płatne usługi chmurowe i jakie (Eurostat, isoc_cicce_use, firmy zatrudniające co najmniej 10 osób, bez sektora finansowego, dane za 2025 rok).

Ogólnie Polska wypada nieco powyżej średniej: z płatnej chmury korzystało 54,71% polskich firm wobec 52,74% w UE. Obraz zmienia się przy infrastrukturze: hosting baz danych w chmurze kupowało 8,8% polskich firm wobec 24,0% w UE, a moc obliczeniową — 5,37% wobec 14,86%. Przechowywanie plików w chmurze: 21,12% wobec 37,73%.

Nasza interpretacja — nie Eurostatu — jest taka, że polskie firmy weszły do chmury głównie przez gotowe usługi, takie jak poczta i pakiet biurowy, a bazy danych i własne aplikacje znacznie rzadziej przenoszą do chmury. Gdzie w takim razie działają — na serwerze w firmie, na VPS-ie czy u dostawcy oprogramowania — badanie nie mówi. Pełną tabelę i zastrzeżenia metodologiczne znajdziesz w tekście o chmurze obliczeniowej.

Jak podjąć decyzję: on-premise, VPS czy chmura

Zacznij od pytań, potem policz.

Pytania, które zawężają wybór

1. Czy obciążenie jest stałe, czy zmienne? Stałe i duże przemawia za własną infrastrukturą albo VPS-em; zmienne — za chmurą rozliczaną według zużycia.
2. Czy masz kogoś, kto utrzyma serwer? Osobę albo firmę z konkretnym zakresem: aktualizacje, kopie, reakcja na awarie. Bez tego on-premise i VPS są ryzykiem, a nie oszczędnością.
3. Czy dane muszą zostać w określonym miejscu? Jeśli tak, sprawdź, czy wymaganie spełni region dostawcy chmury w UE, czy naprawdę wymaga serwera w twoim budynku. O tym, co zostaje po twojej stronie w chmurze, piszemy w tekście o bezpieczeństwie danych w chmurze.
4. Ile kosztuje godzina przestoju i kto ją naprawi? Po stronie on-premise odpowiedź daje umowa serwisowa i twój administrator, po stronie chmury — umowa SLA z dostawcą, którą warto przeczytać ze zrozumieniem, co naprawdę gwarantuje. Koszt samego przestoju pomoże oszacować kalkulator kosztu utrzymania strony.
5. Jakie oprogramowanie musi działać? Aplikacja wymagająca Windows Server i SQL Server oznacza licencje niezależnie od miejsca — w chmurze też za nie płacisz, tylko w abonamencie.
6. Jaki termin cię goni? Koniec wsparcia systemu, koniec umowy z dostawcą, koniec gwarancji sprzętu.

Rachunek 5-letni: jak go policzyć

Jeśli po tych pytaniach zostają dwie lub trzy opcje, porównaj je w horyzoncie pięciu lat — w takim okresie, „conservative five years”, amortyzowało sprzęt 37signals, i taki okres obejmuje pełną amortyzację według stawki 30%. Kwoty zależą od firmy, więc pokazujemy, które pozycje wpisać do arkusza.

Po stronie on-premise:

• zakup sprzętu (serwer, macierz, sieć, UPS) — rozłożony według stawki amortyzacyjnej albo ujęty jednorazowo, jeśli nie przekracza 10 000 zł;
• licencje systemu i baz danych — z uwzględnieniem minimów rdzeniowych i licencji CAL dla każdego użytkownika lub urządzenia;
• umowa serwisowa producenta na cały okres (nie tylko na czas gwarancji);
• prąd i chłodzenie — moc razy godziny razy stawka;
• praca administratora — godziny miesięcznie razy stawka, także jeśli to własny pracownik;
• kopie zapasowe w drugiej lokalizacji;
• wymiana sprzętu albo systemu przed końcem okresu, jeśli wypada termin końca wsparcia.

Po stronie chmury lub VPS:

• abonament lub zużycie — z realistycznym wzrostem, nie z dzisiejszym rachunkiem pomnożonym przez 60;
• transfer danych i przechowywanie — pozycje, które najczęściej rosną szybciej niż reszta;
• licencje, jeśli nie są wliczone w usługę;
• praca administracyjna, która zostaje po twojej stronie — przy VPS podobna do on-premise, przy SaaS minimalna;
• koszt ewentualnej migracji i wyjścia od dostawcy.

Dwie zasady: po obu stronach licz pracę ludzi, także pracownika, który „i tak jest na etacie”, i policz wariant pesymistyczny — większy ruch, awaria w trzecim roku. Rozwiązanie, które wygrywa tylko w wariancie optymistycznym, nie wygrywa.

Jeśli taki rachunek wymaga wiedzy o twoich systemach, której nie masz pod ręką, to typowy przypadek dla doradztwa technologicznego: zewnętrzny przegląd tego, co firma ma, ile to kosztuje i co warto przenieść, zanim wymusi to termin albo awaria.

Co dalej

Czym różnią się modele usług chmurowych i jak z chmury korzystają polskie firmy, wyjaśniamy w tekście o chmurze obliczeniowej. O samym modelu oprogramowania jako usługi piszemy w przewodniku po SaaS, a jeśli rozważasz, czy kupić gotowe oprogramowanie, czy zbudować własne — w tekście o oprogramowaniu dedykowanym.