Hostginger säljer sin Laravel VPS som en förinstallerad, AI-hanterad server byggd för att få ett Laravel-projekt live snabbt. Det mesta av det löftet stämde vid verkliga tester, starka benchmarkresultat, en kapabel AI-supportagent, och säkerhetskopior som bekräftades köras enligt schema.

En knapp på instrumentpanelen skickade mig dock någonstans jag aldrig förväntade mig att hamna, och det är värt att känna till innan du klickar på den själv. Här är hela genomgången.

Hostinger Laravel VPS Hosting

Upptäck hur Hostinger Laravel VPS Hosting erbjuder en flexibel miljö för driftsättning av Laravel-applikationer med dedikerade serverresurser, full kontroll, skalbar prestanda och anpassningsbara konfigurationer för moderna webbprojekt.

Besök Hostinger

För- och nackdelar

Betygsfördelning

För att sätta poäng på Hostingers Laravel VPS-hosting tillämpade jag HostAdvices betygsmetodik, samma standardiserade metod som används i varje recension på sajten, så att poängen förblir konsekventa och grundade i verkliga tester snarare än marknadsföringspåståenden. Här är hur den bedömdes inom varje parameter.

Hostinger Laravel VPS Hosting

Upptäck hur Hostinger Laravel VPS Hosting erbjuder en flexibel miljö för driftsättning av Laravel-applikationer med dedikerade serverresurser, full kontroll, skalbar prestanda och anpassningsbara konfigurationer för moderna webbprojekt.

Besök Hostinger

Planer och priser

Hostinger säljer Laravel-hosting som en av fyra KVM VPS-nivåer, KVM 1 till KVM 8, där CPU-kärnor, RAM, NVMe-diskutrymme och bandbredd skalas upp tillsammans när du går högre upp.

Laravel i sig är inte ett separat köp, det är en app med ett klick som läggs ovanpå vilken nivå du än väljer vid checkout, med Cloudpanel inkluderat som själva kontrollpanelen för att hantera installationen när den väl är live.

Några saker värda att känna till innan du beställer:

• Faktureringsvillkor: Planerna betalas i förskott för 1, 12 eller 24 månader, och de längre villkoren ger verkliga rabatter på månadspriset. Se prissättningswidgeten nedan för fullständig uppdelning per nivå och period.
• Pengarna-tillbaka-garanti: VPS-planer har en 30-dagars garanti, men det finstilta lägger till en verklig begränsning. Du kan bara kräva återbetalning för en VPS en gång var 180:e dag, så en andra återbetalning för ett separat VPS-köp inom det fönstret kommer inte att gå igenom. Uppgraderingar av en befintlig VPS-plan är helt undantagna.
• Gratis provperiod: Jag hittade ingen särskild gratis provperiod för Laravel VPS-hosting, bara 30-dagars pengarna-tillbaka-garantin. Planera din utvärderingstid med den begränsningen i åtanke.
• Betalningsmetoder: Kort (Visa, Mastercard, Amex, Discover), PayPal, Google Pay, AliPay i separata Kina- och Hongkong-varianter, samt Coingate för krypto. Kryptobetalningar omfattas inte alls av återbetalningspolicyn, så tänk på det om garantin är viktig för dig.
• Det som ingår: Varje nivå inkluderar en gratis .cloud-domän för det första året, full root-åtkomst, Git-integration och Cloudpanel utan extra kostnad, så listpriset ligger närmare den verkliga kostnaden än hos hostingleverantörer som tar betalt separat för en kontrollpanel.

Hostingers egen vägledning föreslår att KVM 1 räcker för en enkel Laravel-sajt, medan KVM 8 rekommenderas för tyngre, resursintensiva projekt.

Värt att lägga till utifrån testningen är att förvirringen kring apphanteringsknappen Manage App och malware-scannern som är avstängd som standard gäller alla nivåer lika mycket, så att välja högre nivå löser inte något av det. Välj din plan utifrån CPU- och trafikbehov, och hantera dessa två specifika problem på samma sätt oavsett vilken nivå du hamnar på.

Funktioner

• AMD EPYC-processorer på alla nivåer
• NVMe SSD-lagring på alla planer
• Git-integration för smidigare koddriftsättning
• Full root-åtkomst via SSH
• Cloudpanel-kontrollpanel inkluderad som standard
• AI-agent för VPS-hanteringsuppgifter
• Automatiska veckovisa säkerhetskopior på varje plan
• 1 Gbps nätverkshastighet per plan
• Gratis .cloud-domän i ett år

