Hosting to usługa, w której operator udostępnia środowisko dla twojej strony lub aplikacji - miejsce na pliki, oprogramowanie serwera i uzgodniony zakres obsługi. Nazwa planu w cenniku tego środowiska nie opisuje. Zanim zapłacisz, porównaj atrybuty - runtime, limity, kopie i dostęp - a nie etykiety.

Nie znajdziesz tu rankingu ani cen. Zobaczysz za to firmę, która kupiła plan po nazwie, i cztery zdarzenia, w których ta nazwa rozjechała się z potrzebami. Potem dostaniesz tabelę czterech klas środowiska i pytania, które zadasz dokumentacji zamiast sprzedawcy.

Czym hosting różni się od serwera?

Serwer to maszyna - fizyczna albo wirtualna - na której działa system i oprogramowanie. Hosting jest umową o to, co z tej maszyny dostajesz i na jakich warunkach. Kupując hosting, nie kupujesz komputera. Kupujesz wycinek jego zasobów, zestaw oprogramowania i obietnicę obsługi w opisanym zakresie.

Ta różnica wygląda na akademicką dokładnie do pierwszej awarii. Wtedy okazuje się, że granica między "twoje" i "operatora" przebiega tam, gdzie zapisała ją umowa - a nie tam, gdzie każdy z was ją sobie wyobrażał.

Firma, która kupiła plan po nazwie

Weź firmę, która wynajmuje sprzęt budowlany. To fikcyjny przykład złożony z typowych pułapek rynku, nie opis konkretnego klienta. Właściciel zamówił u znajomego prostą stronę - cennik, zdjęcia maszyn, formularz kontaktowy. Hosting wybrał sam, po nazwie planu i cenie za pierwszy rok. Strona działała, więc temat uznał za zamknięty.

Potem wydarzyły się cztery rzeczy, każda z osobna drobna.

Po roku przyszła faktura odnowieniowa. Cena katalogowa okazała się kilka razy wyższa od promocyjnej złotówki z pierwszego roku. Nikt nie zapisał daty odnowienia ani ceny po promocji, więc decyzję o przedłużeniu firma podjęła pod presją - strona miała zniknąć za trzy dni. Plan nie oszukał w niczym. Po prostu nikt nie doczytał, ile kosztuje drugi rok.

Firma urosła i zamówiła system rezerwacji maszyn online. Programista oddał aplikację napisaną w Node.js. Wykupiony plan współdzielony obsługiwał tylko PHP w wersjach wybranych przez operatora - i żadna ilość miejsca na dysku tego nie zmieniała. Aplikacja czekała, aż firma dokupi inne środowisko. Nikt wcześniej nie zapytał, co plan potrafi uruchomić.

Któregoś ranka baza danych rezerwacji wstała uszkodzona. W ofercie stało "kopie zapasowe w cenie", więc właściciel spał spokojnie. Dokumentacja planu mówiła jednak, że kopia obejmuje pliki, a odtworzenie bazy wykonuje operator na zgłoszenie, w swoim tempie. Słowo "kopia" było prawdziwe. Zakres, retencja i droga odtworzenia były trzema osobnymi pytaniami, których nikt nie zadał.

Rok później firma przenosiła stronę do innego operatora. W trakcie przeprowadzki wygasła domena - opłacona kiedyś razem z hostingiem, na jednej fakturze, ale będąca osobną umową z osobnym terminem. Strona zniknęła z sieci mimo działającego, opłaconego serwera. Klienci widzieli błąd, a firma szukała winy w nowym hostingu, który był akurat jedyną sprawną częścią układanki.

Żadne z tych zdarzeń nie wynikło ze złej woli operatora. Każde wynikło z tego samego błędu - firma kupiła etykietę, a warunki poznała dopiero wtedy, gdy je złamała. Reszta tej strony to instrukcja, jak przeczytać ofertę, zanim zrobi to za ciebie awaria.

Domena, serwer i hosting - trzy osobne umowy

Te trzy rzeczy trafiają do jednego koszyka i na jedną fakturę, więc zlewają się w jedno. Technicznie są rozłączne i mogą pochodzić od trzech różnych firm.

  1. Domena jest nazwą. DNS wiąże nazwy domenowe z informacjami o zasobach (RFC 1034) - nazwa wskazuje drogę do serwera, ale nie zawiera żadnego środowiska.
  2. Serwer jest systemem, który przyjmuje żądanie i je obsługuje. Może to być maszyna fizyczna albo wirtualna, z jedną nazwą albo z wieloma.
  3. Hosting jest usługą - zakresem zasobów, oprogramowania i obsługi, który operator udostępnia na tym serwerze.

