Vad är en molnserver: webbhotell, VPS och vad webbplatsen faktiskt behöver

Webbhotell, VPS och molnserver ser i prislistan ut som tre prestandanivåer, men skiljer sig på tre punkter: vad som skiljer dig från grannarna på samma maskin, var kontot tar stopp och vem som uppdaterar programvaran.

En onsdagsmorgon runt tio blir webbplatsen långsam — inte död, bara långsam: sidan öppnas på fem sekunder, adminpanelen vägrar spara ett inlägg, och efter en halvtimme är allt som vanligt igen, som om ingenting hade hänt. Leverantörens support svarar efter lunch att kontot har överskridit planens gränser, och erbjuder ett byte till nästa nivå, som kostar tre gånger mer och i prislistan heter ”molnserver”.

Vad är en molnserver — och vad de andra två är — går inte att utläsa ur radens namn. I det läget vet de flesta köpare inte vad de egentligen köper, och det är inte en förebråelse: webbhotell, VPS och molnserver är i prislistan staplade under varandra som tre prestandanivåer för samma tjänst, fast de är tre olika tekniska lösningar som skiljer sig på tre konkreta punkter, och var och en av dem kan du kontrollera med din webbplats egna siffror i handen.

Tre ställen där planerna faktiskt skiljer sig

Det första är isoleringen, det vill säga vad som faktiskt skiljer din webbplats från de andra kundernas webbplatser på samma fysiska maskin. På ett webbhotell är det ett konto i operativsystemet tillsammans med en resurscontainer som ligger i kärnan, på en VPS är det en egen virtuell maskin med eget operativsystem, och på en molnserver är det samma virtuella maskin, bara beställd och betald på ett annat sätt. Den praktiska skillnaden mellan de tre varianterna ligger i hur mycket en grannes last kan påverka din webbplats, och i hur mycket av maskinen du över huvud taget får ändra när det visar sig att standardkonfigurationen inte räcker.

Det andra stället är gränsen, det vill säga var kontot tar stopp och hur det tar sig uttryck, och det är just här de flesta missförstånden uppstår, för människor räknar med att överbelastning betyder en långsam sida, trots att det i en del fall betyder en sida som inte öppnas alls och som returnerar en felkod köparen aldrig har sett. Det tredje stället är ansvaret, det vill säga vem som uppdaterar operativsystemet, vem webbservern, vem PHP och vem själva webbplatsen, och det är här VPS-köpare räknar fel oftast, för root-åtkomst är ingen gåva som leverantören räcker över tillsammans med en starkare maskin — det är en överlämning av en lista med skyldigheter från dem till dig, och den sker tyst, i samma minut som lösenordet skickas.

Allt annat som tar rader i en jämförelsetabell för hosting är antingen lika i alla planer, eller inte det som ger vika: NVMe-diskar finns i dag i stort sett överallt, men ”obegränsad datatrafik” är ett påstående om överförd datamängd, inte om resurser, och det står vanligtvis precis intill tabellen där resurserna är räknade till sista megabyte. 99,9 % är däremot en siffra med precis juridisk betydelse och med en lista undantag under sig, och merparten av köparna tror att den täcker något helt annat än det den faktiskt täcker.

Webbhotell: en server, många konton

Ett webbhotell är ett användarkonto på en maskin där det bor ytterligare hundratals likadana konton, och svenska leverantörer säljer samma produkt under just det ordet — webbhotell — medan jämförelsetexterna kallar modellen delat webbhotell. Tekniskt betyder det i båda fallen samma överenskommelse: du äger ett konto, inte maskinen, webbplatsen sköter du via cPanel eller en liknande panel, och allt som ligger under den panelen tillhör någon annan.