Hostinger Laravel VPS Hosting

Upptäck hur Hostinger Laravel VPS Hosting erbjuder en flexibel miljö för driftsättning av Laravel-applikationer med dedikerade serverresurser, full kontroll, skalbar prestanda och anpassningsbara konfigurationer för moderna webbprojekt.

Besök Hostinger

Prestanda

En Laravel-applikation lever eller dör på servern under den lika mycket som på koden själv. Sidladdningar beror på CPU-hastighet för att exekvera PHP, databasfrågor beror på disk-I/O, sessioner och cache beror på minne, och om appen kör köjobb eller har riktiga besökare spelar nätverksgenomströmning och uthållig belastningshantering också roll.

Laravel i sig förändrar inget av det, det är fortfarande PHP som körs på Linux, så det verkliga testet här är VPS:en.

Jag körde en fullständig benchmarksvit mot servern, som täckte CPU, minne, disk, nätverk och ett uthålligt stresstest, för att se vad den här planen faktiskt levererar och vad det innebär för en verklig applikation.

Instansen jag testade var KVM 2-planen, den jag valde vid checkout:

• CPU: 2 vCPU:er, utskurna från en värd som kör en AMD EPYC 9354P-processor
• RAM: 7.8GB användbart av de 8GB som tilldelats, plus 2GB swap
• Disk: 96GB användbart av 100GB NVMe-allokeringen
• OS: Ubuntu 24.04.4 LTS, kernel 6.8.0-137-generic

Innan vi går in på siffrorna är det bra att veta att Hostingers Laravel VPS-utbud kör samma fyra nivåer som resten av VPS-utbudet, KVM 1 till KVM 8, och KVM 2 ligger näst längst ned, ett steg upp från det billigaste alternativet och långt under KVM 4- och KVM 8-nivåerna som är byggda för tyngre arbetslaster med flera applikationer.

Det som följer speglar ett litet till medelstort Laravel-projekt, en enda applikation som serverar en verklig men måttlig mängd trafik, inte en stor plattform som kör flera tjänster på samma maskin.

1. CPU-prestanda

• Single-thread: 1,624.55 events per second, genomsnittlig latens 0.61ms, 95:e percentilen 0.64ms

• Multi-thread, 2 threads: 2,864.02 events per second, genomsnittlig latens 0.70ms, 95:e percentilen 1.10ms

• Thread fairness standard deviation: 182.50 på ett genomsnitt av 14,321.5 events per tråd

Här är vad den där single-thread-siffran faktiskt betyder i praktiken. En typisk Laravel-begäran, som renderar en Blade-vy, kör ett fåtal Eloquent-frågor, kontrollerar en session, spenderar det mesta av sin tid på en CPU-kärna som gör PHP-arbete snarare än att sprida sig över flera kärnor samtidigt.

Vid 0.61ms genomsnittlig latens per beräkningshändelse i det här testet är det inte CPU:n som kommer att få en sida att kännas långsam.

Gapet mellan genomsnittlig latens och 95:e percentilen är också litet, 0.61ms mot 0.64ms, vilket betyder att prestandan förblev konsekvent snarare än att enstaka begäranden tog mycket längre tid än resten, ett mönster som skulle märkas som slumpmässiga långsamma sidladdningar för riktiga besökare.

Multi-thread-resultatet är den mer användbara siffran för att förstå samtidighet. Att gå från en tråd till två nästan fördubblade genomströmningen, ungefär 88 procent skalningseffektivitet, vilket innebär att denna VPS inte förlorar mycket kapacitet till overhead eller till andra hyresgäster som konkurrerar om samma fysiska kärnor

I praktiken betyder det att PHP-FPM som kör med två worker-processer på denna plan kan hantera ungefär dubbelt så många begäranden som i ett single-thread-scenario innan CPU:n blir flaskhalsen, snarare än något som är mindre än dubbelt, vilket är vad du skulle se om de två vCPU:erna kämpade med varandra om cyklerna.

Thread fairness-siffran, ungefär 1.3 procent variation mellan de två trådarna, bekräftar att båda kärnorna gjorde ungefär lika mycket av arbetet i stället för att en kärna bar belastningen medan den andra stod still. För en verklig sajt betyder det att begäranden fördelas jämnt över PHP-FPM-arbetare i stället för att byggas upp bakom den worker som råkar vara upptagen.

2. Minneshastighet

• Sequential Write: 5,865.22 MiB/sec

