Hva er en skyserver: webhotell, VPS og hva nettstedet faktisk trenger

Webhotell, VPS og skyserver ser i prislisten ut som tre ytelsesnivåer, men skiller seg på tre punkter: hva som skiller deg fra naboene på samme maskin, hvor kontoen tar stopp, og hvem som oppdaterer programvaren.

En onsdagsmorgen rundt ti blir nettstedet tregt — ikke dødt, bare tregt: siden åpner på fem sekunder, administrasjonspanelet nekter å lagre et innlegg, og etter en halvtime er alt som vanlig igjen, som om ingenting har skjedd. Leverandørens brukerstøtte svarer etter lunsj at kontoen har overskredet planens grenser, og tilbyr et bytte til neste nivå, som koster tre ganger mer og i prislisten heter «skyserver».

Hva er en skyserver — og hva de to andre er — kan du ikke lese ut av navnet på raden. I det øyeblikket vet de fleste kjøpere ikke hva de egentlig kjøper, og det er ingen bebreidelse: webhotell, VPS og skyserver er i prislisten satt under hverandre som tre ytelsesnivåer for én og samme tjeneste, selv om de er tre ulike tekniske løsninger som skiller seg på tre konkrete punkter, og hvert av dem kan du kontrollere med nettstedets egne tall i hånden.

Tre steder der planene faktisk skiller seg

Det første er isolasjonen, det vil si hva som faktisk skiller nettstedet ditt fra de andre kundenes nettsteder på den samme fysiske maskinen. På et webhotell er det en konto i operativsystemet sammen med en ressurscontainer som ligger i kjernen, på en VPS er det en egen virtuell maskin med eget operativsystem, og på en skyserver er det den samme virtuelle maskinen, bare bestilt og betalt på en annen måte. Den praktiske forskjellen mellom de tre variantene ligger i hvor mye en nabos last kan påvirke nettstedet ditt, og i hvor mye av maskinen du i det hele tatt får lov til å endre når det viser seg at standardoppsettet ikke passer.

Det andre stedet er grensen, det vil si hvor kontoen tar stopp og hvordan det tar seg ut, og det er nettopp her de fleste misforståelsene oppstår, fordi folk venter at overbelastning betyr en treg side, selv om det i en del tilfeller betyr en side som ikke åpner i det hele tatt og som returnerer en feilkode kjøperen aldri har sett. Det tredje stedet er ansvaret, det vil si hvem som oppdaterer operativsystemet, hvem webserveren, hvem PHP og hvem selve nettstedet, og det er her VPS-kjøpere tar feil oftest, for root-tilgang er ingen gave leverandøren gir deg sammen med en kraftigere maskin — det er en overlevering av en pliktliste fra dem til deg, og den skjer stille, i det samme minuttet passordet sendes.

Alt det andre som tar rader i en sammenligningstabell for hosting, er enten likt i alle planer, eller det er ikke det som gir etter: NVMe-disker finnes i dag praktisk talt overalt, men «ubegrenset datatrafikk» er en påstand om overført datamengde, ikke om ressurser, og det står vanligvis rett ved siden av tabellen der ressursene er talt opp til siste megabyte. 99,9 % er derimot et tall med presis juridisk betydning og med en unntaksliste under seg, og de fleste kjøpere tror at det dekker noe helt annet enn det det faktisk dekker.

Webhotell: én server, mange kontoer

Et webhotell er en brukerkonto på en maskin der det bor ytterligere hundrevis av like kontoer, og norske leverandører selger det samme produktet under nettopp det ordet — webhotell — mens sammenligningstekstene kaller modellen delt hosting. Teknisk betyr det i begge tilfeller den samme avtalen: du eier en konto, ikke maskinen, nettstedet styrer du gjennom cPanel eller et tilsvarende panel, og alt som ligger under det panelet, tilhører noen andre.

Det som skiller deg fra naboene, er konkret programvare, ikke et løfte i prislisten, og den programvaren er verdt å kjenne ved navn. De fleste cPanel-leverandørene kjører CloudLinux, der hver konto har sin egen kopi av filsystemet: i dokumentasjonen om CageFS skriver CloudLinux at brukerne verken kan se eller oppdage andre brukere og brukernavnene deres på serveren, ikke kan lese webserverens konfigurasjon og bare ser en avkortet prosessliste. Det andre laget er LVE — en ressurscontainer på kjernenivå som setter grenser for prosessor, minne, I/O og prosesser for hver konto, nettopp for at, som dokumentasjonen selv formulerer det, ingen enkelt nettsted skal kunne ta ned hele webserveren.