Det som skiljer dig från grannarna är konkret programvara, inte ett löfte i prislistan, och den programvaran är värd att kunna vid namn. Merparten av cPanel-leverantörerna kör CloudLinux, där varje konto har en egen kopia av filsystemet: i dokumentationen om CageFS skriver CloudLinux att användare varken kan se eller upptäcka andra användare och deras användarnamn på servern, inte kan läsa webbserverns konfiguration och bara ser en avkortad processlista. Det andra lagret är LVE — en resurscontainer på kärnnivå som sätter gränser för processor, minne, I/O och processer för varje konto, just för att, som dokumentationen själv formulerar det, ingen enskild webbplats ska kunna fälla hela webbservern.

Det tredje lagret är PHP-inställningen open_basedir, och där är det värt att veta vad PHP-handboken själv säger, inte vad leverantörens marknadsföring säger: det är ett extra skyddsnät som på inget sätt är heltäckande och som man inte kan förlita sig på när säkerheten verkligen behövs. På samma ställe varnar handboken för att även avstängning av funktioner med disable_functions kan kringgås, och att det i en delad miljö inte är en tillräcklig skyddsåtgärd. Ingenting av det är ett argument mot webbhotell; det är ett argument för att isoleringen här kommer från kärnan och filsystemet, inte från en rad i en konfigurationsfil, och att en leverantör som på frågan om isolering svarar med ordet ”säkert” inte har svarat på den.

Vad du inte kan välja på ett webbhotell är lika viktigt som vad du kan: kärnan är en och densamma för alla konton, så kärnversionen byter du inte, listan över PHP-versioner bestäms av leverantören och ligger vanligtvis en eller två efter den senaste, och webbservern är den som är installerad, så på frågan om ett paket som inte finns där blir svaret ”nej”, inte ”installera det”. En delad server är också den plats där leverantören vid en incident måste kontrollera grannkontona, för en angripare som har tagit sig in i ett konto försöker samma sak hos grannarna; vad man gör när det redan har hänt har vi beskrivit i artikeln om en hackad WordPress-webbplats. Ingen av de här gränserna är en brist: det är precis den överenskommelse som gör produkten billig, och köparen som förstår den har nytta av den.

Vad som händer när kontot når sin gräns

Ett webbhotellpaket har flera olika slut, de nås oberoende av varandra och tar sig helt olika uttryck, så symptomet är ett användbart diagnostiskt verktyg. CloudLinux-standardgränser för ett konto är 100 % av en processorkärna, 1 GB fysiskt minne, 1024 KB/s I/O, hundra processer och tjugo entry processes, och det är just den sista siffran som överraskar köpare, för tjugo låter löjligt litet för en webbplats som tar emot tio tusen besökare i månaden.

Förklaringen är att en entry process inte är en besökare: det är en process som kommer in i kontot utifrån — en ny HTTP-begäran till ett PHP-skript, en SSH-session eller ett cron-jobb — medan processer som redan uppstår inuti räknas mot en helt annan gräns. När antalet entry processes är nått släpper Apache-modulen inte in nästa begäran utan svarar med felet 508 Resource Limit Reached, och CloudLinux beskriver det utan försköning i sin kunskapsbas: webbplatsen som förbrukar för mycket resurser slutar fungera, men övriga kunder på samma server fortsätter som vanligt. Precis det är poängen med mekanismen — att stänga av ett konto så att maskinen inte stannar.

De övriga gränserna tar sig andra uttryck, och av symptomet kan man läsa av vilken som är nådd innan någon börjar gissa: processor och I/O kapas inte utan stryps, så sidan blir långsam och öppnas till slut, medan minnes- och processgränser vanligtvis ger 500 eller 503, alltså en sida som inte öppnas alls. På LiteSpeed-servrar räknas entry processes annorlunda än på Apache, så där får samma siffra inte översättas till antalet samtidiga besökare, och det är ett av de vanligaste sätten en korrekt siffra hamnar i en felaktig mening.

