webpot@dev:~$
Stabil alapok
Biztonság & felügyelet
Teljesítményre hangolva
Magento tárhely és VPS szerver üzemeltetés Ubuntu alapon.
Magento tárhelyet vagy dedikált szervert keres? Bízza a WebPot Dev csapatára.
Pszt! Figyu, ez a weboldal is VPS-ről fut, hogy tetszik a gyorsasága?
Magento tárhely – miért kevés hozzá a megosztott tárhely?
A Magento 2 nem egy nagyobb WordPress. Olyan szolgáltatásokat igényel, amelyek a legtöbb megosztott tárhelyen egyszerűen nincsenek meg – és amelyek nélkül el sem indul.
A Magento hosting kérdése ott dől el, hogy a webáruház mögött van-e OpenSearch, Valkey vagy Redis, Varnish, percenként futó cron és elegendő PHP-memória. Egy átlagos megosztott tárhely ezek közül jellemzően egyet sem ad: nincs SSH-hozzáférés, nincs Composer, nincs saját keresőmotor-példány, és a PHP memóriakerete töredéke annak, amit a Magento telepítője kér. Ezért lesz a Magento szerver választása nem árkérdés, hanem működési feltétel.
Mit ír elő a Magento 2 a szerverkörnyezettől?
Az alábbi táblázat a jelenleg támogatott Magento Open Source és Adobe Commerce verziók hivatalos rendszerkövetelményeit foglalja össze. Két dolog látszik belőle azonnal: a támogatott verziók gyorsan mozognak, és a régi, megszokott komponensek kifutottak.
| Komponens | Magento 2.4.9 | Magento 2.4.8 | Magento 2.4.7 |
|---|---|---|---|
| PHP | 8.5 | 8.4 / 8.3 | 8.3 / 8.2 |
| Adatbázis | MariaDB 12.3 vagy 11.8, MySQL 8.4 | MariaDB 11.4 vagy 11.8 | MariaDB 10.11 vagy 11.8 |
| Keresőmotor | OpenSearch 3 | OpenSearch 3 | OpenSearch 2 vagy 3 |
| Cache / session | Valkey 9 | Valkey 8.1 | Valkey 8.1 (korábban Redis 7.2) |
| Üzenetsor | RabbitMQ 4.3 | RabbitMQ 4.3 | RabbitMQ 4.3 |
| Webkiszolgáló | nginx 1.30 | nginx 1.30 | nginx 1.30 |
| Composer | 2.10 | 2.x | 2.x |
Forrás: Adobe Commerce hivatalos rendszerkövetelmények, 2026. augusztusi állapot.
Öt jel, hogy a webáruházad kinőtte a tárhelyét
Nincs SSH és Composer
A Magento 2 telepítése, frissítése és a modulok kezelése Composerrel történik, parancssorból. Ha csak FTP és fájlkezelő van, a rendszer karbantarthatatlan.
Nincs saját keresőmotor
A 2.4-es Magento kötelezően OpenSearch-öt (korábban Elasticsearch-öt) használ a katalóguskereséshez. Külön példány nélkül a telepítő meg sem engedi a folytatást.
A cron nem fut percenként
Az indexelés, az árszabályok, az e-mail sor és a rendelés-állapotok mind cronból élnek. Ha csak óránként vagy egyáltalán nem fut, csendben állnak le a folyamatok.
Kevés a PHP-memória
A statikus tartalom generálása és a függőségi fordítás önmagában több száz MB-ot kér. Egy 256 MB-os keret mellett a telepítés vagy a frissítés menet közben elszáll.
Nincs Varnish és objektum-cache
Varnish és Valkey/Redis nélkül minden egyes oldalletöltés végigmegy a teljes PHP- és adatbázis-körön. Ez az a pont, ahol a bolt „lassú”-vá válik forgalom alatt.
Mennyi erőforrás kell egy Magento webáruháznak?
Erre nincs egyetlen jó válasz: a termékszám, a látogatószám és az egyedi fejlesztések mennyisége dönt. Az alábbi sávok tájékoztató iránymutatások, amelyekből a konkrét méretezés kiindulhat – a végleges vasat mindig a valós katalógus és forgalom alapján határozzuk meg.
| Bolt mérete | Katalógus / forgalom | vCPU | Memória | Tárhely |
|---|---|---|---|---|
| Induló | ~5 000 termékig, ~50 000 látogató/hó | 4 | 8 GB | 50 GB SSD |
| Növekvő | 5 000–50 000 termék, 50–500 ezer látogató/hó | 8–16 | 16–32 GB | 100–250 GB NVMe |
| Nagy | 50 000+ termék, 500 ezer+ látogató/hó | 16–32+ | 64 GB+ | 500 GB+ NVMe |
Tájékoztató sávok iparági méretezési ajánlások alapján – nem hivatalos Adobe-előírás.
A memóriaigény nagy részét maga a PHP viszi: egy átlagos bolti oldal néhány száz MB-ot használ folyamatonként, a nagy katalógusú admin felület viszont ennek a többszörösét is kérheti, a statikus tartalom telepítése pedig önmagában közel 1 GB-ot. Egyetlen szerveren futó boltnál ezért érdemes nagyságrendileg 2 GB-ot elkülöníteni csak a PHP-nek – és mellé még ott van az adatbázis, az OpenSearch és a cache saját memóriaigénye.
Ha nem akarsz ezzel foglalkozni, nem is kell: mi havidíjas karbantartás keretében méretezzük, felügyeljük és frissítjük a környezetet, a Magento 2 fejlesztéssel egy kézben. Hogy ez a gyakorlatban mit jelent, a referenciáinkon látszik.
Menedzselt Magento tárhely és VPS üzemeltetés
Magento 2-höz hangolt szerverkörnyezet: felépítés, biztonsági hardening, mentés, monitorozás és folyamatos felügyelet – egy kézben. Nem csak beállítjuk a szervert, hanem évekig felelősséget is vállalunk érte.
A VPS szerver üzemeltetés nem ott kezdődik, hogy valaki elindít egy virtuális gépet. Ott kezdődik, hogy valaki felelősséget vállal azért, hogy az a gép fél év múlva, egy biztonsági frissítés vagy egy forgalmi csúcs után is ugyanúgy működjön. A menedzselt VPS és a puszta szerverbérlés között pontosan ez a különbség: az egyiknél kapsz egy üres Ubuntu telepítést root jelszóval, a másiknál kapsz egy felépített, hangolt, védett és felügyelt környezetet, amiért van kit felhívni.
A WebPot DEV saját éles rendszereit – köztük ezt a weboldalt is – ugyanezen az infrastruktúrán üzemelteti. Nem elméletből ismerjük az Ubuntu szerver üzemeltetés buktatóit: a rosszul méretezett swapot, az elszálló PHP-FPM pool-t, a csendben leálló cront, a lejáró tanúsítványt vagy a hetek óta nem ellenőrzött mentést. Ezeket előre kizárjuk, mert mindegyikkel találkoztunk már.
Mit takar nálunk a VPS üzemeltetés?
Méretezés és architektúra
A várható forgalom, adatbázisméret és futó szolgáltatások alapján határozzuk meg a vCPU, memória és NVMe tárhely igényt. Túlméretezni pazarlás, alulméretezni időzített bomba – mindkettőt elkerüljük.
Telepítés és hardening
Ubuntu LTS alap, jelszavas SSH kikapcsolása kulcsos beléptetés javára, nem szabványos portok, UFW tűzfal, Fail2Ban, minimalizált szolgáltatáskör. A gép már az első naptól védve van.
Webkiszolgáló és cache
Nginx vagy Apache PHP-FPM mögött, szükség esetén Varnish teljes oldalas gyorsítótárral, Redis vagy Valkey objektum-cache-sel és HTTP/2, HTTP/3 kiszolgálással.
Adatbázis-hangolás
MySQL vagy MariaDB paraméterezés a valós memóriához: buffer pool, kapcsolatszám, lassú lekérdezés napló. A legtöbb „lassú a weboldal” panasz itt dől el.
Tanúsítvány és e-mail
Let's Encrypt automatikus megújítással, valamint SPF, DKIM és DMARC beállítás, hogy a rendszerüzenetek és a hírlevél ne a spam mappában landoljanak.
Mentés és visszaállítás
Automatikus, verziózott mentés külön tárolóra, megőrzési idővel. A mentés csak akkor mentés, ha a visszaállítást is kipróbáltuk – ezt rendszeresen megtesszük.
Monitorozás és riasztás
Elérhetőség, terhelés, memória, lemez, tanúsítvány-lejárat és szolgáltatás-állapot figyelése. A hibáról mi értesülünk előbb, nem az ügyfél telefonjából.
Frissítés és karbantartás
Biztonsági csomagfrissítések követése, kernel- és PHP-verzió emelés tervezett ablakban, staging környezetben előzetesen ellenőrizve.
Szerverköltöztetés
Meglévő oldal vagy webáruház átköltöztetése másik szolgáltatótól, minimalizált leállással, DNS-átállítással és a régi környezet párhuzamos megtartásával.
Milyen rendszerekhez építünk VPS környezetet?
Ugyanaz a szerver nem jó mindenre. Egy Magento 2 webáruház más erőforrás-profilt kíván, mint egy WordPress honlap vagy egy Laravel alkalmazás, ezért a környezetet mindig a futtatott rendszerhez szabjuk:
- Magento 2 és Adobe Commerce – Varnish, Redis vagy Valkey, OpenSearch, cron-felügyelet, ütemezett indexelés. Részletesen a Magento 2 webáruház oldalon, a szerver folyamatos felügyeletéről pedig a Magento karbantartás és üzemeltetés oldalon.
- WordPress és WooCommerce – objektum-cache, oldal-cache, képoptimalizálás, bővítmény-higiénia és biztonsági szigorítás.
- PrestaShop, OpenCart, egyedi PHP rendszerek – verziófüggő PHP környezet, elkülönített pool-ok, jogosultsági rend.
- Laravel, Node.js, Python szolgáltatások – systemd szolgáltatásként futtatva, reverse proxy mögött, automatikus újraindítással.
- Szerveroldali mérés (sGTM) – saját konténerrel futtatott szerveroldali Google Tag Manager és Measurement Protocol, adatvédelmi szempontból is tisztább méréssel.
- Belső üzleti alkalmazások – VPN mögé zárt admin felületek, IP-korlátozás, külön adatbázis-példány.
A technológiai rétegek, amikből dolgozunk
Bevált, hosszú távon támogatott és nagy közösség által használt komponensek. Éles rendszeren nem kísérletezünk – azt használjuk, ami bizonyítottan működik.
Operációs rendszer
Ubuntu Server LTS kiadás, amely öt év standard biztonsági támogatást kap. Az LTS azt jelenti, hogy a rendszer évekig kap javításokat anélkül, hogy félévente teljes verzióváltást kényszerítene ki.
Ubuntu Server LTSsystemdunattended-upgradesKVM virtualizációWebkiszolgálás
Nginx reverse proxyként és statikus kiszolgálóként, mögötte elkülönített PHP-FPM pool-ok. Modern protokollok és tömörítés, hogy a válaszidő ne a kiszolgálón vesszen el.
NginxPHP-FPM 8.xHTTP/2 és HTTP/3Brotli, GzipApache (igény szerint)Gyorsítótár
Teljes oldalas cache a webszerver előtt, objektum- és munkamenet-cache memóriában, valamint PHP opcode gyorsítótár. Egy jól beállított cache-réteg többet ér, mint a dupla vCPU.
VarnishRedis / ValkeyOPcacheCloudflare CDNAdatbázis és keresés
MySQL vagy MariaDB a rendszer igénye szerint, a valós memóriához hangolt paraméterekkel és lassú lekérdezés naplózással. Webáruháznál külön keresőmotor.
MySQL / MariaDBOpenSearchslow query logPostgreSQL (igény szerint)Biztonság
Tűzfal alapértelmezett tiltással, automatikus IP-tiltás ismételt sikertelen belépésnél, kulcsos SSH, jogosultság-szeparáció és rendszeres sebezhetőség-ellenőrzés. A biztonság nem egy bővítmény, hanem az alapépítés része.
UFW tűzfalFail2BanSSH kulcsos beléptetésLet's Encrypt TLSModSecurity / WAFLevelezés
Hitelesített küldés, hogy a rendelésvisszaigazolás és a hírlevél ne a spam mappában kössön ki. Szükség esetén külső küldő szolgáltató bekötése relayként.
SPF, DKIM, DMARCPostfixSMTP relayspam szűrésMentés és helyreállítás
Napi automatikus, verziózott mentés fájlrendszerről és adatbázisról, külön tárolóra. A mentés soha nem ugyanazon a gépen áll, amit ment.
verziózott fájlmentésadatbázis dumpkülső tárolópróba-visszaállításMonitorozás
Folyamatos elérhetőség- és erőforrásfigyelés, küszöbérték-alapú riasztással. A cél, hogy a problémáról a beavatkozás előtt tudjunk.
uptime figyeléserőforrás-metrikáktanúsítvány-lejáratnaplóelemzésÜzemeltetési higiénia
Verziókövetett konfiguráció, dokumentált változások, staging környezet a kockázatos lépésekhez és tervezett karbantartási ablakok. Éles szerveren nem improvizálunk.
staging környezetkonfiguráció-verziókövetésváltozásnaplókarbantartási ablakMi fut egy WebPot VPS-en?
A szerver köré épülő rétegek és kapcsolataik. Kattints bármelyik csomópontra: megmutatjuk, mit csinál, miért fontos, és mit állítunk be rajta.
Hogyan állítunk üzembe egy VPS szervert?
Hat szakasz a felméréstől a folyamatos felügyeletig. Az időtartamok egy átlagos méretű weboldal vagy webáruház beüzemelésére vonatkoznak.
Felmérés és méretezés
Végignézzük, mi fog futni a szerveren: milyen rendszer, mekkora adatbázis, milyen forgalom, milyen csúcsidőszakok, milyen kiegészítő szolgáltatások. Ebből jön ki a vCPU-, memória- és tárhelyigény, valamint az, hogy egy gép elegendő-e vagy érdemes szétválasztani a webet és az adatbázist. Itt dől el a szolgáltató és a szerver földrajzi helye is – magyar közönségnél a hazai adatközpont mérhető válaszidő-előnyt ad.
Alaptelepítés és biztonsági szigorítás
Ubuntu LTS telepítés, kulcsos SSH beléptetés és a jelszavas bejelentkezés kikapcsolása, tűzfal alapértelmezett tiltással, Fail2Ban, külön rendszerfelhasználók és minimalizált szolgáltatáskör. A gép még az első nyilvános DNS-bejegyzés előtt védett állapotba kerül – egy friss, nyitott Ubuntu VPS-t órákon belül megtalálnak az automatikus szűrőbotok.
Szolgáltatásrétegek és hangolás
Webkiszolgáló, PHP-FPM pool-ok, adatbázis, gyorsítótár-réteg és szükség esetén keresőmotor telepítése, majd paraméterezés a tényleges memóriához és magszámhoz. Az alapértelmezett konfigurációk általában egy fejlesztői gépre vannak szabva, nem éles terhelésre – a különbség gyakran többszörös válaszidőben mérhető.
Migráció és átállás
A meglévő tartalom, adatbázis és levelezés átköltöztetése, tanúsítvány és átirányítások beállítása, majd az új környezet tesztelése éles DNS-váltás előtt. A DNS TTL-t előre lecsökkentjük, így az átállás percekben mérhető, nem órákban. A régi környezetet egy ideig párhuzamosan tartjuk, hogy legyen hova visszalépni.
Mentés, monitorozás, dokumentáció
Automatikus mentés beállítása külső tárolóra megőrzési politikával, próba-visszaállítás, uptime- és erőforrásfigyelés riasztással, valamint a környezet írásos dokumentálása. Az ügyfél megkapja, mi hol fut és mi hogyan állítható vissza – ez nem üzleti titok, hanem alapvető szakmai tisztesség.
Folyamatos felügyelet
Biztonsági frissítések követése, verzióemelések tervezett ablakban, kapacitásfigyelés és időszakos állapotjelentés. Egy szerver akkor marad évekig stabil, ha valaki ránéz akkor is, amikor éppen nincs baj – ez a szakasz az, amit a legtöbb helyen elhagynak.
Tárhely, VPS vagy dedikált szerver?
A három megoldás nem egymás jobb és rosszabb változata, hanem különböző élethelyzetekre való. Íme a különbség őszintén.
| Szempont | Osztózott tárhely | VPS szerver | Dedikált szerver |
|---|---|---|---|
| Erőforrás | Másokkal osztozik, korlátozva | Garantált vCPU és memória | Teljes fizikai gép |
| Szomszédhatás | Egy másik oldal csúcsa téged is lelassít | Elkülönített, kiszámítható | Nincs szomszéd |
| Szoftverkörnyezet | Amit a szolgáltató enged | Szabadon választható, root hozzáféréssel | Teljesen szabad |
| Varnish, Redis, egyedi szolgáltatás | Általában nem lehetséges | Igen | Igen |
| Havi hardverköltség | Néhány száz – néhány ezer Ft | 1500 Ft-tól felfelé | Több tízezer Ft-tól |
| Üzemeltetési teher | A szolgáltatóé | A tulajdonosé – vagy a mienk | A tulajdonosé |
| Skálázás | Csomagváltás, gyakran költözéssel | Erőforrás-emelés percek alatt | Hardvercsere, hosszabb átállás |
| Tipikus használó | Bemutatkozó oldal, blog | Webáruház, üzleti alkalmazás, több projekt | Nagy terhelés, megfelelőségi előírás |
Mikor érdemes VPS-re váltani?
Nem az a kérdés, hogy „elég nagy-e már a cég”, hanem hogy megjelent-e valamelyik az alábbi jelek közül. Ha igen, a tárhely már nem szűk keresztmetszet nélkül szolgál ki:
És mikor nem érdemes?
Ha egy statikus bemutatkozó oldalról van szó, napi néhány száz látogatóval és semmilyen egyedi szoftverigénnyel, akkor a VPS feleslegesen bonyolult és drágább, mint egy jó tárhely. Ilyenkor ezt mondjuk – a túlméretezés ugyanolyan szakmai hiba, mint az alúlméretezés. A VPS akkor térül meg, ha van mit védeni: bevételt, mérhető forgalmat vagy üzleti folyamatot.
Szolgáltatási szintek, reakcióidő és mentés
A „felügyeljük a szerveredet” önmagában semmit nem jelent. Ezért leírjuk, pontosan mit vállalunk – és mit nem.
| Amit vállalunk | Felügyelet | Üzemeltetés | Üzletmenet-folytonosság |
|---|---|---|---|
| Elérhetőség-figyelés | 5 percenként | 1 percenként | 1 percenként, több pontról |
| Riasztás csatornája | e-mail és SMS | e-mail, SMS és telefonhívás | |
| Reakcióidő munkaidőben | 1 munkanapon belül | 4 munkaórán belül | 1 munkaórán belül |
| Reakcióidő munkaidőn kívül | nincs vállalás | következő munkanap reggel | esetügyelet hétvégén is |
| Biztonsági csomagfrissítés | havi | heti | heti, kritikusnál azonnal |
| Mentés gyakorisága | napi | napi, adatbázis gyakrabban | napi teljes + napközbeni adatbázis |
| Mentés megőrzése | 7 nap | 30 nap | 30 nap + havi archivált példány |
| Próba-visszaállítás | évente | félévente | negyedévente |
| Állapotjelentés | negyedéves | havi | havi + negyedéves technikai audit |
| Teljesítmény-felülvizsgálat | – | félévente | negyedévente |
| Staging környezet | – | igény szerint | állandó |
| Dedikált kapcsolattartó | – | – | igen |
A táblázat a tipikus csomagtartalmat mutatja. A konkrét vállalásokat mindig írásos megállapodás rögzíti, a rendszer kritikusságához igazítva.
Mentési politika – amit mindig tisztázunk
A mentés a legtöbb helyen addig működik, amíg nincs rá szükség. Ezért négy kérdésre minden ügyfélnél konkrét válasz tartozik, még az élesedés előtt:
- Mennyi adatot engedünk el a legrosszabb esetben? Ez az RPO – ha napi egy mentés van, akkor legrosszabb esetben egy nap munkája vész el. Webáruháznál ez ritkán elfogadható, ezért ott gyakoribb adatbázis-mentés kell.
- Mennyi idő alatt áll vissza a rendszer? Ez az RTO. Egy 200 GB-os állomány visszaállítása órákat vesz igénybe – erről jó előre tudni, nem a leállás közben.
- Hol áll a mentés? Ha ugyanazon a gépen vagy ugyanabban a fiókban, akkor egy fiók-kompromittálódás vagy egy szolgáltatói hiba a mentést is elviszi. Nálunk a mentés mindig külön tárolóra megy.
- Ki próbálta ki utoljára? A nem tesztelt mentés csak remény. Rendszeresen visszahúzunk egy példányt külön környezetbe, és ellenőrizzük, hogy elindul-e.
Amit őszintén megmondunk előre
A dedikált VPS nem varázslat. A virtuális szerver osztött fizikai vasra épül, így a szolgáltató adatközpontjának hibája minket is érint – valódi földrajzi redundanciát csak több gépes, magasabb költségű architektúra ad. Egy rosszul megírt bővítmény vagy egy végtelen ciklusú lekérdezés a legjobban hangolt szervert is térdre kényszeríti, ezért az üzemeltetés és a fejlesztés minősége együtt számít. És ha a rendszer alapvetően alúlméretezett, azt nem konfigurációval, hanem nagyobb csomaggal kell megoldani – ezt is megmondjuk, ahelyett hogy hetekig hangolnánk a lehetetlent.
Próbáld ki: mit mutat egy karbantartott szerver
Kattints egy parancsra, vagy írd be magad a promptba - a terminál be is gépeli. A kimenetek egy valós, általunk üzemeltetett Ubuntu VPS tipikus értékei, és minden válasz alatt elmagyarázzuk, mit jelent. Kezdd a help paranccsal.
Demonstrációs terminál: nem fut valódi parancs, a kimenet előre rögzített - a számok egy hangolt WebPot VPS valós nagyságrendjei.
Mennyibe kerül egy üzemeltetett VPS szerver?
A végösszeg három tételből áll össze, és érdemes külön nézni őket. Az első a VPS bérleti díja, amit a szolgáltatónak fizetsz – ez a hardver ára, és hónapért 1500 forinttól indul. A második az egyszeri beüzemelés, amikor a nyers Ubuntu telepítésből működő, védett és hangolt környezet lesz. A harmadik a folyamatos üzemeltetés havi díja, ami a felügyeletet, a frissítéseket, a mentést és a rendelkezésre állást fedezi.
A tapasztalat az, hogy a legdrágább megoldás mindig az elmaradt üzemeltetés: egy feltört, elavult vagy mentés nélkül álló szerver helyreállítása többe kerül, mint évek felügyeleti díja – az elvesztett rendeléseket és a keresőben elveszett pozíciókat pedig nem lehet visszaszámlázni senkinek.
Egyszeri beüzemelés
Havi üzemeltetési csomagok
Mitől függ az ár?
Ugyanaz a mondat – „kellene egy VPS” – jelenthet egy havi néhány ezer forintos gépet és egy komoly infrastruktúrát is. A különbséget ezek adják:
- Mi fut a szerveren – egy bemutatkozó honlap és egy tízezer termékes webáruház között nagyságrendi eltérés van erőforrásban és felügyeleti igényben.
- Hány szolgáltatást kell egyben tartani – minden további réteg (cache, kereső, mérőkörnyezet, levelező) külön beállítást és külön figyelést jelent.
- Mennyi leállást bír el az üzlet – a gyorsabb reakcióidő és a hétvégi esetügyelet rendelkezésre állást jelent, aminek ára van.
- Milyen mentési igény van – a hosszabb megőrzés és a gyakoribb adatbázis-mentés tárhelyköltséggé válik.
- Milyen állapotból indulunk – egy átvett, dokumentálatlan szerver feltérképezése önálló fázis, néha több munka, mint egy tiszta telepítés.
- Kell-e több környezet – az állandó staging és a fejlesztői példány külön gépet vagy külön erőforrást igényel.
A fenti sávok nettó árak és tájékoztató jellegűek, nem ajánlatnak minősülnek. A VPS bérleti díja ezektől külön értendő. Minden környezet egyedi felmérés és megegyezés alapján árazódik.
VPS tárhely már nem kiváltság
Már 1500 Ft-tól elérhető a dedikált VPS szerver, ahol az erőforrásokat csak te használod.
A szolgáltatáshoz egy egyszeri beüzemelési költség társul, amely során a szervert sebességre és biztonságra optimalizáljuk (rendszerhangolás, védelem, alap szolgáltatások).
Ennek köszönhetően a VPS már az első perctől gyors, stabil és üzembiztos környezetet biztosít.
Gyakori kérdések a Magento tárhelyről és a VPS-ről
A leggyakrabban felmerülő kérdések – marketingszöveg nélkül, úgy, ahogy egy személyes egyeztetésen is válaszolnánk.
Elég a Magentóhoz egy megosztott tárhely?
A legtöbb általános tárhelycsomagon nem. A Magento 2 telepítése és frissítése SSH-hozzáférést és Composert igényel, a katalóguskereséshez külön OpenSearch példány kell, a cronnak percenként kell futnia, a statikus tartalom generálásához pedig több száz MB PHP-memória. Van néhány hazai szolgáltató, aki kifejezetten Magentóra készített tárhelyet kínál – ott működhet –, de egy átlagos, WordPresshez méretezett csomagon a bolt vagy el sem indul, vagy forgalom alatt használhatatlanul lelassul.
Milyen szerver kell a Magento 2-höz?
A hivatalos rendszerkövetelmény röviden: támogatott PHP-verzió (a 2.4.8-hoz 8.3 vagy 8.4, a 2.4.9-hez 8.5), MariaDB vagy MySQL adatbázis, OpenSearch keresőmotor, Valkey vagy Redis a cache-nek és a munkamenetnek, nginx, Composer 2, valamint teljes oldalas gyorsítótárhoz Varnish. Ehhez jön a méretezés: egy induló bolt ~4 vCPU és 8 GB memória körül kezdődik, nagyobb katalógusnál ez többszöröse. A részletes táblázat feljebb, a Magento tárhely szekcióban van.
Mennyibe kerül egy Magento tárhely?
Három tételből áll össze, és érdemes külön nézni őket: a virtuális gép bérleti díja (ez a mérettel arányos, és a Magento nagyobb gépet kíván, mint egy honlap), az egyszeri beüzemelés – amikor a nyers telepítésből védett, Magentóra hangolt környezet lesz –, és a folyamatos üzemeltetés havi díja. A konkrét sávokat az árak szekcióban találod, a havi karbantartási csomagokat pedig a Magento karbantartás oldalon.
Miért lassú a Magento webáruházam?
A tapasztalat szerint négy okból, ebben a sorrendben. Először: nincs Varnish és objektum-cache, ezért minden oldalletöltés végigmegy a teljes PHP- és adatbázis-körön. Másodszor: az indexerek ütemezése vagy a cron rossz, ezért a rendszer folyamatosan újraszámol. Harmadszor: az adatbázis nincs a valós memóriához paraméterezve. Negyedszer: túl sok, egymásra rétegződő harmadik féltől vett modul fut. A tárhelyváltás ezek közül csak az első hármat oldja meg – a negyedikhez fejlesztői átvilágítás kell.
Mi az a VPS szerver, és miért nevezik virtuálisnak?
A VPS (Virtual Private Server) egy fizikai szerveren belül kialakított, elkülönített virtuális gép, saját operációs rendszerrel, saját fájlrendszerrel és garantált erőforrásokkal. Úgy viselkedik, mintha saját szervered lenne – root hozzáféréssel, szabadon telepíthető szoftverekkel –, de a fizikai vasat többen osztják. A modern virtualizáció (jellemzően KVM) garantálja, hogy a szomszédos példányok ne lássanak bele egymás adataiba és ne vegyék el egymás erőforrását.
Mennyibe kerül egy VPS szerver Magyarországon?
A VPS bérleti díja hazai szolgáltatónál havi 1500 forinttól indul egy kisebb, egy-két vCPU-s gép esetén, és a méretével arányosan nő. Ez azonban csak a hardver ára. Ehhez jön az egyszeri beüzemelés – amikor a nyers telepítésből védett, hangolt környezet lesz –, valamint a folyamatos üzemeltetés havi díja, ha nem saját magad akarod felügyelni. A konkrét sávokat az árak szekcióban részletezzük.
Mi a különbség a menedzselt és a nem menedzselt VPS között?
Nem menedzselt esetben a szolgáltató a virtuális gépet és a hálózatot adja – minden más a te felelősséged: telepítés, biztonság, frissítés, mentés, hibaelhárítás. Menedzselt esetben ezt egy üzemeltető vállalja át. A különbség akkor látszik meg, amikor baj van: nem menedzselt gépnél a szolgáltató legfeljebb annyit mond, hogy a virtuális gép fut – hogy a weboldal miért nem, az nem az ő dolga.
Miért Ubuntut használtok, és mit jelent az LTS?
Az Ubuntu Server a legelterjedtebb Linux disztribúció webes kiszolgálásra, ami két gyakorlati előnyt jelent: szinte minden szoftverhez van hozzá hivatalos csomag és dokumentáció, és bármilyen hibába futunk, nagy eséllyel más is beleütközött már. Az LTS (Long Term Support) kiadások öt év standard biztonsági támogatást kapnak, így a rendszer évekig frissíthető marad anélkül, hogy félévente teljes verzióváltást kényszerítene ki.
Kell-e rendszergazdát alkalmaznom, ha VPS-t használok?
Nem feltétlenül – pontosan ezért létezik a menedzselt üzemeltetés. Egy átlagos webes környezet felügyelete nem tölt ki egy teljes munkaidős pozíciót, viszont szakképzettséget igényel. A havi üzemeltetési díj töredéke egy alkalmazott költségének, cserébe a tudás és a rendelkezésre állás folyamatos. Ha van belső informatikusod, akkor is dolgozhatunk együtt – sok ügyfélnél a belső csapat mellett adunk szerver-szintű támogatást.
Mennyi idő alatt áll üzembe egy VPS?
Egy átlagos weboldalhoz készülő környezet 2–4 munkanap alatt áll össze a felméréstől az élesedésig. Webáruháznál, ahol gyorsítótár-réteg, keresőmotor és teljesítményhangolás is kell, ez 4–10 munkanap. A migráció ideje főként az adatmennyiségtől és a régi környezet állapotától függ – egy dokumentálatlan, évek alatt összenőtt szerver feltérképezése néha több idő, mint maga a költöztetés.
Átköltöztethető a meglévő weboldalam? Mennyi leállással jár?
Igen, és a leállás jól tervezve percekben mérhető, nem órákban. A módszer: az új környezetet előre felépítjük és teszteljük, a DNS élettartamát (TTL) előző nap lecsökkentjük, majd egy alacsony forgalmú idősávban történik az átkapcsolás és a friss adatok másolása. A régi szervert még napokig párhuzamosan tartjuk, hogy legyen hova visszalépni.
Mekkora VPS kell egy webáruházhoz?
Ez a rendszertől, a katalógus méretétől és a forgalomtól függ, nem általános szabálytól. Egy néhány száz termékes WooCommerce bolt általában jól elfut néhány vCPU-n és pár giga memórián, míg egy Magento 2 rendszer érdemi memóriát igényel már az indexeléshez és a keresőmotorhoz is. A méretezést mindig a tényleges terhelési adatokból számolással kezdjük, és inkább skálázható csomagot választunk, mint előre túlméretezettet.
Nem elég a szolgáltató mentése?
Önmagában ritkán. A szolgáltatói pillanatkép (snapshot) a teljes gépről készül, gyakran ugyanabban az infrastruktúrában tárolódik, és rövid ideig őrződik meg. Ha csak egy táblát vagy egy fájlt kell visszaállítani, a snapshot túl durva eszköz; ha pedig a szolgáltatói fiók sérül, a snapshot is elvész vele. Ezért teszünk minden esetben külön, független tárolóra menő, verziózott mentést is.
Mennyire biztonságos egy VPS?
Pontosan annyira, amennyire felügyelik. Egy friss, alapbeállításokkal futtatott és kitett Ubuntu VPS ellen órákon belül megindulnak az automatikus jelszópróbálgatások. Ezért a beüzemelés része a kulcsos SSH beléptetés, a jelszavas bejelentkezés tiltása, az alapértelmezetten záró tűzfal, az ismételt próbálkozások automatikus tiltása és a futó szolgáltatások körének minimalizálása. A legtöbb feltört szerver nem körülményes támadás áldozata, hanem egy elmaradt frissítésé.
Mi történik, ha mégis feltörik a szervert?
Ilyen esetben nem „kitakarítunk” egy fertőzött rendszert, mert egy kompromittálódás után soha nem lehet biztosan kijelenteni, hogy minden hátsó ajtó eltűnt. A helyes eljárás: a szerver izolálása, a behatolás útjának azonosítása a naplókból, majd tiszta környezet felépítése és az adatok ellenőrzött visszaállítása – a kihasznált rés bezárásával együtt. Ezért ér annyit egy működő mentési rendszer.
Hol legyen földrajzilag a szerver?
Ha a látogatók túlnyomó része magyar, akkor hazai vagy közép-európai adatközpont a célszerű: a rövidebb hálózati út mérhetően jobb válaszidőt ad, ami a Core Web Vitals értékekben is megjelenik. Nemzetközi közönségnél a különbséget CDN-nel lehet kiegyenlíteni. Adatvédelmi szempontból az európai uniós adatközpont a legegyszerűbben védhető választás.
Tényleg gyorsabb a VPS, mint egy jó tárhely?
Nem automatikusan. Egy alapbeállításokkal futó VPS lehet lassabb is, mint egy jól optimalizált tárhely. A VPS előnye nem a nyers sebesség, hanem a kontroll: te döntöd el, hogy milyen cache-réteg fut, mennyi memóriát kap az adatbázis, milyen PHP-beállítások élnek. A gyorsaság ebből a kontrollból lesz – ha valaki értő kézzel él vele.
Kell cPanel vagy Plesk felület?
Nem kötelező, és ha az üzemeltetést mi visszük, akkor jellemzően felesleges: a vezérlőpanelek licencdíjat, további erőforrást és újabb támadási felületet jelentenek. Ha viszont szükséged van önálló felületre – például több ügyfél tárhelyét kezelnéd –, akkor telepíthető, és van ingyenes alternatíva is. Ezt a felméréskor tisztázzuk.
Futtatható több weboldal egy VPS-en?
Igen, és gyakran ez a leggazdaságosabb megoldás. A lényeg az elkülönítés: minden oldal saját rendszerfelhasználót, saját PHP-FPM pool-t és saját adatbázis-hozzáférést kap, így egy oldal biztonsági problémája nem terjed át a többire. Érdemes viszont figyelni, hogy egy nagy forgalmú webáruház mellé ne kerüljön olyan projekt, amelyik csúcsidőben elviszi előle az erőforrást.
Hogyan skálázható később?
Két irányban. Függőlegesen: a szolgáltatónál több vCPU és memória kérhető, ez általában egy rövid újraindítással jár. Vízszintesen: a webréteg és az adatbázis szétválasztható külön gépekre, elé terheléselosztó tehető, a statikus tartalom pedig CDN-re költöztethető. A legtöbb magyar webáruháznak sokáig elég az első út – a második akkor jön, ha a forgalom tényleg megköveteli.
Megkapom a root hozzáférést a saját szerveremhez?
Igen. A szerver a te tulajdonod vagy a te előfizetésed, így a teljes hozzáférés jár hozzá, ahogy a környezet írásos dokumentációja is. Egyetlen kérésünk, hogy a közös üzemeltetés idején a kézi beállítás-módosításokat egyeztessük – a nem dokumentált változás a leggyakoribb oka annak, hogy egy addig stabil rendszer hirtelen “magától” elromlik.
Mi történik, ha felmondom az üzemeltetést?
Semmilyen technikai fogság nincs. A szerver, a domain, a mentések és a dokumentáció a tiéd marad, és átadási jegyzőkönyvvel adjuk át a hozzáféréseket a következő üzemeltetőnek. Nem használunk zárt, csak általunk értett megoldásokat: a környezet szabványos Ubuntu, szabványos szolgáltatásokkal, hogy bármelyik szakember át tudja venni.
Milyen szerver kell szerveroldali méréshez (server-side GA4)?
A szerveroldali Google Tag Manager saját konténerben fut, és a forgalommal arányosan használ erőforrást – kisebb-közepes forgalomnál egy dedikált VPS bőven elég hozzá, saját aldoménnel és tanúsítvánnyal. Előnye, hogy a mérés nem külső szkripttől függ, a hirdetési adatok pontosabbak, és adatvédelmi szempontból is jobban kontrollálható, mi hagyja el a rendszert.
Ti élesben is használjátok ezt, vagy csak ajánljátok?
Használjuk. A WebPot DEV saját rendszerei – beleértve ezt a weboldalt és az általunk fejlesztett webáruházakat – ugyanezen az elven felépített Ubuntu VPS környezetben futnak. Ami nálunk nem vált be, azt ügyfélnek sem ajánljuk.
Szerverüzemeltetési fogalomtár
A leggyakrabban előkerülő szakkifejezések röviden, magyarul – hogy egy ajánlat vagy egy üzemeltetői egyeztetés ne legyen érthetetlen.
VPS
Virtual Private Server: fizikai szerveren belül kialakított, elkülönített virtuális gép saját operációs rendszerrel és garantált erőforrásokkal.
KVM
A Linux beépített virtualizációs technológiája. Erős elkülönítést ad a példányok között – ezért érdemes KVM-alapú VPS-t választani a régebbi, gyengébben szeparált megoldások helyett.
vCPU
A virtuális gépnek kiosztott processzormag. Nem mindegy, hogy garantált vagy csak megosztható kapacitásról van szó – a különbség csúcsidőben derül ki.
LTS
Long Term Support: hosszú távon támogatott Ubuntu kiadás öt év standard biztonsági javítással. Éles szerverre mindig LTS való, soha nem köztes kiadás.
Hardening
Biztonsági szigorítás: a felesleges szolgáltatások kikapcsolása, jogosultságok szűkítése, belépési módok korlátozása. A telepítés része, nem utólagos kiegészítés.
SSH kulcs
Jelszó helyett kriptográfiai kulcspárral történő beléptetés. Nem lehet kitalálni és nem lehet próbálgatással feltörni – ezért kapcsoljuk ki a jelszavas SSH bejelentkezést.
Tűzfal (UFW)
Csak azokat a portokat engedi be, amelyek tényleg kellenek. Alapértelmezésben minden tiltva van, és csak a szükséges szolgáltatások kapnak kivételt.
Fail2Ban
A naplókat figyelve automatikusan kitiltja azokat az IP-címeket, amelyek ismételten sikertelenül próbálnak belépni. Ezzel szűnnek meg a robot támadások naplózárkói.
Reverse proxy
A látogató és az alkalmazás közé tett kiszolgáló (jellemzően Nginx), amely a titkosítást, a tömörítést és a forgalomelosztást intézi.
Varnish
Teljes oldalas gyorsítótár a webszerver előtt. A látogatók nagy része kész, eltárolt oldalt kap, így a PHP-t és az adatbázist meg sem kell terhelni.
Redis és Valkey
Memóriában tároló gyorsítótárak munkamenetekhez és objektum-cache-hez. A Valkey a Redis nyílt forráskódú továbbélő ága.
PHP-FPM pool
A PHP-folyamatok elkülönített csoportja. Weboldalanként külön pool azt jelenti, hogy egy oldal túlterhelése vagy sérülése nem viszi magával a többit.
OPcache
A PHP előfordított kódját tartja memóriában, így nem kell minden kérésnél újra értelmezni a forrást. Ingyenes sebesség, ha jól van méretezve.
Cron
Az ütemezett háttérfeladatok motorja: indexelés, e-mail küldés, feed-generálás, mentés. Ha a cron nem fut, a rendszer látszólag működik, de sok minden csendben elmarad.
systemd
Az Ubuntu szolgáltatáskezelője. Ez indítja és tartja életben a háttérfolyamatokat, és ez indítja újra őket, ha váratlanul leállnak.
RPO
Recovery Point Objective: mennyi adatot engedünk el a legrosszabb esetben. Napi egy mentésnél ez legfeljebb egy nap munkája.
RTO
Recovery Time Objective: mennyi idő alatt áll vissza a rendszer egy súlyos hiba után. Nagy adatmennyiségnél ez órákban mérhető, és érdemes előre tudni.
Snapshot
Pillanatkép a teljes virtuális gépről. Gyors visszaállásra jó, de nem helyettesíti a külön tárolón álló, verziózott mentést.
SPF, DKIM, DMARC
Három DNS-alapú e-mail hitelesítési szabvány. Együtt biztosítják, hogy a nevedben küldött levél hitelesnek számítson, és ne kerüljön spambe.
TTL
A DNS-bejegyzés élettartama. Szerverköltöztetés előtt lecsökkentve az átállás percek alatt átfut, nem órák alatt.
Uptime
A rendelkezésre állás aránya. A 99,9 százalék havonta körülbelül 43 perc kiesést jelent – érdemes számokban gondolkodni, nem jelzőkben.
Load average
A rendszerterhelés mutatója. Önmagában nem mond semmit – a magszámhoz viszonyítva értelmes, és ilyenkor derül ki, hogy szűk-e a kapacitás.
Staging
Az éles rendszer mása, ahol a frissítés és a fejlesztés előzetesen kipróbálható. Aki közvetlenül élesben tesztel, az az ügyfeleivel teszteltet.
WAF
Webalkalmazás-tűzfal, amely a bejövő kéréseket szűri ismert támadási mintákra. Jó kiegészítő védelem, de nem pótolja a frissítést.
Kapcsolódó Magento szolgáltatások
Magento karbantartás
Havidíjas üzemeltetés: biztonsági patch-ek, verziófrissítés, hibajavítás, monitorozás és havi jelentés.
Magento 2 fejlesztés
Új webáruház bevezetése, egyedi modulok, fizetési és ERP-integrációk, átlátható árazással.
Magento migráció
Platformváltás Magento 2-re: adatmigráció, 301-es átirányítási térkép és tesztelt éles átállás új szerverkörnyezetbe.
Referenciák
Webáruházak, amelyeket fejlesztettünk, költöztettünk vagy évek óta üzemeltetünk.
Árajánlatkérés
Írd le, mekkora a katalógus és a forgalom. Visszajelzünk, milyen szerver kell hozzá.