• Sequential Read: 7,155.43 MiB/sec

Minneshastighet spelar roll för Laravel på ett sätt som är lätt att förbise. Varje OPcache-uppslag, varje sessionsläsning, varje array eller collection som din applikation bygger medan den hanterar en begäran ligger i RAM, och om ett cachelager som Redis också körs på samma maskin konkurrerar det om samma minnesbandbredd.

Med ungefär 5.9 GiB per sekund skrivning och 7.2 GiB per sekund läsning kan denna VPS flytta data in och ut ur minnet tillräckligt snabbt för att minnesoperationer mycket osannolikt är det som saktar ner en begäran, flaskhalsen för en typisk Laravel-app kommer nästan alltid att vara disk eller nätverk innan det är RAM-hastighet.

Där minne mer direkt spelar roll är kapacitet snarare än hastighet. Med 7.8GB användbart och 2GB swap bakom det kan denna plan bekvämt köra PHP-FPM, MySQL eller PostgreSQL och en liten Redis-instans sida vid sida för en enda applikation, men den lämnar inte mycket utrymme om du kör flera sajter på samma VPS eller en databas med en stor arbetsmängd i minnet.

Swappen är en säkerhetsnätsfunktion för en kort minnestopp, inte en ersättning för RAM om applikationen verkligen är för liten för den här planen.

3. Disk-I/O

• Sequential Write: 740 MiB/s (776 MB/s), 740 IOPS

• Sequential Read: 749 MiB/s (785 MB/s), 748 IOPS

• Random 4K mixed read/write: ungefär 9,400 IOPS i vardera riktningen, cirka 36.7 MiB/s genomströmning per riktning

Sekventiell hastighet är den siffra som spelar roll för stora engångsoperationer, återställa en databassäkerhetskopia, packa upp ett uppladdat arkiv, skriva en stor loggfil.

Vid omkring 740 till 750 MiB/s i båda riktningarna, och med läsning och skrivning inom två procent från varandra, har den här disken inte den sneda svagheten i ena riktningen som man ser på en del molnlagring, där läsningar är snabba men skrivningar släpar efter mycket.

Slumpmässig 4K-prestanda är den siffra som faktiskt förutsäger hur en Laravel-app kommer att kännas i daglig användning, eftersom en databas inte läser och skriver i stora sekventiella block, den läser och skriver små, utspridda block över disken när den slår upp rader, uppdaterar index och skriver till sin transaktionslogg.

Strax över 9,000 IOPS i varje riktning motsvarar ungefär 9,000 små databasoperationer per sekund innan disk-I/O blir den begränsande faktorn.

En typisk Laravel-sidladdning kan utlösa någonstans mellan några få och några dussin frågor beroende på hur appen är byggd, vilket betyder att den här disken har utrymme för ett betydande antal samtidiga användare som träffar databasen på samma gång innan frågorna börjar köa och vänta på diskåtkomst.

Det skulle krävas en tydligt skrivtung arbetslast, högvolymsloggning, en upptagen kötabell, frekventa cache-skrivningar till disk, för att pressa denna specifika gräns.

4. Nätverkshastighet

• Run 1: Download 990.06 Mbps, Upload 910.87 Mbps, idle latency 0.31ms, 0% packet loss

• Run 2: Download 985.24 Mbps, Upload 947.82 Mbps, idle latency 0.27ms, 0% packet loss

Båda körningarna landade mot en server i Phoenix, Arizona, vilket matchar USA-platsen jag valde vid checkout, nära ett fullt gigabit i båda riktningar med noll paketförlust i båda försöken.

För en Laravel-app spelar den här siffran störst roll för två saker, hur snabbt servern kan leverera tillgångar och API-svar till besökare, och om appen anropar externa API:er eller hämtar data från andra tjänster, hur snabbt de utgående anropen slutförs.

Nästan gigabitgenomströmning betyder att bandbredd inte kommer att vara begränsningen för en typisk webbapplikation, du skulle behöva en mycket hög volym av stora filöverföringar, video, stora nedladdningar, mass-exporter, innan detta blir den begränsande faktorn i stället för CPU eller disk.

De nästan identiska resultaten över två separata körningar, tagna med några minuters mellanrum, utesluter också ett lyckat enstaka resultat, det här är hur anslutningen faktiskt beter sig konsekvent snarare än ett tal som råkade toppa en gång.

5. Stresstest

Jag körde CPU-, minnes- och diskstressorer i 180 sekunder vardera för att se hur servern klarar långvarig belastning snarare än en snabb topp:

