Sdílený hosting (někdy také virtuální hosting) je služba, při které jeden server provozuje weby mnoha zákazníků. Každý zákazník má samostatný účet s vlastními soubory, databázemi, e-mailovými schránkami a limity prostředků, zatímco poskytovatel provozuje, aktualizuje a zabezpečuje samotný server. Je to nejlevnější a nejjednodušší způsob, jak hostovat běžný web, pokud nepotřebujete přístup root ani vlastní služby běžící na pozadí.
Pokud je pro vás téma nové, začněte tím, co je webhosting. Tento průvodce jde o úroveň hlouběji: jak se sdílený server ve skutečnosti dělí, co limity znamenají v praxi, co můžete a nemůžete dělat a jak poznat, že vám tarif přestal stačit.
Jak se jeden server dělí mezi účty
Na sdíleném serveru je každý zákazník samostatným uživatelem Linuxu. Ovládací panel vytvoří tohoto uživatele, domovský adresář a pro každý web konfiguraci webového serveru, takzvaný virtuální host. Odtud pochází i název: dokumentace Apache definuje virtuální hosting jako provoz více než jednoho webu na jednom stroji, obvykle mnoha domén na jedné IP adrese. O tom, kolik ze serveru skutečně dostanete, rozhodují čtyři mechanismy.
1. Samostatný účet a prostor pro soubory
Vaše soubory leží ve vašem domovském adresáři a patří vašemu uživateli. Ostatní zákazníci je nemohou číst a diskovou kvótu obvykle tvoří soubory webu, databáze a pošta dohromady.
2. Pooly PHP-FPM
Většinu webů v PHP spouští PHP-FPM, správce procesů FastCGI. Příručka PHP ho popisuje jako způsob, jak provozovat několik poolů procesů s různým nastavením. Na sdíleném hostingu má každý účet, nebo každá doména, vlastní pool, který běží pod uživatelem daného účtu. Pomocí pm.max_children pool omezuje, kolik požadavků PHP může běžet současně; další čekají ve frontě. Toto je výňatek z typické výchozí šablony poolu hostingového panelu (řádek open_basedir je zkrácený):
[%backend%]
listen = /run/php/php%backend_version%-fpm-%domain%.sock
user = %user%
group = %user%
pm = ondemand
pm.max_children = 8
pm.max_requests = 4000
pm.process_idle_timeout = 10s
php_admin_value[open_basedir] = /home/%user%/web/%domain%/public_html:/home/%user%/tmp:/tmp
Čte se to takto: jeden pool na doménu, běžící pod vlastním uživatelem zákazníka; procesy PHP se spouštějí až s příchodem požadavků a končí po 10 sekundách nečinnosti; současně jich běží nejvýše 8; a open_basedir drží skripty PHP ve složkách vlastního účtu. Jde o výchozí hodnoty panelu, ne o slib konkrétního hostingu, protože poskytovatelé čísla upravují podle tarifu. Osm procesů obslouží mnohem víc než osm návštěvníků, protože stránka z mezipaměti se vygeneruje ve zlomku sekundy. Fronta roste, když jsou stránky pomalé: těžké pluginy, stránky bez cache, pomalé dotazy do databáze nebo volání externích API.
3. Limity prostředků pro každý účet
Mnoho poskytovatelů přidává pro každý účet limity na úrovni jádra. Nejznámější implementací je CloudLinux LVE postavený na linuxových cgroups; jiná řešení používají přímo cgroups nebo podobné nástroje, ale parametry jsou do velké míry stejné:
- CPU: podíl procesorového času, často vyjádřený jako procento jednoho jádra. Když ho dosáhnete, web nespadne, jen zpomalí.
- Fyzická paměť: RAM, kterou využívají všechny vaše procesy dohromady. Když dojde, procesy se ukončí a návštěvníci obvykle vidí chyby 500 nebo 503.
- Vstupní procesy (entry processes): kolik požadavků může současně vstoupit do vašeho účtu. Na CloudLinuxu vrací dosažení tohoto limitu chybu 508 „Resource Limit Reached“.
- Počet procesů: všechny procesy a vlákna včetně úloh cron a relací SSH.
- Diskové IO a IOPS: propustnost čtení a zápisu a počet operací za sekundu, aby skript zálohy v jednom účtu nezablokoval disk všem ostatním.
4. Disková kvóta a inody
Kromě gigabajtů souborový systém počítá inody: jeden na každý soubor nebo složku. Web na WordPressu s mezipamětí stránek, několika velikostmi náhledů pro každý obrázek a schránkami, které ukládají každou zprávu jako samostatný soubor, může mít desítky tisíc souborů a přitom zabírat málo místa. Někteří poskytovatelé počet inodů omezují (CloudLinux tento limit uplatňuje přes diskovou kvótu), proto kontrolujte toto číslo stejně jako gigabajty.

