Magento 2 hosting: krav, ydeevne og opsætning

Opdateret og kontrolleret: 12. oktober 2026 · Af: Redaktionen, Magento Hosting Danmark

Magento 2 er en modulær PHP-applikation, der fordeler arbejdet mellem webserver, database, søgemaskine, cache og køsystem. Det gør platformen fleksibel, men også følsom over for forkert opsætning. Her ser vi på forskellen til et webhotel, hvilke versioner der passer sammen, hvordan du dimensionerer uden at gætte, og hvordan deployment bør foregå. Vil du først have overblikket over udbydere, så start med guiden til Magento hosting i Danmark.

Magento 2 versus almindeligt webhotel

Et webhotel er bygget til mange små websites på samme server med begrænset adgang. Magento 2 har brug for det modsatte: egne tjenester, faste baggrundsprocesser og kommandolinje. Du skal kunne køre bin/magento via SSH, installere pakker med Composer, nå en OpenSearch-instans og lade cron starte Magentos jobplanlægger hvert minut. Webhoteller begrænser ofte PHP's køretid og hukommelse, så indeksering, import og kompilering stopper midtvejs – fejl, der er svære at finde, når logfiler og processer er skjult.

Systemkrav og versionskompatibilitet

Adobe understøtter kun de kombinationer, der står i den officielle tabel. Et modul eller en sikkerhedspatch kan bryde, hvis serveren kører en version, Adobe ikke har testet.

Adobe udgiver ikke et officielt minimum for RAM eller CPU til produktionsdrift. Tal i artikler og hostingreklamer er erfaringsværdier, ikke krav. Kontrollér også de PHP-udvidelser, Adobe lister for hver version, og at Linux bruges som operativsystem.

Ressourcer efter butikkens størrelse

I stedet for faste RAM-tal beskriver vi butikken med en belastningsprofil og tester. Profilerne nedenfor er vores egne arbejdsdefinitioner – ikke målte resultater.

Deployment og vedligeholdelse

En sund Magento 2-butik deployes – den redigeres ikke live. Koden ligger i Git, afhængigheder installeres med Composer, og produktionen kører i production mode. En enkel sekvens på serveren ser sådan ud (værktøjer til nul-nedetid bygger i stedet artefaktet uden for produktion):

bin/magento maintenance:enable
composer install --no-dev --optimize-autoloader
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento setup:static-content:deploy da_DK en_US
bin/magento cache:flush
bin/magento maintenance:disable

10 tjek af parathed før go-live

1. Versionsmatch dokumenteret. Notér PHP-, database-, OpenSearch-, Valkey- og Varnish-versionerne, og sammenlign dem med Adobes tabel for netop din Magento-patch. Gem resultatet i projektets dokumentation.
2. Production mode aktiv. Kontrollér med bin/magento deploy:mode:show, at butikken kører i production mode. Developer mode er langsommere og kan vise tekniske fejlmeddelelser til kunderne.
3. Cron kører hvert minut. Installer med bin/magento cron:install, og tjek tabellen cron_schedule for job med status "missed" eller "error". Manglende cron giver forældede indekser og hængende e-mails.
4. Indeksere i "Update by Schedule". På større kataloger bør indekser opdateres via cron frem for ved hver gemning. Det mindsker låse i databasen, når medarbejdere redigerer produkter under trafik.
5. Varnish verificeret. Eksportér VCL-filen fra Magento-admin, læg den på serveren, og kontrollér i svar-headers, at sider faktisk leveres fra cachen. Varnish uden korrekt VCL giver falsk tryghed.
6. Valkey til cache og sessioner. Brug separate databaser eller instanser til cache og sessioner, så en cachetømning ikke logger kunder ud. Overvåg hukommelsen, så sessioner ikke smides ud under spidser.
7. OpenSearch nåbar og lukket. Søgemaskinen må ikke være åben mod internettet. Test forbindelsen, kør en fuld reindeksering, og kontrollér, at søgninger med æ, ø og å giver korrekte resultater.
8. Gendannelse afprøvet. En backup tæller først, når den er gendannet. Gendan database og media til et testmiljø, mål tidsforbruget, og brug tallet som jeres reelle genetableringstid.
9. HTTPS og sikret admin. Hele butikken skal køre over HTTPS, admin bør have en ikke-standard URL, og tofaktorgodkendelse skal være aktiv. Begræns gerne admin-adgang til kendte IP-adresser.
10. Overvågning og alarmer. Overvåg forside, kategoriside og checkout, og sæt alarmer for diskplads, CPU og fejlede cron-job. Uden alarmer opdager du først problemer, når kunderne skriver.

6 typiske konfigurationsfejl

1. Cache slået fra – og glemt. Udviklere slår cachetyper fra under fejlsøgning og glemmer at slå dem til igen. Tjek bin/magento cache:status efter hver release, så full page cache ikke står slukket.
2. Filcache på flere webservere. Har hver server sin lokale filcache, ser kunder forskellige priser og lagerstatus afhængigt af, hvilken server de rammer. Brug en fælles Valkey-cache, når du skalerer horisontalt.
3. Forkert håndtering af mapper. pub/media skal ligge på persistent eller delt lager, og var/ må ikke deployes fra Git. Ellers forsvinder produktbilleder eller logfiler ved næste deploy.
4. Udviklingspakker i produktion. Pakker fra require-dev og debugværktøjer hører ikke hjemme på liveserveren. De gør koden tungere og kan i værste fald afsløre konfiguration eller kundedata.
5. Ingen grænse for bots. Aggressive crawlere kan ramme filtrerede kategorisider uden cache og belaste PHP og database. Brug rate limiting og robots-regler for filter-URL’er, og følg adgangslogs.
6. Uafstemte PHP-grænser. For lave værdier for memory_limit, max_execution_time eller antal PHP-FPM-processer giver tilfældige fejl under import og deploy. Afstem dem med det reelle forbrug, og dokumentér valget.

Eksempel: dimensionering af PHP-FPM uden gætværk

Opsummering

God Magento 2 hosting starter med Adobes versionstabel, fortsætter med test af din egen butik og holdes sund med deployment, cron og overvågning. Når kravene er på plads, kan du se hvilken Magento-hosting der er bedst til din størrelse eller læse om Magento server hosting på VPS og dedikerede maskiner.

FAQ