Det tredje laget er PHP-innstillingen open_basedir, og der er det verdt å vite hva PHP-håndboken selv sier, ikke hva leverandørens markedsføring sier: det er et ekstra sikkerhetsnett som på ingen måte er dekkende, og som man ikke kan stole på når sikkerheten virkelig trengs. På samme sted advarer håndboken om at også avstenging av funksjoner med disable_functions kan omgås, og at det i et delt miljø ikke er et tilstrekkelig sikkerhetstiltak. Ingenting av dette er et argument mot webhotell; det er et argument for at isolasjonen her kommer fra kjernen og filsystemet, ikke fra én linje i en konfigurasjonsfil, og at en leverandør som på spørsmål om isolasjon svarer med ordet «trygt», ikke har svart på det.

Det du ikke kan velge på et webhotell, er like viktig som det du kan: kjernen er én og den samme for alle kontoer, så kjerneversjonen bytter du ikke, listen over PHP-versjoner bestemmes av leverandøren og ligger vanligvis én eller to etter den nyeste, og webserveren er den som er installert, så på spørsmål om en pakke som ikke finnes der blir svaret «nei», ikke «installer den». En delt server er også stedet der leverandøren ved en hendelse må kontrollere nabokontoene, fordi en angriper som har kommet inn i én konto, prøver det samme hos naboene; hva du gjør når det allerede har skjedd, har vi beskrevet i artikkelen om et hacket WordPress-nettsted. Ingen av disse grensene er en mangel: det er nøyaktig den avtalen som gjør produktet billig, og kjøperen som forstår den, har nytte av den.

Hva som skjer når kontoen treffer grensen sin

En webhotellplan har flere ulike stopp, de nås uavhengig av hverandre og tar seg helt forskjellig ut, så symptomet er et nyttig diagnoseverktøy. De standardgrensene CloudLinux setter for én konto er 100 % av én prosessorkjerne, 1 GB fysisk minne, 1024 KB/s I/O, hundre prosesser og tjue entry processes, og det er nettopp det siste tallet som overrasker kjøpere, fordi tjue høres latterlig lite ut for et nettsted som tar imot ti tusen besøkende i måneden.

Forklaringen er at en entry process ikke er en besøkende: det er en prosess som kommer inn i kontoen utenfra — en ny HTTP-forespørsel til et PHP-skript, en SSH-økt eller en cron-jobb — mens prosesser som allerede oppstår inni, teller mot en helt annen grense. Når antallet entry processes er nådd, slipper ikke Apache-modulen inn neste forespørsel, men svarer med feilen 508 Resource Limit Reached, og CloudLinux beskriver det uten omsvøp i kunnskapsbasen: nettstedet som bruker for mye ressurser, slutter å virke, men de øvrige kundene på samme server fortsetter som vanlig. Det er nøyaktig poenget med mekanismen — å kutte av én konto slik at maskinen ikke stopper.

De øvrige grensene tar seg annerledes ut, og av symptomet kan du lese av hvilken som er nådd, før noen begynner å gjette: prosessor og I/O kuttes ikke av, de strupes, så siden blir treg og åpner til slutt, mens minne- og prosessgrenser vanligvis gir 500 eller 503, altså en side som ikke åpner i det hele tatt. På LiteSpeed-servere telles entry processes annerledes enn på Apache, så der må det samme tallet ikke oversettes til antallet samtidige besøkende, og det er en av de vanligste måtene et riktig tall havner i en gal setning.