Rozdzielenie ma praktyczne skutki. Domenę przeniesiesz do innego operatora bez ruszania strony. Środowisko zmienisz bez zmiany adresu. Awarię diagnozujesz po właściwej stronie - problem z nazwą prowadzi do DNS, gdzie sprawdzisz wpis zapytaniem przez nslookup, a problem z odpowiedzią prowadzi do serwera i aplikacji.

Ma to też skutek z historii wyżej. Umowa na domenę i umowa na hosting to dwa zobowiązania z dwoma terminami, nawet gdy faktura jest jedna. Wygaśnięcie któregokolwiek wyłącza stronę niezależnie od stanu drugiego. Zapisz oba terminy tam, gdzie firma trzyma daty ważności, nie w skrzynce mailowej.

Domena z rynku wtórnego

Jeżeli zadaniem jest zakup domeny wystawionej na sprzedaż, sprawdź aktualne warunki bezpośrednio w serwisie partnera.

Link do partnera jest afiliacyjny - jeśli z niego skorzystasz, redakcja może dostać prowizję bez zmiany warunków po Twojej stronie.

Jak serwer wie, którą stronę pokazać?

Gdy klient otwiera adres, jego przeglądarka ustala przez DNS, dokąd wysłać żądanie, i wysyła je. W żądaniu HTTP przekazuje nazwę docelowego hosta w polu Host, a serwer korzysta z tej informacji przy obsłudze (RFC 9110, sekcja 7.2). Na tym opiera się name-based virtual hosting - serwer rozpoznaje po przysłanej nazwie, którą witrynę obsłużyć, więc wiele stron dzieli jeden adres (dokumentacja Apache HTTP Server). Cała klasa usług współdzielonych to właściwość protokołu, nie sztuczka cenowa.

Serwowanie plików i uruchamianie kodu to dwie osobne zdolności. W Apache dyrektywa DocumentRoot wskazuje katalog, z którego serwer udostępnia pliki - stronie statycznej to wystarcza. Aplikacja potrzebuje dodatkowo procesu, który jej kod wykona i dopiero wtedy wytworzy odpowiedź. Właśnie o tę różnicę rozbiła się rezerwacja maszyn z historii wyżej.

Jakie są typy hostingu?

Porównujemy tu cztery redakcyjne klasy środowiska - hosting współdzielony, usługę zarządzaną, platformę aplikacyjną i własne środowisko. Etykiety rynkowe nakładają się na siebie, dlatego klasę ustalasz po tym, co usługa daje, nie po nazwie w cenniku.

Typ środowiska Izolacja Runtime Dostęp Kto aktualizuje Kto robi kopię Jak migrujesz
Hosting współdzielony konta na wspólnym systemie, granice ustawia operator zestaw i wersje wybiera operator, sprawdzisz je w dokumentacji planu panel i kanały opisane w ofercie operator warstwę systemową w zakresie z umowy, klient własny kod wg umowy - potwierdź zakres, retencję i drogę odtworzenia eksport plików i bazy, format do potwierdzenia w dokumentacji
Hosting zarządzany zależna od architektury usługi, opisana w dokumentacji zestaw pod wspieraną aplikację, wersje w gestii operatora panel i uprawnienia wynikające z umowy operator to, co umowa nazywa zarządzaniem, resztę klient wg umowy - sprawdź, czy obejmuje bazę i pliki narzędzia migracyjne usługi plus eksport danych
Platforma aplikacyjna środowisko aplikacji oddziela platforma deklaruje klient w granicach wspieranych przez platformę interfejs wdrożeniowy, dostęp do systemu zależny od platformy platforma warstwę uruchomieniową, klient kod i zależności wg usług platformy - dane trwałe wymagają osobnej decyzji ponowne wdrożenie z repozytorium plus przeniesienie danych
Własne środowisko osobny system operacyjny w granicach od operatora dowolny - instaluje i utrzymuje klient dostęp administracyjny w zakresie z oferty klient system, runtime i usługi, operator warstwę niżej klient, chyba że dokupił usługę kopii obraz systemu albo odtworzenie konfiguracji na nowej maszynie

Tabela nie ustawia typów od gorszego do lepszego. Każdy wiersz to inny rozkład pracy - im więcej kontroli po twojej stronie, tym więcej obowiązków po tej samej stronie. Wybierasz między wygodą i władzą, a płacisz zawsze - abonamentem albo własnym czasem. Ten sam podział obowiązuje piętro wyżej, przy samym programie: gotowa usługa w abonamencie zdejmuje utrzymanie i wprowadza zależność od dostawcy.

Sprawdź aktualne warunki u potwierdzonych partnerów

Najpierw wybierz klasę środowiska z tabeli, a potem porównaj dokumentację planu ze swoimi wymaganiami. Poniższe odnośniki nie są rankingiem dostawców.