• CPU stress, 2 workers: 540,042 bogo ops, 0 failures

• Memory stress, 2 workers: 24,335,966 bogo ops, 0 failures

• Disk stress, 2 workers: 2,655,058 bogo ops, 0 failures

De enskilda bogo ops-siffrorna betyder mindre här än vad som inte hände.

Noll misslyckade workers och noll opålitliga mätvärden i alla tre tester, körda direkt efter varandra i tre hela minuter vardera, betyder att servern höll CPU, minne och disk under samtidigt tryck utan att krascha, strypas in i ett opålitligt tillstånd eller returnera resultat som själva benchmarken flaggade som misstänkta. Det är det närmaste den här typen av test kommer att simulera en verklig trafikspik, flera resurser maxade

t samtidigt, och det är resultatet som betyder mest för alla som oroar sig för att deras sajt ska falla över under en hektisk period snarare än prestera bra bara i isolerade tester en åt gången.

Slutlig bedömning av prestanda

Hostinger Laravel VPS Hosting

Upptäck hur Hostinger Laravel VPS Hosting erbjuder en flexibel miljö för driftsättning av Laravel-applikationer med dedikerade serverresurser, full kontroll, skalbar prestanda och anpassningsbara konfigurationer för moderna webbprojekt.

Besök Hostinger

Användarvänlighet

Jag testade Hostingers Laravel VPS från checkout till att öppna de faktiska hanteringsverktyg som följer med den.

Det omfattade att välja plan och serverplats, skapa ett konto, betala och sedan klura ut hur man faktiskt hanterar en Laravel-driftsättning när servern väl var live. Här är hur den processen faktiskt var, inklusive ett ögonblick där gränssnittet skickade mig någonstans jag inte hade väntat mig.

1. Registrering

Jag började på landningssidan för Laravel VPS, som lyfter fram tre påståenden som är värda att minnas från början:

• Gratis automatiska veckovisa säkerhetskopior
• AI-hanterad VPS
• Automatisk malware-scanner

Jag valde KVM 2-planen, en rimlig mellanväg för en enskild Laravel-applikation snarare än en resurstung byggnad, och gick vidare till kundvagnen.

Därifrån lade kundvagnssidan allt på en skärm:

• Faktureringsperiod: 1, 12 eller 24 månader, besparingar visade per alternativ
• Serverplats: regioner grupperade per kontinent, uppskattad latens bredvid varje
• Applikationsmarknad: över tusen one-click OS-, panel- och applikationsalternativ

Jag valde 24 månader för det lägre priset, och spenderade sedan mer tid än vanligt på serverplatsen.

Storbritannien gav bäst latens på listan, men jag skrollade igenom resten av regionerna för att jämföra ändå. Nordamerika visade ett bra resultat för USA, och Asiens snabbaste alternativ, Malaysia, låg betydligt efter båda.

Eftersom sajten jag tänkte mig skulle dra en mestadels amerikansk publik valde jag USA framför det tekniskt snabbare alternativet Storbritannien.

Det är värt att flagga för alla läsare som jämför regioner på den här sidan. Den bästa latensen för dig, när du sitter framför din egen laptop, är inte den siffra som spelar roll. Det är latensen till de människor som faktiskt kommer att besöka sajten, så välj utifrån din publik, inte utifrån dina egna testresultat.

Därefter skrollade jag in i applikationsmarknaden, där Laravel redan var valt, samma one-click-uppsättningsmönster som Hostinger använder över hela sitt appkatalog. Inget behövde ändras där, så jag gick direkt till checkout.

Jag var redan inloggad på ett befintligt Hostinger-konto, så registreringen tog bara ett klick.

Därefter erbjöd sidan för faktureringsadress och betalning:

• Kort, som omfattar Visa, Mastercard, Amex och Discover
• PayPal
• Google Pay
• AliPay, i separata varianter för Kina och Hongkong
• Coingate, för kryptobetalning

Allt på en sida, ingen separat omdirigering. Jag skickade in betalningen, fick en bekräftelsemail direkt och hamnade tillbaka i hPanel med den nya servern redan listad som igång.

Det som stack ut här är hur mycket val Hostinger ger vid checkout utan att göra något av det obligatoriskt.

Platsjämförelsen i synnerhet är värd att ta på allvar i stället för att klicka förbi, eftersom planens standardrekommendation inte alltid matchar vem som faktiskt kommer att använda servern.