Pokud tyto chyby už vidíte, naše návody k chybě 503 Service Unavailable a k tomu, jak zvýšit memory_limit v PHP, ukazují, jak najít příčinu v logách.
Co dostanete a co nejde
Sdílený tarif je spravovaná služba: poskytovatel instaluje, aktualizuje a monitoruje operační systém, webový server, PHP, databázový server a poštu. Vy spravujete své weby přes ovládací panel. Typický tarif obsahuje:
- weby a domény, každou s vlastní složkou a nastavením;
- databáze MySQL nebo MariaDB;
- e-mailové účty na vlastní doméně;
- přístup přes FTP nebo SFTP a správce souborů;
- plánované úlohy (cron);
- bezplatné certifikáty SSL a volbu verze PHP.
Co na sdíleném hostingu obvykle nejde:
- Žádný root ani sudo. Nemůžete instalovat systémové balíčky, měnit nastavení celého serveru ani načítat moduly jádra.
- Žádní vlastní démoni. Trvale běžící procesy, které naslouchají na vlastním portu, například server Node.js, bot dotazující API ve dne v noci nebo vlastní Redis či Elasticsearch, ukončí limity procesů nebo pravidla poskytovatele.
- Žádný vlastní webový server ani vlastní sestavení PHP. Nastavení měníte jen v panelu, v souborech
.htaccess(na Apache) nebo v souborech.user.ini. - Žádné dlouhé úlohy z prohlížeče. Požadavky PHP ukončí
max_execution_timea časové limity poolu, takže kódování videa nebo hodiny trvající importy patří jinam. - Žádné změny firewallu ani sítě. Porty, pravidla firewallu a směrování spravuje poskytovatel.
Pro koho je sdílený hosting a kdy přejít jinam
Sdílený hosting se hodí pro firemní a prezentační weby, landing pages, blogy, weby na WordPressu s cache, malé e-shopy, portfolia, e-mail na vlastní doméně a agentury, které mají několik malých webů klientů v jednom účtu. U takových projektů bývají úzkým hrdlem jen zřídka popsané limity; mnohem častěji jsou to pomalé pluginy a chybějící cache.
Čas na změnu přichází, když:
- při běžném provozu pravidelně narážíte na limity CPU, paměti nebo vstupních procesů, ne jen při jednorázové špičce, a vyšší tarif už nepomáhá;
- potřebujete přístup root, vlastní stack (Node.js, aplikační servery v Pythonu, Docker), WebSockety nebo workery na pozadí;
- potřebujete ladit samotný server: vlastní konfiguraci Nginx, Redis pro relace, rozšíření PHP, která poskytovatel nenabízí;
- smlouva nebo předpisy vyžadují server, který se nesdílí s dalšími zákazníky.
Prvním krokem bývá vyšší tarif u stejného poskytovatele. Dalším je VPS. RichHost neprodává VPS ani dedikované servery, takže v tu chvíli budete potřebovat VPS od jiného poskytovatele. Přechod si dobře naplánujte, aby proběhlo stěhování hostingu bez výpadku.
Jak posoudit tarif sdíleného hostingu
Prodejní stránky obvykle ukazují stejný seznam funkcí. Tyto otázky odhalí skutečné rozdíly mezi tarify a poskytovateli:
- Limity prostředků. Jsou limity CPU, RAM a procesů zveřejněné v číslech? „Neomezeně“ se obvykle týká přenosů nebo počtu webů, nikdy CPU.
- Inody. Je omezen počet souborů a započítává se do něj pošta?
- Úložiště. NVMe, nebo starší SSD, a zahrnuje kvóta databáze a schránky?
- PHP. Lze zvolit verzi PHP pro každý web? Jaké jsou výchozí hodnoty
memory_limitamax_execution_time? - Zálohy. Jak často se dělají, jak dlouho se uchovávají a můžete sami obnovit jeden web nebo soubor?
- SSL. Bezplatné certifikáty Let’s Encrypt s automatickou obnovou by měly být standardem.
- Umístění. Vybírejte servery blízko návštěvníkům a změřte ping a TTFB na testovací IP nebo demo web poskytovatele z regionu svého publika.
- Cena v čase. Porovnávejte cenu prodloužení, ne jen akci na první rok.
U neomezeného přenosu se také zeptejte, zda poskytovatel po překročení limitu fair use nesnižuje rychlost; jak poznat omezení rychlosti přenosu na hostingu a změřit ho pomocí curl, popisujeme samostatně.