Det finns ännu ett fjärde slut, som inte har med last att göra alls och därför dyker upp oväntat: en inode är filsystemets post om en fil eller en mapp, så antalet inoder i kontot är helt enkelt antalet filer och mappar, inklusive den e-postlåda ingen har rensat på åratal. Hostnet publicerar inode-antalet öppet i sin prislista — 400 000 i MINI, 600 000 i PLUS, 800 000 i PRO — och i samma tabell står MINI och PLUS med 100 % av en kärna och 2048 MB minne, men PRO med 200 % och 3072 MB, och alla tre med 10 MB/s I/O och 150 samtidiga anslutningar, medan månadens datatrafik är ”obegränsad”. Den kombinationen är den verkliga läxan om ordet ”obegränsad” i en prislista för hosting: det avser överförd datamängd, och alla övriga gränser står precis intill, räknade till sista siffran.

VPS: eget operativsystem på delad hårdvara

En VPS är en virtuell maskin där du äger operativsystemet, root-åtkomst och möjligheten att installera det som behövs, och på den svenska marknaden skrivs det med den engelska förkortningen: VPS, utskrivet Virtual Private Server. Det namnet inte säger är två tekniska frågor som avgör hur mycket av ”den egna servern” som faktiskt är din.

Den första frågan är om virtualiseringen ligger på hårdvaru- eller operativsystemsnivå. KVM är en modul i Linux-kärnan som använder processorns virtualiseringstillägg och ger varje gäst sin egen virtualiserade hårdvara — nätverkskort, disk, grafikkort — och framför allt sin egen kärna, så där kan man också köra omodifierad Windows. LXC och närbesläktade containrar är en annan mekanism: de använder Linux-namnrymder, cgroups och behörighetsbegränsning för att skapa en miljö som ligger så nära en separat Linux-installation som möjligt, men utan en separat kärna. Följden är enkel och praktisk — i containern förblir kärnversion, kärnmoduler och kärnsårbarheter gemensamma med värdmaskinen, så en del av det du trodde du köpte blev faktiskt kvar hos grannarna.

Den andra frågan gäller processorn, för orden ”egen server” betyder inte egen processor. Hetzner har två skilda produktlinjer för molnservrar: i planer med delade resurser fördelas beräkningskraften mellan alla instanser på samma fysiska server, med en basprestanda och möjlighet att tillfälligt gå över den, medan i planer med dedikerade resurser är en vCPU en tråd på en fysisk kärna och bara din. DigitalOcean formulerar det ännu tydligare: i en plan med delade resurser kan tråden delas med andra, och om grannarna har hög last får instansen delar av tråden, inte full åtkomst, så att full åtkomst i praktiken är möjlig men inte garanterad.

Hur många grannar som sitter på samma maskin publicerar ingen av de stora leverantörerna, och den kvot du hittar i bloggar är inte någons publicerade mätning, så den är varken värd att citera eller att tro på. Den enda dokumenterade storheten man kan hänvisa till är om planen utlovar delade eller separata resurser, och den skillnaden står vanligtvis helt öppet — med två olika produktnamn, två olika specifikationer och en prisskillnad som är flera gånger så stor.

Vad är en molnserver: samma VPS, köpt på ett annat sätt

En molnserver är tekniskt sett en virtuell maskin på en hypervisor, alltså precis samma sak som en VPS, och Hetzner inleder sin dokumentation med samma mening: molnservrar är virtuella maskiner som körs på fysiska servrar. Om du av två erbjudanden väntar dig två olika hårdvaror finns det ingen grund för den förväntan.

Skillnaden ligger inte i hårdvaran utan i sättet den köps, och det beskrivs mest precist av den definition från den amerikanska standardiseringsmyndigheten NIST som branschen fortfarande citerar: molnet har fem kännetecken — självbetjäning vid behov, åtkomst via nätet, sammanslagning av resurser med flera hyresgäster, snabb elasticitet och mätt förbrukning. I praktiken betyder det ett API som kan skapa och riva maskinen programmatiskt, timdebitering med ett tak per månad och extra delar som kan kopplas på separat: snapshots, separat blocklagring, en flyttbar IP-adress och en lastbalanserare.