2. Instrumentpanel/kundområde

När betalningen gått igenom öppnades hPanel på startsidan, samma centrala konto-panel som hanterar domäner, e-post, webbplatsbyggaren och VPS-hantering från ett och samma ställe.

Den hälsade mig med namn, med en AI-promptfält, en rad genvägsknappar, en att-göra-checklista och en löpande lista över varje webbplats och server på kontot längre ned på sidan.

Därefter skrollade jag till VPS-tabellen, där den nya servern redan var markerad som Running, med sitt värdnamn, IP-adress, plan och utgångsdatum synliga utan att öppna något.

Jag klickade på Manage för att gå in i den serverspecifika panelen.

Att landa på kontots startsida direkt efter betalning, med servern redan provisionerad och listad, är den del av flödet som konsekvent fungerar bra.

Det finns ingen separat väntesida och inget behov av att gräva i menyer för att hitta det du precis köpte.

3. Laravel och serverhantering

Att klicka på Manage öppnade VPS Overview-sidan, och det är här de verkliga skillnaderna börjar synas.

Högst upp låg ett appkort märkt Laravel med en Manage App-knapp, vilket bekräftade att Laravel installerades automatiskt under provisioneringen.

Direkt under det låg ett andra kort som jag inte hade väntat mig:

• Cloudpanel, byggt på Ubuntu 24.04
• Admin-användarnamn visat i klartext
• Länk för lösenordsåterställning
• Egen Manage panel-knapp, separat från Laravel-kortet ovanför

Det andra kortet betyder mer än det ser ut. Cloudpanel är en fullständig kontrollpanel för servern som ingår tillsammans med Laravel, inte en engångsguide för uppsättning, och det visade sig vara den faktiska ytan för att hantera filer, sajter och servern dag till dag.

När jag skrollade förbi båda korten låg den underliggande Ubuntu 24.04-instansen längre ned, markerad som Running, med omstart- och terminalkontroller samt root SSH-information upplagd på samma sätt som varje annan VPS på det här kontot.

Eftersom den här servern precis hade provisionerats var resursgraferna inte ifyllda ännu, hPanel visade ett meddelande som bad mig komma tillbaka om cirka 30 minuter för användningsdata, ett ärligt sätt att hantera en server som faktiskt inte har någon trafikhistorik än i stället för att visa tomma diagram som om de betydde något.

Längre ned hittade jag:

• SSH-nyckelhantering
• Brandväggsregler
• Backup-snapshots
• Malware scanner: Not installed

Den sista raden är det första verkliga hålet. Malware-scannern visas som Not installed, direkt under en plansida som listar en automatisk malware-scanner som en av tre huvudfunktioner för just denna produkt. Oavsett vad marknadsföringen lovar är den inte påslagen som standard på servern du faktiskt får.

Nyfiken på om det andra huvudlöftet stämde bättre, kontrollerade jag Backups & Monitoring härnäst. Loggen Latest Actions visade:

• En recreate-åtgärd loggad samma dag
• Veckovisa backup_create-poster, alla markerade Success, som sträckte sig över mer än en månad tillbaka

Det påståendet stämde mot vad kontots egna loggar visade, en verklig kontrast till malware-scannern som stod oaktiverad bara en sektion bort.

Det är värt att känna till att Hostinger levererar vissa av sina utlovade funktioner som standard och lämnar andra för dig att aktivera själv, och det enda sättet att avgöra vilka som är vilka är att leta efter dem, eftersom plansidan behandlar dem som lika inkluderade.

Därefter gick jag tillbaka till Laravel-appkortet och klickade på Manage App, i förväntan att det skulle öppna någon slags Laravel-specifik uppsättning eller filhanteringsskärm på samma sätt som Cloudpanels knapp gjorde.

I stället öppnade det en sida med titeln “Let’s get started”, med länkar till Laravels egen dokumentation och Laracasts-videoguider, och en enda knapp under som löd Deploy now.

Jag klickade ändå på den för att se vart den ledde, och den tog mig till laravel.com/cloud, registreringssidan för Laravel Cloud.

Här är skillnaden som är värd att vara exakt med.

Laravel Cloud är inte en Hostinger-produkt och har inget med den VPS jag precis hade betalat för att göra. Det är en separat, fullt hanterad hostingplattform byggd och såld direkt av Laravel-teamet, som konkurrerar i samma område som en tjänst som Vercel eller Heroku, med sitt eget kontosystem, sina egna priser och sin egen fria användningskredit.