Sdílený hosting, VPS, cloud a dedikovaný server
| Parametr | Sdílený hosting | VPS | Cloudový hosting | Dedikovaný server |
|---|---|---|---|---|
| Co si pronajímáte | Účet na serveru, který provozuje poskytovatel | Virtuální stroj s pevnými prostředky | Virtuální prostředky účtované podle spotřeby | Celý fyzický server |
| Přístup root | Ne | Ano | Ano, u cloudových serverů | Ano |
| Kdo spravuje systém | Poskytovatel | Vy, pokud nejde o spravovanou službu | Vy nebo poskytovatel, podle služby | Vy, pokud nejde o spravovanou službu |
| Izolace | Limity na účet; jádro a disk jsou sdílené | Vlastní jádro a vyhrazená RAM na sdíleném hardwaru | Jako VPS, navíc oddělené instance | Úplná: žádní sousedé |
| Škálování | Přechod na vyšší tarif | Zvětšení stroje, často s restartem | Přidání prostředků nebo instancí podle potřeby | Nový hardware nebo další servery |
| Potřebné znalosti | Panel, FTP, CMS | Správa Linuxu | Linux a cloudové nástroje | Správa Linuxu a plánování hardwaru |
| Obvyklá cena | Nejnižší | Vyšší | Podle spotřeby | Nejvyšší |
| Nejlepší pro | Weby, blogy, malé e-shopy, e-mail | Vlastní stack, aplikace, boty | Proměnlivou nebo rychle rostoucí zátěž | Velké nebo silně regulované projekty |
Základy izolace a bezpečnosti
Na dobře nastaveném sdíleném serveru stojí oddělení zákazníků na několika vrstvách:
- Oddělení uživatelé a oprávnění souborů. Vaše soubory patří vašemu uživateli. Obvyklým základem je 644 pro soubory a 755 pro složky; 777 není nikdy potřeba.
- PHP běží pod vaším uživatelem ve vašem vlastním poolu. Napadený web v jiném účtu nemůže zapisovat do vašich souborů a díky
open_basedirskripty PHP nemohou mimo povolené složky ani číst. - Virtualizovaný souborový systém u některých poskytovatelů. Příkladem je CloudLinux CageFS: každý uživatel vidí jen své soubory a omezenou sadu systémových nástrojů, ne ostatní uživatele serveru.
- Limity prostředků. Brání tomu, aby jeden napadený nebo přetížený účet shodil celý server.
Dvě věci zůstávají na vás. Zaprvé, weby ve vašem vlastním účtu obvykle běží pod stejným uživatelem, takže jeden infikovaný web může nakazit ty vedlejší: aktualizujte CMS, šablony a pluginy a mažte staré instalace, které už nepoužíváte. Zadruhé, přístupy: používejte silná, jedinečná hesla a dvoufázové přihlášení do panelu i do administrace webu a každý web provozujte přes HTTPS (viz SSL certifikát na sdíleném hostingu). Sdílené IP adresy přinášejí další společné riziko: pokud soused rozesílá spam, může utrpět pověst IP adresy, proto je důležité nastavení SPF, DKIM a DMARC pro vaši doménu.
Sdílený hosting RichHost ve zkratce
RichHost je mezinárodní poskytovatel hostingu, který působí od roku 2003 a má servery v Evropě a USA. Prodává pouze sdílený hosting a domény: tarify A3 (8 $ měsíčně), A5 (10 $), A10 (13 $), A20 (20 $), A30 (35 $) a A50 (65 $), se slevou 10 % při roční platbě. Všechny tarify běží na NVMe discích s neomezenými přenosy, neomezeným počtem webů, schránek a FTP účtů, vlastním ovládacím panelem s asistentem AI a bezplatným SSL Let’s Encrypt. Porovnat je můžete na stránce s tarify hostingu. RichHost neprodává VPS ani dedikované servery: pokud váš projekt potřebuje přístup root, zvolte VPS u jiného poskytovatele.
Jak jsme to ověřili
Zdroje ověřené 30. 10. 2026: dokumentace CloudLinux OS k limitům LVE (SPEED, PMEM, EP, NPROC, IO, IOPS, inody, chyba 508) a k CageFS; příručka PHP ke konfiguraci PHP-FPM (pooly, režimy pm, pm.max_children); dokumentace Apache HTTP Server k virtuálním hostům. Uvedené hodnoty poolu jsou typická výchozí nastavení, nikoli měření na serverech RichHost. Údaje o tarifech RichHost pocházejí z naší stránky s tarify.
Časté otázky
Je sdílený hosting totéž co virtuální hosting?
Ano. Oba názvy popisují server, na kterém běží weby mnoha zákazníků. „Virtuální hosting“ vychází z pojmu virtuální host u webových serverů: mnoho domén obsluhovaných jedním strojem, často z jedné IP adresy.
Můžu na sdíleném hostingu provozovat Node.js nebo bota?
Jen pokud to poskytovatel výslovně podporuje, například přes správce aplikací v panelu. Proces, který běží nepřetržitě nebo naslouchá na vlastním portu, se na sdíleném hostingu obvykle ukončí; na to potřebujete VPS.
Může web souseda zpomalit ten můj?
Limity CPU, paměti a IO na účet to výrazně omezují, ale disk, síť a IP adresa zůstávají sdílené. Dobří poskytovatelé servery nevytěžují naplno a hlídají pověst svých IP adres.
Jak poznám, že mi sdílený hosting přestal stačit?
Sledujte opakované chyby 503 nebo 508 a dosažené limity CPU či paměti ve statistikách panelu při běžném provozu. Nejdřív optimalizujte (cache, méně pluginů, lehčí stránky), pak zkuste vyšší tarif; na VPS přejděte, když potřebujete přístup root nebo software, který poskytovatel nemůže provozovat.