Var och en av de delarna har gränser som är värda att känna till före köpet, inte en månad efter det. Ett byte av Hetzner-plan kan inte minska diskens storlek ens när bara en del av den används; efter en utökning måste du själv utöka partitionen i räddningsläge, och själva planbytet står upptaget som undantag från tillgänglighetsgarantin. En snapshot är däremot inte en säkerhetskopia, även om marknaden använder de två orden som synonymer: Hetzner-snapshots omfattar inte anslutna volymer, och konsistens garanteras inte om servern körs, så det är en bra sak före en uppdatering och en dålig sak som enda datakopia. Den flyttbara IPv4-adressen kostar extra, precis som den primära IPv4-adressen på själva instansen.

En företagswebbplats på fem sidor använder vanligtvis ingen av de här delarna, och det är den ärligaste meningen i det här avsnittet: om webbplatsen aldrig ändrar kapacitet, aldrig växlar över till en andra maskin och aldrig kopplas till ett API, då är molnservern och en VPS av samma storlek en och samma maskin med två olika räkningar. Det är inte ett argument mot molnet, för där elasticiteten faktiskt används kostar den mindre än en ständigt hållen reserv. Det är ett argument för att valet står mellan möjligheter du verkligen kommer att använda, inte mellan ord som låter moderna.

Vem som uppdaterar vad

Den största praktiska skillnaden mellan de tre planerna är inte hastigheten utan fördelningen av skyldigheter, och tydligast har den formulerats av molnleverantörerna själva. AWS-modellen för delat ansvar delar upp allting i två delar: säkerheten för molnet är AWS ansvar — hårdvara, programvara, nät och de lokaler där tjänsterna körs — medan säkerheten i molnet är kundens ansvar. I patchfrågan står det till och med skrivet separat och ord för ord: AWS ansvarar för infrastrukturens patchar och fel, men kunden ansvarar för patcharna i gästens operativsystem och i de egna applikationerna.

På ett webbhotell tillhör det lagret leverantören, och det är produktens största värde, som sällan någon tänker på: kärnan, webbservern och PHP uppdaterar de, och du vet ingenting om det förrän något går sönder. På en VPS eller molnserver utan managed hosting gick alltihop över till dig tillsammans med root-lösenordet, och Hetzner säger det också från andra hållet i sina villkor: programvara, konfiguration och systeminställningar som kunden inför räknas inte som ett tillgänglighetsavbrott, alltså ansvarar inte leverantören för dem och de ingår inte i någon ersättning.

Själva webbplatsen förblir ditt ansvar i alla tre fallen, och det är den punkten där erbjudandena ska läsas noga, för ordet ”managed” betyder i branschen vanligtvis operativsystem och serverprogramvara, inte WordPress-kärnan, tilläggen och temat. Också i vår egen drift av infrastruktur ingår uppdateringar av operativsystem och serverprogramvara, säkerhetskonfiguration, säkerhetskopior med testad återläsning, övervakning och åtgärd enligt SLA — och där står det inte skrivet att vi uppdaterar dina tillägg, för det är en annan rad i prislistan och ett annat avtal, och vi säger det tydligt så att ingen ska upptäcka den gränsen på incidentdagen.

Det praktiska testet före beställningen är en fråga, ställd rakt och i tre delar: vem uppdaterar operativsystemet, vem webbservern och PHP, och vem webbplatsens kod. Om svaret på någon av de tre är ”du själv”, då är det arbete som kräver antingen en människa med tid eller ett avtal med någon annan, och ingetdera är gratis. Obesvarad försvinner frågan inte — den kommer tillbaka efter arton månader som ett system där ingen har lagt in en enda patch, och då är det inte längre en fråga om val av plan.

Vad 99,9 % betyder och vad de inte täcker

Tillgänglighetsprocenten i prislistan ser ut som ett löfte, men är i själva verket en formel med en lista undantag. Hetzners servicenivåavtal för molnservrar lovar 99,9 % i månaden för en instans, och Hetzner själv räknar i sin förklaring ut vad siffran betyder i praktiken: i en månad med trettio dagar ligger 43 minuters nertid fortfarande inom avtalet, det vill säga det är inte ett avtalsbrott och det ger ingen ersättning alls.