Att registrera sig där skulle innebära att betala Laravel, ovanpå det du redan betalat Hostinger, för att hosta din applikation någon annanstans helt och hållet.

Vad gäller varför Manage App pekar dit, kontrollerade jag den officiella kunskapsbasartikeln som Kodee själv citerade när jag frågade, “Hur man använder Laravel VPS-mallen hos Hostinger.” Den artikeln går igenom hur man öppnar CloudPanel på din VPS IP på port 8443, redigerar .env -filen och kör Composer- och Artisan-kommandon över SSH.

Den nämner aldrig knappen Manage App, och den nämner aldrig Laravel Cloud heller. Så det här är inte ett fall där förklaringen finns någon annanstans som jag inte hade tittat.

Hostingers egen officiella genomgång för just den här mallen nämner inte att den knappen finns, och Kodee bekräftade, när jag frågade direkt, att Manage App inte hanterar VPS:en och varnade för att registrering i Laravel Cloud från den skulle innebära en andra, separat faktura.

Alla som klickar på Manage App i förväntan att hantera sin app hamnar i stället på en registreringssida för en annan betald produkt, utan någon dokumentation som i förväg förklarar det.

Knappen som faktiskt tar dig dit sitter ett kort längre ned. Manage panel, på Cloudpanel-kortet.

Att klicka på den öppnar en inloggningsskärm som ber om användarnamn och lösenord, och här är det värt att vara exakt, eftersom panelen inte ger några ledtrådar när du väl är på den skärmen.

Användarnamnet är admin, och lösenordet är serverlösenordet som Hostinger mejlade när VPS:en först provisionerades, inte ditt Hostinger-kontolösenord.

Om det mejlet sedan länge är borta genererar Reset-länken som sitter precis bredvid lösenordsfältet på Cloudpanel-kortet ett nytt utan att du behöver rota i inkorgen.

När du väl är inloggad öppnas Cloudpanel på en Sites-lista, med VPS:ens värdnamn redan konfigurerat som en live-sajt, PHP satt som app-typ och en Manage-länk bredvid.

Att öppna sajtens inställningar visade en hel rad flikar, Settings, Vhost, Databases, Varnish Cache, SSL/TLS, Security, SSH/FTP, File Manager, Cron Jobs och Logs.

Det är en verklig, gedigen kontrollpanel, och det är värt att nämna att det ligger en flik för Cron Jobs rakt där i samma gränssnitt. Kodee guidade mig genom att lägga till schemaläggarens cron-post för hand över SSH, vilket fungerar bra, men Cloudpanel har ett point-and-click-sätt att göra samma sak utan att alls röra en terminal, och varken Kodee eller kunskapsbasartikeln nämnde det som ett alternativ.

Med den änden ur vägen är det vänstra menyn på serverns hanteringssida där de verkliga kontrollerna finns.

Här är vad den erbjuder:

• Overview: sammanfattningssidan själv, med Laravel- och Cloudpanel-appkorten, resursanvändning och genvägar till allt nedan
• Settings: servernivåkonfiguration, som täcker saker som återställning av root-lösenord och ändring av värdnamn
• OS & Panel: kontroll över operativsystemet och vilken kontrollpanel som är installerad på servern
• Backups & Monitoring: expanderar till Snapshots & Backups, Server Usage och Latest Actions, vilket är där jag hittade den veckovisa backup-loggen som bekräftade att det påståendet stämde
• Security: täcker malware-scannern och brandväggsinställningarna, avsnittet där jag fann scannern avstängd
• API: öppnar Hostingers API-dokumentation i en ny flik, för alla som automatiserar serverhantering utanför panelen
• DNS Manager: domän- och DNS-posthantering kopplad till servern
• Tutorials: en extern länk till Hostingers hjälpguider

Det är en tillräckligt bred uppsättning för att kalla det komplett VPS-administration. Serverinställningar, OS-kontroll, säkerhet, säkerhetskopior, DNS och API-åtkomst är alla representerade som egna kategorier i stället för att vara gömda i en enda inställningsmeny, och jag stötte inte på något jag behövde som saknades i den här listan.

Det den inte gör är att väva in någon Laravel-specifik verktygslåda, driftsättning av kod, hantering av miljövariabler, körning av Artisan-kommandon, allt sådant sker antingen via Cloudpanel eller terminalen, inte via sidomenyn här.