Na start kody rabatowe. cyber_Folks - FMRY-UOJM-4JHK, SEOHOST - wzg25pro, LH.PL - ibbmedia30, Hit Me - VUXL29G454NT.

Linki do partnerów są afiliacyjne - jeśli z nich skorzystasz, redakcja może dostać prowizję bez zmiany warunków po Twojej stronie.

Od czego zacząć wybór hostingu?

Zacznij od pytania, co ma się w tym środowisku wykonywać. Nie od ceny i nie od liczby kont poczty w ofercie - to najtańsza część każdego planu.

Strona statyczna potrzebuje publikacji plików i obsługi HTTP. Pliki trafiają do katalogu udostępnianego przez serwer i wracają do przeglądarki bez uruchamiania kodu. To najmniejszy możliwy zestaw wymagań i spełnia go każda klasa z tabeli.

Aplikacja podnosi poprzeczkę. Potrzebuje zgodnego runtime - środowiska, które wykona jej kod, w konkretnej technologii i wersji. Potrzebuje procesu żyjącego między żądaniami, dostępu do logów i drogi wdrażania nowych wersji. Brak jednej z tych rzeczy blokuje start niezależnie od tego, ile miejsca na dysku obiecuje plan.

Zanim otworzysz cennik, wypisz zależności tego, co uruchamiasz:

  1. runtime i jego wersja,
  2. proces działający w tle,
  3. baza danych,
  4. magazyn plików,
  5. zadania cykliczne,
  6. dostęp do logów,
  7. sposób wdrożenia nowej wersji.

Ta lista służy do odrzucania ofert, nie do rozmowy ze sprzedażą po zakupie. Baza danych, kolejka, zadania cykliczne i poczta to osobne zdolności planu - żadna nie jest domyślną cechą każdego hostingu i każdą potwierdzasz w dokumentacji konkretnej usługi.

Kto odpowiada za aktualizacje, kopie i awarie?

Zakres obsługi odczytasz z umowy i dokumentacji, nie z etykiety. Słowo "zarządzany" opisuje kierunek, nie zakres - jedna usługa pod tą nazwą aktualizuje system i runtime, druga tylko system, trzecia dokłada monitoring aplikacji. Różnicę widać dopiero w dokumencie opisującym świadczenie i to jego czytasz przed podpisaniem, nie stronę produktową.

Sześć pytań rozstrzyga podział pracy:

  1. Kto aktualizuje system operacyjny, kto runtime aplikacji i w jakim oknie?
  2. Co dokładnie obejmuje kopia - pliki, bazę, konfigurację - i jaka jest retencja?
  3. Kto wykonuje odtworzenie i czy zamówisz je samodzielnie?
  4. Kto obserwuje dostępność usługi i pod jaki adres trafia alarm?
  5. Jak zgłaszasz awarię i kto po stronie operatora prowadzi eskalację?
  6. Czy masz dostęp do logów systemowych i logów aplikacji?

Odpowiedź "to po naszej stronie" bez wskazania dokumentu nie zamyka żadnego punktu. Awaria weryfikuje umowę, nie deklarację handlową - firma z historii wyżej dowiedziała się o zakresie kopii w najgorszym możliwym momencie.

Gdzie kończy się plan „bez limitów"?

Każde środowisko ma granice, także to reklamowane jako pozbawione ograniczeń. Na systemach linuksowych zasoby kontroluje mechanizm cgroup v2 - jego kontrolery obejmują między innymi procesor, pamięć i operacje dyskowe, a konkretne wartości ustawia konfiguracja środowiska (dokumentacja kernela Linux). Limity istnieją zawsze. Pytanie brzmi tylko, czy je znasz.

Zapytaj wprost o te klasy limitów:

  • czas procesora dla kont i procesów,
  • pamięć operacyjna środowiska,
  • operacje wejścia i wyjścia na dysku,
  • liczba jednoczesnych procesów i wątków,
  • liczba jednoczesnych połączeń, w tym do bazy danych,
  • przestrzeń dyskowa oraz liczba plików i katalogów,
  • transfer sieciowy,
  • maksymalny czas wykonania żądania i zadania.

Każdą pozycję traktuj jak pole do wypełnienia wartością z dokumentacji planu. Dopytaj też, co się dzieje po przekroczeniu - żądanie odpada, proces ginie, usługa zwalnia czy licznik nalicza dopłatę. Limit bez opisanej konsekwencji to informacja niepełna.

Środowisko z ostro opisanymi limitami zaplanujesz, nawet jeśli liczby wyglądają skromniej niż hasło marketingowe. Wiesz, gdzie kończy się plan, i sprawdzasz to przed wdrożeniem, a nie w trakcie awarii.

Jak sprawdzić, czy klasa środowiska wystarczy?