Själva ersättningen är lika konkret och mycket mindre än människor väntar sig: den räknas från minuterna över tröskeln, omräknade till timmar och multiplicerade med instansens timtaxa, och betalas ut som tillgodohavande mot framtida förbrukning, inte som pengar. I Hetzners eget exempel ger 185 minuters nertid 142 minuter över tröskeln, alltså 2,37 timmar, och ett tillgodohavande på 0,87 €, vilket är mindre än en timmes arbete med att räkna ut det. Utebliven omsättning, förlorade ordrar och sjunkna placeringar i sökresultaten ingår inte någonstans där, och inget hostingavtal vi har läst täcker dem.

Undantagslistan är lika viktig som siffran, för det är den som avgör hur ofta siffran över huvud taget tillämpas: utanför avtalet ligger i förväg aviserat underhåll, kundens egen programvara och konfiguration, planbyte som kunden har begärt, livemigreringar för värdmaskinens stabilitet och nätet utanför leverantörens stomnät. Allt det står skrivet ärligt och öppet, och ur det följer en enkel slutsats: procenten avser maskinen, inte din webbplats, så en webbplats som föll efter en misslyckad uppdatering ligger helt utanför det här avtalet.

Dessutom är 99,9 % ingen branschkonstant, även om den ofta används som om den vore det. Amazons EC2-avtal för en instans lovar 99,5 %, men 99,99 % bara om instanserna ligger i minst två tillgänglighetszoner, det vill säga det är två olika avtal med två olika siffror, och meningen ”i branschen är 99,9 %” plattar till båda till en. På webbhotell finns ett sådant dokument vanligtvis inte alls — bara en siffra på webbplatsen utan definition, utan mätmetod och utan följder, och det är ett påstående, inte en förpliktelse.

Så mäter du din webbplats före valet

Siffran som avgör är inte antalet besökare i månaden, även om det är precis den köparen kan utantill och precis den säljaren frågar efter först. Det som avgör är antalet samtidiga PHP-begäranden i det ögonblick lasten är som störst, och det är en helt annan storhet, som korrelerar svagt med månadens besök.

Två webbplatser med samma besök kan ligga på olika sidor om en och samma gräns, och skillnaden ligger i hur länge varje sida håller en process. En statisk, cachelagrad företagswebbplats betjänas till största delen av webbservern utan PHP, så den förbrukar nästan inga entry processes och tio tusen besökare i månaden betyder ingenting för den. En webbutik där varje varukorg, varje inloggning och varje återkomst från betalväxeln håller en PHP-process i två sekunder kan nå samma gräns redan vid tjugo samtidiga köpare, och det är därför det i kampanjens första timme just är de butiker som har betalat för kampanjen som faller.

Tillsammans med den siffran är det värt att läsa av ytterligare tre, och alla tre går att få fram utan hjälp av en utvecklare. Den första är databasens storlek och den långsammaste frågan i den, för det är vanligtvis den som är den verkliga orsaken till långsamhet, inte maskinens kraft. Den andra är antalet filer i kontot, för inode-gränsen nås oväntat och utan förvarning av webbplatser med stora mediabibliotek och med en gammal e-postlåda. Den tredje är det webbplatsen gör utanför webbläsaren — cron-jobb, utskick av e-post, integrationer mot bokföringssystemet — för de processerna kommer också in i kontot utifrån och räknas mot samma gräns som du nyss mätte för köparna.

Alla fyra siffrorna går att läsa av på en eftermiddag ur statistiken i hostingpanelen och ur serverloggarna, och det är det enda stället där din webbplats verkliga last finns, inte en aning om den. Planens namn känner inte till de siffrorna, säljaren som inte har sett dem känner inte heller till dem, och ett samtal som börjar med dem slutar vanligtvis med ett billigare svar än ett samtal som börjar med en lista över planer.

När bytet hjälper och när det inte löser något