Vilket för mig till terminalknappen som sitter på Ubuntu-kortet. Dess syfte är direkt kommandoradsåtkomst till själva servern, där en live-SSH-session öppnas i webbläsaren utan att du behöver en separat SSH-klient eller kopiera en privat nyckel till din dator.

Att klicka på den tog mig direkt till ett root-shell, redan autentiserat, med Cloudpanels välkomstbanner på skärmen som visade dess egen webbadress och ett CLI-verktyg kallat clpctl för att hantera panelen från kommandoraden.

För alla som är bekväma med att arbeta från en terminal är det den snabbaste vägen till att faktiskt konfigurera Laravel-installationen, driftsätta kod, redigera miljövariabler, köra migrationer, eftersom inget av det har någon dedikerad knapp någonstans i hPanel.

Slutlig bedömning av användarvänlighet

Hostinger Laravel VPS Hosting

Upptäck hur Hostinger Laravel VPS Hosting erbjuder en flexibel miljö för driftsättning av Laravel-applikationer med dedikerade serverresurser, full kontroll, skalbar prestanda och anpassningsbara konfigurationer för moderna webbprojekt.

Besök Hostinger

Supportnivå

Kodee, Hostingers AI-assistent, ligger bakom knappen Ask AI i hPanel och hanterar support här, på samma sätt som den gör över resten av Hostingers produkter.

Jag testade den med två separata tekniska frågor om den här VPS:en, en om ett gränssnittsfel jag redan hade stött på, och en andra, djupare fråga om hur Laravel faktiskt körs i produktion på den här servern.

Därefter gick jag igenom Hostingers kunskapsbas för att se hur mycket av det området den täcker utan att man behöver fråga någon.

1. AI-support (Kodee)

Min första fråga kom direkt ur testningen av Laravel-appkortets Manage App-knapp, som hade öppnat Laravel Cloud, en separat betald plattform, i stället för något som hörde till VPS:en själv.

Jag frågade Kodee direkt om den knappen var tänkt att öppna Laravel Cloud eller hantera installationen som redan kördes via Cloudpanel, och vad som faktiskt skulle hända om jag registrerade mig för Laravel Cloud därifrån.

Kodee svarade inom en minut:

• Bekräftade att Manage App inte hanterar den befintliga VPS-installationen
• Identifierade den korrekt som en länk till Laravel Cloud, en separat driftsättningsplattform
• Pekade på Cloudpanel, åtkomlig på VPS:ens IP på port 8443, som den verkliga hanteringsytan
• Varnade för att registrering i Laravel Cloud skulle skapa en separat, oberoende fakturerad miljö, inte driftsätta något till den VPS jag redan hade betalat för

Det är ett klart och korrekt svar på en fråga som har en verklig kostnad kopplad till sig om du får den fel, och det kom med en hänvisning till Hostingers egen dokumentation snarare än en gissning.

Därefter frågade jag något med större teknisk tyngd bakom sig. Laravel-applikationer i produktion är beroende av en cron-post för schemaläggaren och en Supervisor-process för att hålla köarbetare igång, och jag ville veta om VPS-mallen sätter upp något av det automatiskt, och om Supervisor själv skulle överleva en omstart om jag konfigurerade det själv.

Kodee sa att den skulle kontrollera servern direkt innan den svarade, och det gjorde den:

• Rapporterade att ingen schedule:run-cronpost fanns
• Rapporterade att ingen Supervisor-tjänst var konfigurerad
• Rapporterade att ingen köarbetare var uppsatt
• Tillhandahöll exakt cron-rad som behövdes för schemaläggaren
• Tillhandahöll ett komplett Supervisor-konfigurationsblock för en köarbetare, med rätt flaggor
• Bekräftade att Supervisor består över en omstart när den aktiveras med systemctl enable –now supervisor
• Lade till påminnelsen att köarbetaren ska startas om med php artisan queue:restart efter att ny kod driftsatts, en detalj som är lätt att missa och som orsakar verkliga produktionsbuggar när den hoppas över

Vad jag tyckte om AI-supporten: Kodee förtjänade sina svar här i stället för att gissa. Att bekräfta att det inte fanns någon scheduler-cron och ingen Supervisor-process innan man rekommenderar något är skillnaden mellan en checklista-svar och ett svar som är grundat i vad just den här servern faktiskt gjorde, och påminnelsen om att starta om köarbetaren efter deploys är den typ av detalj som bara dyker upp när någon, eller något, faktiskt förstår hur Laravel-köer beter sig i produktion.

Två frågor, två korrekta och fullständiga svar, båda levererade inom ett par minuter.