Det finnes enda et fjerde stopp, som ikke har med last å gjøre i det hele tatt og derfor dukker opp uventet: en inode er filsystemets post om én fil eller én mappe, så antallet inoder i kontoen rett og slett er antallet filer og mapper, inkludert e-postkassen ingen har ryddet i årevis. Vertsleverandøren Hostnet publiserer inode-tallet åpent i prislisten — 400 000 i MINI, 600 000 i PLUS, 800 000 i PRO — og i den samme tabellen står MINI og PLUS med 100 % av én kjerne og 2048 MB minne, men PRO med 200 % og 3072 MB, og alle tre med 10 MB/s I/O og 150 samtidige tilkoblinger, mens månedens datatrafikk er «ubegrenset». Den kombinasjonen er den egentlige lærepengen om ordet «ubegrenset» i en hostingprisliste: det gjelder overført datamengde, og alle de øvrige grensene står like ved siden av, talt opp til siste siffer.

VPS: eget operativsystem på delt maskinvare

En VPS er en virtuell maskin der du eier operativsystemet, root-tilgangen og muligheten til å installere det som trengs, og på det norske markedet skrives det med den engelske forkortelsen: VPS, utskrevet virtuell privat server. Det navnet ikke sier, er to tekniske spørsmål som avgjør hvor mye av «din egen server» som faktisk er din.

Det første spørsmålet er om virtualiseringen ligger på maskinvare- eller operativsystemnivå. KVM er en modul i Linux-kjernen som bruker prosessorens virtualiseringsutvidelser og gir hver gjest sin egen virtualiserte maskinvare — nettverkskort, disk, skjermadapter — og framfor alt sin egen kjerne, så der kan du også kjøre uendret Windows. LXC og beslektede containere er en annen mekanisme: de bruker Linux-navnerom, cgroups og rettighetsbegrensning for å lage et miljø som ligger så nær en separat Linux-installasjon som mulig, men uten en separat kjerne. Følgen er enkel og praktisk — i containeren forblir kjerneversjon, kjernemoduler og kjernesårbarheter felles med vertsmaskinen, så en del av det du trodde du kjøpte, ble faktisk igjen hos naboene.

Det andre spørsmålet gjelder prosessoren, for ordene «egen server» betyr ikke egen prosessor. Hetzner har to atskilte produktlinjer for skyservere: i planer med delte ressurser fordeles regnekraften mellom alle instansene på den samme fysiske serveren, med en grunnytelse og mulighet til å overskride den en tid, mens i planer med dedikerte ressurser er én vCPU én tråd på en fysisk kjerne og bare din. DigitalOcean formulerer det enda tydeligere: i en plan med delte ressurser kan tråden deles med andre, og hvis naboene har høy last, får instansen deler av tråden, ikke full tilgang, så full tilgang er mulig i praksis, men ikke garantert.

Hvor mange naboer som sitter på samme maskin, publiserer ingen av de store leverandørene, og forholdstallet du finner i blogger, er ikke noens publiserte måling, så det er verken verdt å sitere eller å tro på. Den eneste dokumenterte størrelsen du kan vise til, er om planen lover delte eller atskilte ressurser, og den forskjellen står vanligvis helt åpent — med to ulike produktnavn, to ulike spesifikasjoner og en prisforskjell på flere ganger.

Hva er en skyserver: samme VPS, kjøpt på en annen måte

En skyserver er teknisk sett en virtuell maskin på en hypervisor, altså nøyaktig det samme som en VPS, og Hetzner innleder dokumentasjonen med den samme setningen: skyservere er virtuelle maskiner som kjører på fysiske servere. Hvis du av to tilbud venter deg to ulike maskiner, er det ikke grunnlag for den forventningen.

Forskjellen ligger ikke i maskinvaren, men i måten den kjøpes på, og det beskrives mest presist av definisjonen fra den amerikanske standardiseringsmyndigheten NIST, som bransjen fortsatt siterer: skyen har fem kjennetegn — selvbetjening ved behov, tilgang via nettet, sammenslåing av ressurser med flere leietakere, rask elastisitet og målt forbruk. I praksis betyr det et API som kan opprette og rive maskinen programmatisk, timefakturering med et tak per måned og tilleggsdeler som kan kobles på separat: snapshots, separat blokklagring, en flyttbar IP-adresse og en lastbalanserer.