Ett byte till en större plan är rätt svar betydligt mer sällan än det erbjuds, och det första fallet där det inte hjälper är också det vanligaste. Om webbplatsen är långsam för att en enda fråga läser hela produkttabellen vid varje sidöppning, då kommer en starkare maskin att köra den fortare, problemet blir kvar, och du har köpt tid, inte en lösning. Detsamma gäller fyrtio tillägg, obehandlade bilder i originalstorlek och ett tema som vid varje begäran bygger menyn från noll.

Bytet är rätt svar när gränsen är nådd med korrekt kod: om webbplatsen är cachelagrad, frågorna är i ordning och kontot ändå slår i antalet entry processes, då är det planens gräns, inte ett fel i koden, och det finns inget mer att optimera. På samma sätt är bytet det enda svaret när det behövs något som inte går att installera på ett delat konto — en annan PHP-version, en köhanterare, Redis, en egen cron med minutsteg — eller när ett bransch-, upphandlings- eller kundkrav anger i vilket land data fysiskt ska ligga.

Det finns också ett tredje fall, som säljare sällan talar om, för det sänker räkningen: ibland är rätt rörelse nedåt. En webbplats som för tre år sedan flyttades till en VPS på grund av en enda reklamkampanj och som sedan dess tar emot tvåhundra besökare om dagen betalar för en maskin den inte använder, och den betalar dubbelt — med pengar på räkningen och med en människas tid, för VPS:ens operativsystem måste någon uppdatera även när ingen går in där.

Före varje flytt är det värt att lösa ytterligare en fråga som inte har med kapacitet att göra alls: i vems namn domänen är registrerad och i vems namn hostingkontot står. Om det har vi skrivit separat i artikeln om misstag när du beställer en webbplats, och det här är en av de frågor som på flyttdagen inte längre går att laga snabbt, för svaret beror på en människa du kanske inte längre talar med.

Vad du köper när planen kallas managed hosting

Prisskillnaden mellan en oadministrerad maskin och en med managed hosting är stor, och den är inte ett påslag för samma vara, så båda siffrorna förtjänar att läggas intill varandra. I Hetzners prislista, som trädde i kraft den 15 juni 2026, kostar molnservern CX23 med två vCPU, fyra gigabyte minne och 40 GB disk 5,49 € i månaden exklusive moms, och den primära IPv4-adressen kommer ovanpå för 0,50 € i månaden. Vår hosting av infrastruktur börjar på 45 € i månaden, och skillnaden mellan de två siffrorna är precis vad det här avsnittet handlar om.

Skillnaden är arbete, och det kan räknas upp en sak i taget: uppdateringar av operativsystem och serverprogramvara, säkerhetskonfiguration, övervakning med Zabbix dygnet runt och åtgärd enligt SLA, säkerhetskopior varje dag med 30 dagars lagringstid och regelbundet testad återläsning, och för särskilt kritisk infrastruktur — upp till 365 dagar och i två olika länder i Europeiska unionen. Förberedelse av miljön och flytt tar 3–10 dagar, migreringen kör vi parallellt och DNS lägger vi om i ett planerat fönster, och därefter har du en ansvarig kontaktperson, inte ett supportärende i en annan tidszon.

Den andra sidan ska också sägas ärligt, för utan den skulle det här avsnittet vara en prislista med en artikel runt. Om din webbplats är statisk, besöket litet och ingen någonsin begär en PHP-version som leverantören inte har, då är webbhotell för några euro i månaden rätt svar, och en miljö med managed hosting skulle vara en avgift för sinnesro du redan har. Vi säger det också till dem som ringer med den frågan, för att sälja en miljö som inte används är en kortsiktig affär — efter ett år kommer den tillbaka som frågan vad man egentligen betalade för, och på den finns det inget bra svar.

Om du inte är säker på vilken sida om den här gränsen din webbplats ligger kan de fyra siffrorna läsas av tillsammans: skriv till oss, så säger vi vad statistiken i ditt nuvarande konto visar och vilken gräns som ligger närmast — också när svaret visar sig vara att det inte finns någon anledning att flytta och att pengarna hellre ska gå till webbplatsens hastighet.