2. Kunskapsbas

Hostingers kunskapsbas är organiserad på samma sätt över alla produkter, stora kategoriplattor med artikelantal, en sökruta och ett kategori-filter längst upp.

I stället för att bläddra gick jag direkt till sök och skrev “laravel”, vilket gav 15 resultat över två sidor, märkbart mer än en smalare one-click-app brukar ge.

Det är dock värt en brasklapp. Fler resultat är inte samma sak som mer relevanta resultat, eftersom flera av träffarna bara var perifert relaterade, en artikel om begränsningar i PHP-mail och en annan om webbplatsmigreringsproblem dök upp helt enkelt för att de nämner Laravel i förbifarten.

Det mest relevanta resultatet, “How to use the Laravel VPS template at Hostinger,” går igenom hur man öppnar Cloudpanel, förstår Laravels mappstruktur, redigerar .env -filen, kör Composer och kör migrationer.

Det är en gedigen genomgång av att få ett Laravel-projekt i gång på den här mallen. Det den inte täcker är schemaläggaren eller köarbetare alls, exakt den lucka Kodee fick fylla när jag frågade.

Om man gräver vidare i sökresultaten hittar man något värt att flagga för. En äldre artikel, “How to deploy Laravel 8 at Hostinger,” innehåller ett fungerande cron-exempel för schemaläggaren, men den är skriven för en annan, äldre uppsättning helt och hållet, där Laravel driftsätts manuellt på shared eller cloud hosting, komplett med en public_html -filstruktur som inte alls har något med hur Cloudpanel organiserar en VPS att göra.

Den som på den här VPS-mallen söker i kunskapsbasen efter vägledning om schemaläggaren skulle landa i en artikel som beskriver en annan produkt innan man hittar något som faktiskt gäller för deras server.

Vad jag tyckte om kunskapsbasen: Artikelantalet ser starkt ut på pappret, 15 resultat för en sökterm, men rå volym döljer hur utspritt det användbara innehållet faktiskt är. Den centrala artikeln om VPS-mallen är välskriven och får igång ett första projekt, men den slutar exakt där en produktionsdriftsättning blir allvarlig, och den enda dokumentation som faktiskt täcker schemaläggaren ligger i en artikel skriven för en helt annan hostingprodukt.

En läsare som litar enbart på kunskapsbasen skulle lätt kunna följa den äldre guiden och felkonfigurera sin VPS genom att kopiera kommandon byggda för en helt annan filstruktur.

Slutlig bedömning av support

Hostinger Laravel VPS Hosting

Upptäck hur Hostinger Laravel VPS Hosting erbjuder en flexibel miljö för driftsättning av Laravel-applikationer med dedikerade serverresurser, full kontroll, skalbar prestanda och anpassningsbara konfigurationer för moderna webbprojekt.

Besök Hostinger

Rekommenderar vi Hostinger Laravel Hosting?

Ja. Grunderna här är starka. Laravel och Cloudpanel kommer förinstallerade och fungerar, den underliggande hårdvaran presterar bra i benchmarktester över CPU, minne och disk, och Kodee levererade två korrekta, servermedvetna tekniska svar när jag satte den på prov på riktigt. Veckovisa säkerhetskopior stämde mot kontots egna loggar, precis som utlovat.

De grova kanterna är smala men värda att känna till innan du köper. Malware-scannern som anges som en huvudfunktion var inte aktiverad som standard, och knappen Manage App på Laravel-kortet skickar dig mot Laravel Cloud, en separat betald produkt, snarare än något som liknar apphantering, utan någon dokumentation som varnar dig i förväg.

Varken det ena eller det andra är svårt att kringgå när du väl vet att Cloudpanel är den verkliga hanteringsytan, men inget av dem borde kräva gissningar.

För en utvecklare som vill få Laravel att köras snabbt på solid infrastruktur, och som är bekväm med att lägga fem minuter på att hitta Cloudpanel i stället för den felmärkta knappen bredvid den, är detta en enkel rekommendation. För någon som vill att varje utlovad funktion ska vara påslagen i samma ögonblick som servern startar, utan någon som helst extra kontroll, bör du räkna med några extra minuter för inställning innan du kallar det klart.

Hostinger

5.0

2,471 user reviews

16 kr /mo

Utgångspris

Besök Hostinger

Rating based on expert review

• Användarvänligt
  4.9
• Support
  4.9
• Funktioner
  4.8
• Pålitlighet
  4.7
• Priser
  4.5