Hver av disse delene har grenser det er verdt å kjenne før kjøpet, ikke en måned etter. Et bytte av Hetzner-plan kan ikke redusere diskens størrelse selv når bare en del av den er i bruk; etter en utvidelse må du selv utvide partisjonen i redningsmodus, og selve planbyttet står oppført som unntak fra tilgjengelighetsgarantien. Et snapshot er derimot ikke en sikkerhetskopi, selv om markedet bruker de to ordene som synonymer: Hetzner-snapshots omfatter ikke tilknyttede volumer, og konsistens garanteres ikke hvis serveren kjører, så det er en god ting før en oppdatering og en dårlig ting som eneste datakopi. Den flyttbare IPv4-adressen koster ekstra, akkurat som den primære IPv4-adressen på selve instansen.

Et bedriftsnettsted på fem sider bruker vanligvis ingen av disse delene, og det er den ærligste setningen i dette avsnittet: hvis nettstedet aldri endrer kapasitet, aldri slår over på en annen maskin og aldri kobles til et API, da er skyserveren og en VPS av samme størrelse én og samme maskin med to ulike regninger. Det er ikke et argument mot skyen, for der elastisiteten faktisk brukes, koster den mindre enn en reserve som holdes hele tiden. Det er et argument for at valget står mellom muligheter du virkelig kommer til å bruke, ikke mellom ord som høres moderne ut.

Hvem som oppdaterer hva

Den største praktiske forskjellen mellom de tre planene er ikke farten, men fordelingen av plikter, og tydeligst har den blitt formulert av skyleverandørene selv. AWS-modellen for delt ansvar deler alt i to: sikkerheten for skyen er AWS sitt ansvar — maskinvare, programvare, nett og lokalene tjenestene kjører i — mens sikkerheten i skyen er kundens ansvar. I spørsmålet om oppdateringer står det til og med skrevet separat og ord for ord: AWS har ansvaret for infrastrukturens oppdateringer og feil, men kunden har ansvaret for oppdateringene i gjestens operativsystem og i egne applikasjoner.

På et webhotell tilhører det laget leverandøren, og det er produktets største verdi, som sjelden noen tenker på: kjernen, webserveren og PHP oppdaterer de, og du vet ingenting om det før noe går i stykker. På en VPS eller skyserver uten administrert serverdrift gikk alt over til deg sammen med root-passordet, og Hetzner sier det også fra den andre siden i vilkårene: programvare, konfigurasjon og systeminnstillinger kunden innfører, telles ikke som et brudd på tilgjengeligheten, altså har ikke leverandøren ansvaret for dem og de inngår ikke i noen kompensasjon.

Selve nettstedet forblir ditt ansvar i alle tre tilfellene, og det er det punktet der tilbudene må leses nøye, for ordet «administrert» betyr i bransjen vanligvis operativsystem og serverprogramvare, ikke WordPress-kjernen, utvidelsene og temaet. Også i vår egen drift av infrastruktur inngår oppdateringer av operativsystem og serverprogramvare, sikkerhetskonfigurasjon, sikkerhetskopier med testet gjenoppretting, overvåking og reaksjon etter SLA — og der står det ikke skrevet at vi oppdaterer utvidelsene dine, for det er en annen rad i prislisten og en annen avtale, og vi sier det tydelig slik at ingen skal oppdage den grensen på hendelsesdagen.

Den praktiske testen før bestillingen er ett spørsmål, stilt rett fram og i tre deler: hvem oppdaterer operativsystemet, hvem webserveren og PHP, og hvem nettstedets kode. Hvis svaret på noen av de tre er «du selv», da er det arbeid som krever enten et menneske med tid eller en avtale med noen andre, og ingen av delene er gratis. Ubesvart forsvinner ikke spørsmålet — det kommer tilbake etter atten måneder som et system der ingen har lagt inn en eneste oppdatering, og da er det ikke lenger et spørsmål om valg av plan.

Hva 99,9 % betyr, og hva tallet ikke dekker

Tilgjengelighetsprosenten i prislisten ser ut som et løfte, men er i virkeligheten en formel med en unntaksliste. Hetzners tjenestenivåavtale for skyservere lover 99,9 % i måneden for én instans, og Hetzner selv regner i forklaringen ut hva tallet betyr i praksis: i en måned på tretti dager ligger 43 minutter nedetid fortsatt innenfor avtalens ramme, det vil si at det ikke er et brudd og at det ikke utløser noen kompensasjon.