Ocena ma pięć kroków i kończy się werdyktem o klasie środowiska, nie o dostawcy.

  1. Nazwij, co uruchamiasz. Technologia, wersja, zależności.
  2. Wypisz potrzebny poziom dostępu. Panel i publikacja plików czy własny proces, własna usługa, zmiana konfiguracji systemu.
  3. Przypisz osobę do aktualizacji, kopii, monitoringu i reakcji na awarię. Każda z tych czterech pozycji ma mieć nazwisko albo rolę po jednej ze stron. Pozycja bez osoby to dziura w projekcie, nie szczegół.
  4. Sprawdź drogę wyjścia. W jakim formacie odzyskasz pliki i bazę, ile trwa eksport i czy wykonasz go bez udziału operatora.
  5. Porównaj wynik z wierszami tabeli. Jeśli wymagania mieszczą się w klasie prostszej, nie kupuj bardziej rozbudowanej - przejąłbyś obowiązki, których nie ma kto wykonywać.

Werdykt brzmi "ta klasa obsłuży to, co uruchamiam" albo "nie obsłuży". Nie brzmi "ten dostawca jest najlepszy" - to inne pytanie, z innym rodzajem dowodu.

Pytania o hosting

Na czym polega hosting?

Hosting polega na udostępnieniu klientowi środowiska, w którym jego strona lub aplikacja przechowuje pliki i odpowiada na żądania z internetu. Operator dostarcza zasoby, oprogramowanie serwera i uzgodniony zakres obsługi. Klient umieszcza tam treści albo kod i odpowiada za warstwę aplikacji.

Co to znaczy hosting po polsku?

Hosting to usługa utrzymywania cudzych danych i aplikacji na infrastrukturze operatora. Klient wnosi treść i kod, operator udostępnia serwer z zasobami, a umowa opisuje granicę między nimi. Dosłowne tłumaczenie słowa niewiele wyjaśnia, bo znaczenie niesie właśnie ta granica.

Czym różni się hosting od domeny?

Domena jest nazwą, pod którą klienci znajdują usługę, a hosting środowiskiem, w którym ta usługa działa. DNS wiąże nazwę z informacją potrzebną do dotarcia do serwera. Domenę przeniesiesz bez zmiany hostingu, a hosting zmienisz bez zmiany domeny. To dwie osobne umowy z dwoma terminami ważności, nawet gdy kupisz je razem.

Jakie są typy hostingu?

Na tej stronie porównujemy cztery klasy środowiska - hosting współdzielony, hosting zarządzany, platformę aplikacyjną i własne środowisko. Różnią się izolacją, dostępnym runtime, zakresem dostępu oraz tym, kto aktualizuje, kto robi kopię i jak wygląda migracja. Nazwy handlowe planów bywają mieszane, więc klasę ustalasz po atrybutach usługi.

Po czym poznać, czy hosting obsłuży aplikację?

Sprawdź w dokumentacji planu sześć rzeczy - obsługiwany runtime i jego wersję, możliwość utrzymania procesu między żądaniami, dostęp do logów, sposób wdrożenia nowej wersji, limity zasobów oraz zakres obsługi po stronie operatora. Brak choćby jednej pozycji przesądza sprawę wcześniej niż cena.

Podstawa techniczna

  • Pole Host w żądaniu HTTP - RFC 9110, sekcja 7.2, https://www.rfc-editor.org/rfc/rfc9110#section-7.2.
  • Name-based virtual hosting - Apache HTTP Server, https://httpd.apache.org/docs/2.4/vhosts/name-based.html.
  • Katalog udostępniany przez serwer - Apache HTTP Server, dyrektywa DocumentRoot, https://httpd.apache.org/docs/2.4/mod/core.html#documentroot.
  • Wiązanie nazw domenowych z informacjami o zasobach - RFC 1034, https://www.rfc-editor.org/rfc/rfc1034.
  • Kontrolery zasobów systemu - dokumentacja kernela Linux, Control Group v2, https://docs.kernel.org/admin-guide/cgroup-v2.html.

Zakres tej strony

Tutaj definiujemy hosting przez środowisko, runtime i podział obowiązków. Jak dobrać całą architekturę dla strony lub aplikacji - od statycznej witryny po własny serwer - opisują typy środowisk dla strony i aplikacji. Jeżeli decyzja dotyczy zakupu urządzenia zamiast usługi, przejdź do sprzętu firmowego dobieranego do zadania. Zweryfikowane deklaracje dostawców i aktywne kody rabatowe zestawia porównanie hostingów bez fikcyjnego rankingu, a kolejność tych samych czterech ofert według kompletności deklaracji - ranking hostingu dla WordPressa. Cen nie podajemy na żadnej z tych stron.