Selve kompensasjonen er like konkret og mye mindre enn folk venter: den regnes ut fra minuttene over terskelen, omregnet til timer og multiplisert med instansens timesats, og utbetales som kreditt mot framtidig forbruk, ikke som penger. I Hetzners eget eksempel gir 185 minutters nedetid 142 minutter over terskelen, altså 2,37 timer, og en kreditt på 0,87 €, som er mindre enn én times arbeid med å regne det ut. Tapt omsetning, tapte ordrer og svekket rangering i søkeresultatene inngår ikke noe sted der, og ingen hostingavtale vi har lest, dekker dem.

Unntakslisten er like viktig som tallet, for det er den som avgjør hvor ofte tallet i det hele tatt anvendes: utenfor avtalen ligger forhåndsvarslet vedlikehold, kundens egen programvare og konfigurasjon, planbytte kunden har bedt om, live-migreringer av hensyn til vertsmaskinens stabilitet, og nettet utenfor leverandørens kjernenett. Alt det står skrevet ærlig og åpent, og av det følger en enkel slutning: prosenten gjelder maskinen, ikke nettstedet ditt, så et nettsted som falt etter en mislykket oppdatering, ligger helt utenfor denne avtalen.

I tillegg er 99,9 % ingen bransjekonstant, selv om den ofte brukes som om den var det. Amazons EC2-avtale for én instans lover 99,5 %, men 99,99 % bare hvis instansene er plassert i minst to tilgjengelighetssoner, det vil si at det er to ulike avtaler med to ulike tall, og setningen «i bransjen er 99,9 %» flater ut begge til ett. På webhotell finnes et slikt dokument vanligvis ikke i det hele tatt — bare et tall på nettstedet uten definisjon, uten målemetode og uten følger, og det er en påstand, ikke en forpliktelse.

Slik måler du nettstedet ditt før du velger

Tallet som avgjør, er ikke antallet besøkende i måneden, selv om det er nøyaktig det kjøperen kan utenat og nøyaktig det selgeren spør om først. Det som avgjør, er antallet samtidige PHP-forespørsler i det øyeblikket lasten er størst, og det er en helt annen størrelse, som korrelerer svakt med månedens besøk.

To nettsteder med like mange besøk kan ligge på hver sin side av én og samme grense, og forskjellen ligger i hvor lenge hver side holder en prosess. Et statisk bedriftsnettsted med hurtigbuffer betjenes for det meste av webserveren uten PHP, så det bruker nesten ingen entry processes, og ti tusen besøkende i måneden betyr ingenting for det. En nettbutikk der hver handlekurv, hver innlogging og hver retur fra betalingsløsningen holder en PHP-prosess i to sekunder, kan nå den samme grensen allerede ved tjue samtidige kjøpere, og det er derfor det i kampanjens første time nettopp er de butikkene som har betalt for kampanjen, som faller.

Sammen med det tallet er det verdt å lese av ytterligere tre, og alle tre får du fram uten hjelp fra en utvikler. Det første er databasens størrelse og den tregeste spørringen i den, for det er vanligvis den som er den egentlige årsaken til treghet, ikke maskinens kraft. Det andre er antallet filer i kontoen, for inode-grensen nås uventet og uten varsel av nettsteder med store mediebiblioteker og med en gammel e-postkasse. Det tredje er det nettstedet gjør utenfor nettleseren — cron-jobber, utsending av e-post, integrasjoner mot regnskapssystemet — for disse prosessene kommer også inn i kontoen utenfra og teller mot den samme grensen som du nettopp målte for kjøperne.

Alle fire tallene kan leses av på én ettermiddag fra statistikken i hostingpanelet og fra serverloggene, og det er det eneste stedet der nettstedets virkelige last finnes, ikke en anelse om den. Planens navn kjenner ikke de tallene, selgeren som ikke har sett dem, kjenner dem heller ikke, og en samtale som begynner med dem, ender vanligvis med et billigere svar enn en samtale som begynner med en liste over planer.

Når byttet hjelper, og når det ikke løser noe

Et bytte til en større plan er det riktige svaret atskillig sjeldnere enn det tilbys, og det første tilfellet der det ikke hjelper, er også det vanligste. Hvis nettstedet er tregt fordi én spørring leser hele produkttabellen ved hver sideåpning, vil en kraftigere maskin kjøre den fortere, problemet blir værende, og du har kjøpt tid, ikke en løsning. Det samme gjelder førti utvidelser, ubehandlede bilder i originalstørrelse og et tema som ved hver forespørsel bygger menyen fra bunnen av.

Byttet er det riktige svaret når grensen er nådd med korrekt kode: hvis nettstedet bruker hurtigbuffer, spørringene er i orden og kontoen likevel treffer antallet entry processes, da er det planens grense, ikke en feil i koden, og det er ikke mer å optimalisere. På samme måte er byttet det eneste svaret når du trenger noe som ikke kan installeres på en delt konto — en annen PHP-versjon, en købehandler, Redis, en egen cron med minuttintervall — eller når et bransje-, anskaffelses- eller kundekrav angir i hvilket land dataene fysisk skal ligge.

Det finnes også et tredje tilfelle, som selgere sjelden snakker om, fordi det senker regningen: noen ganger er den riktige bevegelsen nedover. Et nettsted som for tre år siden ble flyttet til en VPS på grunn av én reklamekampanje, og som siden den gang tar imot to hundre besøkende om dagen, betaler for en maskin det ikke bruker, og det betaler dobbelt — med penger på regningen og med et menneskes tid, for VPS-ens operativsystem må noen oppdatere også når ingen går inn der.

Før hver flytting er det verdt å løse enda ett spørsmål som ikke har med kapasitet å gjøre i det hele tatt: på hvem sitt navn domenet er registrert, og på hvem sitt navn hostingkontoen står. Om det har vi skrevet separat i artikkelen om feil når du skal bestille nettside, og dette er ett av de spørsmålene som på flyttedagen ikke lenger lar seg reparere raskt, fordi svaret avhenger av et menneske du kanskje ikke lenger snakker med.

Hva du kjøper når planen kalles administrert serverdrift

Prisforskjellen mellom en maskin uten administrert serverdrift og en med er stor, og den er ikke et påslag for den samme varen, så begge tallene fortjener å legges ved siden av hverandre. I Hetzners prisliste, som trådte i kraft 15. juni 2026, koster skyserveren CX23 med to vCPU, fire gigabyte minne og 40 GB disk 5,49 € i måneden uten MVA, og den primære IPv4-adressen kommer i tillegg for 0,50 € i måneden. Vår administrerte serverdrift begynner på 45 € i måneden, og forskjellen mellom de to tallene er nøyaktig det denne seksjonen handler om.

Forskjellen er arbeid, og det kan telles opp én ting om gangen: oppdateringer av operativsystem og serverprogramvare, sikkerhetskonfigurasjon, overvåking med Zabbix døgnet rundt og reaksjon etter SLA, sikkerhetskopier hver dag med 30 dagers lagringstid og jevnlig testet gjenoppretting, og for særlig kritisk infrastruktur — inntil 365 dager og i to ulike land i Den europeiske union. Klargjøring av miljøet og flytting tar 3–10 dager, migreringen kjører vi parallelt og DNS slår vi om i et planlagt vindu, og deretter har du én ansvarlig kontakt, ikke en sak hos brukerstøtten i en annen tidssone.

Den andre siden skal også sies ærlig, for uten den ville denne seksjonen vært en prisliste med en artikkel rundt. Hvis nettstedet ditt er statisk, besøket lite og ingen noensinne ber om en PHP-versjon leverandøren ikke har, da er webhotell for noen euro i måneden det riktige svaret, og et administrert miljø ville vært betaling for sinnsro du allerede har. Vi sier det også til dem som ringer med det spørsmålet, for å selge et miljø som ikke brukes, er en kortsiktig handel — etter et år kommer den tilbake som spørsmålet om hva man egentlig betalte for, og på det finnes det ikke noe godt svar.

Hvis du ikke er sikker på hvilken side av denne grensen nettstedet ditt ligger på, kan de fire tallene leses av sammen: skriv til oss, så sier vi hva statistikken i den nåværende kontoen din viser, og hvilken grense som ligger nærmest — også når svaret viser seg å være at det ikke er noen grunn til å flytte, og at pengene heller bør gå til nettstedets fart.