Alapvető VPS-szoftverek: mit telepítsen az egyes felhasználási módokhoz

Egy friss VPS ugyanaz az üres doboz, akár egy weboldal hosztolására, akár egy tradingbot futtatására vették. Ugyanaz a tiszta kiindulópont, ugyanaz a szinte üres lemez, alig valami az operációs rendszeren túl. Ami rákerül, az már az első telepítésnél szétválik, és úgy is marad: egy webes stack és egy trading stack szinte semmilyen szoftveren nem osztozik, és az egyik nem is ugyanazon az operációs rendszeren fut.

Így nincs egyetlen lista az alapvető VPS-szoftverekről. Van egy rövid alapréteg, amelyre minden szervernek szüksége van, bármiért vették is, utána pedig mindenről a felhasználási mód dönt. Két, ezt megelőző döntés is megváltoztatja ennek az alaprétegnek a formáját. A megosztott tárhely és a VPS közötti választás eldönti, hogy van-e egyáltalán root-hozzáférése. A menedzselt és a nem menedzselt közötti választás eldönti, hogy az alábbi öt elem közül mennyiért felel saját maga.

OLVASD

KVM vs. OpenVZ vs. LXC: mit enged meg valójában a VPS virtualizációs típusa

Röviden

• Nincs univerzális válasz. Egy rövid alaprétegen túl a felhasználási mód választja ki a programokat, és néha az operációs rendszert is.
• Minden VPS-nek először ugyanarra az öt kategóriára van szüksége: biztonságos adminisztrátori hozzáférésre, egy ténylegesen bekapcsolt tűzfalra, frissítési szabályzatra, legalább egyszer visszaállított biztonsági mentésekre, és valamire, ami jelzi, hogy a gép életben van. Linuxon a biztonságos adminisztrátori hozzáférés általában kulcsalapú SSH-t jelent; Windowson az RDP vagy egy másik adminisztrációs útvonal védelmét.
• Három dolog, amelyet egy 1 vagy 2 GB-os Linux VPS-re nem érdemes alapból feltenni: egy vezérlőpult, egy víruskereső és a levelezési stackbe épített spam- és vírusszűrés. Dokumentált memóriaigényük egy kis gép nagy részét vagy egészét elfoglalhatja, mielőtt a tényleges munkaterhelése elindulna.
• Ezután tíz VPS-felhasználási mód következik, mindegyik a munkát végző programokkal és azzal az egy korláttal, amely eldönti, hogy elfér-e a megvásárolt gépen.
• Minden szakasz itt a térkép. A hivatkozott útmutatók adják a mélységet.

Amire minden VPS-nek szüksége van, bármiért vásárolta is

Az első dolog, amit egy új VPS-re telepíteni kell, semmi köze ahhoz, miért vették. Öt elem jön először, ugyanaz az öt, akár egy webáruházat, akár egy játékszervert futtat végül a gép.

Linuxon kezdje a kulcsalapú SSH-val. Hozzon létre egy kulcspárt, tegye a nyilvános kulcsot a szerverre, egy második munkamenetben ellenőrizze, hogy a kulcsos bejelentkezés működik, majd kapcsolja ki a jelszavas hitelesítést, mert egy nyilvános IP-címen futó, jelszóval védett port mágnesként vonzza a bejelentkezési kísérleteket.

Aztán a tűzfal, és ellenőrizze, hogy fut-e, ahelyett, hogy feltételezné. Az Ubuntu alapértelmezett tűzfaleszközként az UFW-t szállítja, és az Ubuntu közösségi dokumentációja szerint az UFW alapértelmezés szerint ki van kapcsolva. Az előtelepített nem ugyanaz, mint a bekapcsolt. Ha SSH-n keresztül csatlakozik, először engedélyezze a tényleges SSH-portját, majd kapcsolja be az UFW-t, és csak azokat a további portokat nyissa meg, amelyekre a munkaterhelésnek szüksége van. Alapértelmezett beállításnál ez az első szabály: sudo ufw allow 22.

Ha egy webalkalmazás-tűzfal is szóba kerül, a kategóriákkal kezdje. A Linux VPS-hez elérhető ingyenes tűzfallehetőségek négy, könnyen összekeverhető kategóriába sorolhatók.

A frissítési szabályzat a harmadik, és az alapértelmezés a disztribúciótól függ. Az Ubuntu Server automatikus frissítésekről szóló útmutatója szerint a csomag alapból telepítve van, és automatikusan alkalmazza a biztonsági frissítéseket. Ez a csomag: unattended-upgrades.

A Debian nem tesz ilyen ígéretet. A Debian wiki figyelmeztet, hogy egy rendszer „lehet, hogy egyáltalán nem telepítette a csomagot, vagy telepítette, de teljesen letiltotta”. Annak ellenőrzéséhez, hogy engedélyezve van-e, és a beállításához futtassa ezt: sudo dpkg-reconfigure unattended-upgrades.

A biztonsági mentés a negyedik, és a szabály egyetlen visszaállítás. Az a mentés, amelyet soha senki nem állított vissza, csak hipotézis. Állítson vissza egyet egy eldobható szerverre, nézze meg, ahogy elindul, és onnantól az egy biztonsági mentés.

Az ötödik egy monitorozási útvonal, valami, ami előbb szól a szerver leállásáról, mint egy felhasználó. Egy könnyű rendelkezésre állás-ellenőrző megteszi. Nincs megbízható képlet, amely a monitorok számát memóriára váltaná, ezért induljon 1 vCPU-val és 1 GB-tal, és figyeljen.

Ezen az öt elemen túl a hardening önálló projekt, nem egyetlen lépés. Két útmutató már foglalkozik vele:

• Egy 20 pontos ellenőrzőlista a Linux VPS biztonságossá tételéhez
• A Windows VPS hardening-ellenőrzőlistája

Most jön a nehezebb fele: mit ne tegyen fel alapból egy 1 vagy 2 GB-os Linux VPS-re. A CloudPanel legalább 2 GB RAM-ot igényel, mielőtt a webhelyei bármit is használnának. A ClamAV saját dokumentációja 3 GiB-ot vagy többet ajánl. A Virtualmin kevés memóriájú rendszerekre vonatkozó útmutatója pedig azt javasolja, hogy szűkös memória esetén teljesen kapcsolja ki a SpamAssassint és a ClamAV-t.

Ezek a gyártók követelményei és ajánlásai, nem ízlés kérdései. Mindhármat rossz alapértelmezett választássá teszik egy kis gépen, hacsak az adott szoftver nem része annak a munkaterhelésnek, amelyért valójában megvette a VPS-t.

Mit futtatnak az egyes felhasználási módok

Ebben a tíz helyzetben nem annyira a gép mérete változik, hanem az, hogy melyik két-három programnak kell léteznie, mielőtt bármi más számítana, és melyik korlát dönti el általában, mekkora legyen a gép.

A harmadik oszlopot érdemes kétszer elolvasni. A több CPU a reflexszerű bővítés, és ezeknek a soroknak több esetében nem ez a döntő korlát.

Weboldal vagy webalkalmazás hosztolása

Az ezt a szervert meghatározó döntés nem az, hogy melyik webszerver gyorsabb. Hanem az, hogy ki kezeli a TLS-tanúsítványokat. A Caddy maga állítja ki és újítja meg őket, extra eszköz nélkül. Az NGINX egy külön ACME-klienst, például Certbotot, és több kézi konfigurációt vár, cserébe üresjáratban kevesebb memóriát használ. A Caddy és NGINX összehasonlítása egymás mellé teszi a két konfigurációs fájlt, ha ezt a kompromisszumot ellenőrizni kell, mielőtt valamelyik mellett dönt.

A többi az alkalmazást követi, nem fordítva. Sok dinamikus alkalmazásnak adatbázisra van szüksége, és hogy ez MariaDB vagy PostgreSQL lesz, azt általában az dönti el, mit támogat az alkalmazás, nem a személyes preferencia. A Redis akkor érdemli ki a helyét, ha az alkalmazásnak valóban gyorsítótárra, munkamenetekre, várólistákra vagy más Redis-alapú funkcióra van szüksége. És ha egynél több webhely vagy szolgáltatás osztozik a szerveren, egy reverse proxy, vagyis az elöl álló folyamat, amely minden kérést a hosztnév alapján a megfelelő alkalmazáshoz irányít, még azelőtt véget vet a portokkal való zsonglőrködésnek, hogy elkezdődne. Az Nginx Proxy Manager grafikus felületet ad ehhez a feladathoz, és kényelmesen elfut 2 GB-on. Az Nginx Proxy Manager beállítási útmutatója lépésről lépésre végigvezet rajta.

Egy kikötés, és ez teljesen elvezet a VPS-től. Ha a feladat egyetlen kis webhely különleges igények nélkül, a menedzselt tárhely védhető válasz, a saját adminisztrálású szerver pedig haszon nélküli többletmunka. A VPS abban a pillanatban kifizetődik, amikor a webhelynek olyasmire van szüksége, amit egy menedzselt csomag nem telepít Önnek.

Fizetős SaaS-eszközök lecserélése saját üzemeltetésűekre

Itt a Docker a sorrendet meghatározó döntés, és megelőzi mindazokat az alkalmazásokat, amelyekért jött. Egy konténer-futtatókörnyezet minden szolgáltatást és függőségeit a saját dobozában tartja elzárva, így a Nextcloud PHP-verziója és az Immich gépi tanulási könyvtárai sosem vesznek össze. A Portainer vagy a Dockge webes felületet ad ennek a futtatókörnyezetnek, és helyet, ahol látszik, mi fut. A Coolify tovább megy, és a szervert egy telepítési platformhoz közelebb álló eszközzé alakítja, git push alapú buildekkel és automatikus TLS-sel. A kezelőréteget a futtatókörnyezet után válassza, ne helyette.

Profi tipp: A Dockert a Docker saját tárolójából telepítse, ne a disztribúcióéból. A Docker telepítési dokumentációja nem hivatalosnak nevezi a disztribúció által biztosított csomagot, és előírja, hogy a Docker Engine telepítése előtt el kell távolítani. Ez a csomag: docker.io.

Maguk az alkalmazások jelentik a könnyű részt, és éppen ez a probléma. Egy r/selfhosted szál arról, hogy az emberek mely saját üzemeltetésű szolgáltatásokat tartják meg hosszú távon, jól mutatja ezt. A szál indítója felsorol egy sor helyettesítőt, amelyet beállított, majd feladott, és egyik sem a telepítési lépésnél bukott el. A felhozott okok a felhasználói élmény csiszolatlanságáról és a hozzáférés elvesztésétől való félelemről szóltak. Egy VPS ennek második felét teljes mértékben megoldja, mivel nem függ az otthoni áramtól vagy attól, hogy egy otthoni internetkapcsolat működik-e. Az első feléért viszont semmit sem tesz.

Trading: forex, algo és kripto

Ez az egyetlen szakasz, ahol az operációs rendszer megváltozhat. A MetaTrader 4 és a MetaTrader 5 Windows-alkalmazások, így egy trading szerver továbbra is gyakran RDP-n keresztül elért Windows Server. A MetaQuotes a MetaTrader Linuxon, Wine-on keresztüli futtatását is támogatja, így a Windows az egyszerűbb natív út, nem pedig kötelező feltétel. A QuantRocket ugyanennek a listának az algoritmikus és kvantitatív kutatási vége, a BTCPay Server pedig a kriptofizetéseket kezeli. Mindkettő Docker-munkaterhelés Linuxon.

A specifikációk kevésbé számítanak, mint a térkép. Egy trader az r/VPSforTradings oldalon, aki öt brókernél tervezett MT5-botot, azt kérdezte, melyik VPS adja a legkisebb késleltetést az egyes brókerek konkrét adatközpontjához, és ez az a kérdés, amely eldönti a dolgot. A nagy brókerek végpontjai néhány adatközponti csomópont köré csoportosulnak, és a VPS és a bróker végpontja közötti hálózati útvonalat kell mérnie. Két azonos processzorú szerver különböző hálózatokon vagy különböző városokban nagyon eltérően viselkedhet ennél a feladatnál.

Ami a kézenfekvő bővítést teszi rossz választássá. Több mag vásárlása nem rövidíti le az útvonalat. A forex VPS helyszínének kiválasztása a csomag előtt az a pont, ahol ez a döntés eldől.

Privát VPN vagy mesh hálózat futtatása

Itt két forma létezik, és nem cserélhetők fel. Egy WireGuard-szerver a VPS-en titkosított útvonalat ad az eszközeinek ehhez a szerverhez és mindahhoz, amit rajta keresztül irányít. A WireGuard Easy webes felületbe csomagolja ezt a beállítást, így egy peer hozzáadása többé nem jelenti egy konfigurációs fájl kézi szerkesztését. Egy olyan mesh hálózat, mint a Tailscale, egészen más: az eszközök közvetlenül próbálnak egymáshoz csatlakozni, de a forgalom peer relay-t vagy DERP relay-t is használhat, ha közvetlen útvonal nem lehetséges. A koordinációs rétege osztja szét azokat az információkat, amelyekre az eszközöknek szükségük van egymás megtalálásához és a kapcsolódáshoz. Az OpenVPN AS, a Pritunl, a ZTNET és a WGDashboard tölti ki a két pólus közötti teret.

Egy r/selfhosted szál erről a választásról felszínre hozta a Tailscale-től való függés valódi aggodalmát. Az egyik válaszoló azt írta, hogy „csak attól tart, hogy a Tailscale romlani kezd, miközben próbál nyereségessé válni”. Ez a szolgáltatóval, nem az árral kapcsolatos aggodalom. Ha saját maga futtatja az alagutat, azzal kiveszi ezt a céget a láncból.

Ez munkával is jár. Egy menedzselt koordinációs szerver valóban kevesebb üzemeltetést igényel, és egyetlen laptop számára, amely egyetlen szervert ér el, a saját mesh felállítása több gépezet, mint amennyit a probléma kíván. Ebben az esetben a sima WireGuard elég.

Játékszerver hosztolása

A játék a könnyű telepítés, a panel a döntés. Csak a Minecraftnak is több szerverváltozata van, és hogy melyiket futtatja, azt az dönti el, mit vár tőle: Paper a teljesítményért egy sima survival szerveren, Forge vagy Quilt, ha egy modpack a lényeg. Közvetlenül a szerveren futtatni is jól működik. A Pterodactyl Panel és a Wings démon alatt, vagy a PufferPanel alatt futtatva szerverenkénti erőforráskorlátokat, webes konzolt és egy módot kap arra, hogy egy barátjának újraindítási jogot adjon anélkül, hogy SSH-t adna neki. A Nakama egészen más termék, azoknak, akik játékot fejlesztenek, nem pedig hosztolnak.

Egy r/admincraft útmutató végigjárja az utat egy üres VPS-től egy Pterodactylen futó, automatizált, modolt szerverig, ami jól jelzi, mit ad a panelos megoldás.

Az ár egy második rendszer, amelyet javítani kell, és ez sosem ér véget. Egyetlen, hat barátot kiszolgáló vanilla szerverhez a panel több infrastruktúra, mint amennyire a játéknak szüksége van. A modok száma a másik változó, amelyet figyelni kell. Egy ARK-szerver modolása megmutatja, mit jelent ez a gyakorlatban. Mindent, ami nyilvános, védeni is kell, mielőtt valaki megtalálja, és a Minecraft-szerverek biztonsági útmutatója ezt a lépést tárgyalja.

AI-modellek futtatása és helyi következtetés

Az Ollama futtatja a modellt, az Open WebUI pedig a ráépített felület. A LiteLLM csak akkor érdemel helyet elöl, ha a hívásokat szolgáltatók között kell irányítani, a Qdrant pedig csak akkor, ha a visszakeresés része a tervnek.

GPU nélkül a plafon gyorsan elérkezik. Valaki, aki egy 8 GB-os, csak CPU-s VPS-en próbálta futtatni az Ollama modellfuttatót, memóriahiányos hibába ütközött: a modell 7,2 GiB-ot kért, és 3,8 GiB volt szabad, mert a különbséget már elfoglalta az operációs rendszer és a Coolify. A kis kvantált modellek, vagyis a kisebb memóriába férés érdekében alacsonyabb pontossággal tárolt súlyú modellek futhatnak CPU-n, ha a modell és a futtatókörnyezet elfér a rendszer RAM-jában. Ha elférnek, a szokásos ár a lassabb következtetés; ha nem, a folyamat memóriahiányos hibával leállhat.

A minőség a második korlát. Egy r/selfhosted szál arról, hogy megéri-e az Ollama saját üzemeltetése, a másik oldalt mutatja meg. Egy hozzászóló a kipróbált nyílt modelleket „rosszabb minőségűnek” nevezte, és azt mondta: „ezeket a milliárd dolláros óriásokat nem fogod legyőzni”. Ez egyetlen felhasználó tapasztalata, nem szabály minden nyílt modellre. A saját üzemeltetés kontrollt ad az adatok és az infrastruktúra felett; hogy minőségben vagy költségben legyőz-e egy hosztolt API-t, az a modelltől, a munkaterheléstől és a kihasználtságtól függ.

A költségszámítás egy hosztolt API-val szemben megmutatja, hol fordul meg a gazdaságosság. A nagyobb modellek, a nagyobb párhuzamosság vagy a szigorúbb késleltetési célok hardverkérdéssé teszik. A Cloudzy GPU VPS-csomagjai pontosan erre az esetre készültek.

Távoli asztal vagy felhőalapú munkaállomás

A „távoli asztal” kifejezés mögött három különböző mechanizmus rejtőzik, és ha termék neve alapján választ mechanizmus helyett, az emberek így kötnek ki a rosszal. Egy RDP-munkamenet valódi asztal, amely a szerveren fut, és amelyre bejelentkezik. A Cloudzy egykattintásos IceWM over XRDP képe itt a könnyű csomag: együtt szállítja az IceWM-et, a Terminatort, a Falkont és egy TLS-t használó xRDP-figyelőt, a Linux Mint pedig minimális helyett teljes asztalt ad.

A Kasm Workspaces igény szerint konténerizált alkalmazásokat és asztalokat tud biztosítani böngészőben, de a meglévő RDP-, VNC-, SSH- és KasmVNC-szervereket is elérhetővé teheti Server workspace-eken keresztül. A Neko megint más: egyetlen megosztott virtuális böngészőt közvetít WebRTC-n keresztül egy szobában lévő több embernek, és ez nem olyan asztal, amelyre bárki bejelentkezik.

Ha a szerver saját asztalát szeretné, konténeres workspace helyett RDP- vagy VNC-alapú Kasm Server workspace-t használjon. A Kasm fix infrastruktúráról szóló dokumentációja ismerteti ezt a beállítást. A Kasm natív konténeres munkamenetei különálló környezetek, nem a gazdagép asztala.

Ha a kívánt gép már létezik, és csak el kell érni, a RustDesk asztal felépítése nélkül eléri, a Sshwifty pedig shellt ad a böngészőben, ha csak egy shellre volt szüksége. Előbb a protokollról döntsön, csak utána a termék nevéről. A kapcsolódás RDP-n keresztül és egy böngészőmunkamenet közvetítése nem ugyanaz a dolog más címkével.

Fejlesztési, build- és CI-gép

A Code Server a VS Code-ot egy böngészőlapra teszi, amely a szerver fájlrendszerére mutat, és ez teszi érdemessé, hogy a gép többi részét együtt tartsuk: a Gitea vagy a Forgejo tárolja a szerkesztő által megnyitott repókat, a Jenkins futtatja a commitok által indított pipeline-okat, alattuk pedig a Docker. Az újabb elem a most ugyanazon a gépen futó AI-kódoló ügynökök: Claude Code, Aider, OpenCode és Goose CLI.

Ez a kézenfekvő felállás nem az egyetlen. Egy r/selfhosted szál a távoli fejlesztői környezetekről olyan választ hozott, amely az ellenkezőjét védte: tartsa helyben telepítve a szerkesztőt, és egy távoli fejlesztési bővítménnyel irányítsa a VPS-re, így a felület helyi marad, és csak a fájlok és a futtatás távoli. A szál indítójának panasza az volt, hogy a billentyűparancsokat a böngésző helyett a gazdagép kapta el, ami a böngészős változat valódi hátránya.

Mindkettő jogos. A Code Server futtatása AI-ügynökkel elejétől a végéig bemutatja a böngészős utat. A saját üzemeltetésű fejlesztői stack tartalmaz mindent, ami a szerkesztő körül van.

Automatizálás, botok és ütemezett feladatok

Az n8n a szokásos kiindulópont, és jó alapértelmezés: egy vizuális munkafolyamat-építő, ahol a csomópontok szolgáltatások, az élek pedig a köztük mozgó adatok. Az Activepieces hasonló munkát végez megengedőbb licenc alatt. A Node-RED a másik irányból közelít ugyanahhoz a problémához: folyamatalapú, és inkább eszközök és események összekötésében gyökerezik, mint SaaS-szolgáltatások összeragasztásában. A Dagu függőségi gráfok ütemezője, amely akkor illik, ha valójában cron-feladatok sorozata van, amelyeknek sorrend kell.

Ezek a szolgáltatások a feladatok között is futnak. Erőforrás-használatuk a munkafolyamatok aktivitásával nő, a megőrzött futtatási előzmények pedig főként az adatbázist és a tárhelyet növelik. Ez teszi őket olyan munkaterheléssé, amely csendben kinőheti a legkisebb szervert néhány hónappal azután, hogy minden rendben lévőnek tűnt. A saját üzemeltetésű Zapier-alternatívák összehasonlítása tartalmazza a licencelési részleteket és a méretezést.

Médiatartalmak kiszolgálása

Itt általában a tárhely az első korlát, de a transzkódolás a CPU- vagy GPU-kapacitást teheti döntővé. A Jellyfin a videóhoz, a Navidrome a zenéhez és az Audiobookshelf a hangoskönyvekhez és podcastokhoz egyaránt egy könyvtárszkennert, egy metaadat-letöltőt és egy streamingszervert egyesít egyetlen alkalmazásban, amely úgy települ, mint bármely más webszolgáltatás, az AzuraCast (webrádió) és az Immich (fotók) pedig ugyanezt a mintát követi.

Emiatt a VPS gyakrabban rossz forma, mint nem. Az azonnali transzkódolás processzoridőbe kerül, amelyből egy kis szervernek nincs feleslege, és egy otthoni, nagy lemezekkel rendelkező gép általában jobb gazda magának a könyvtárnak, a VPS pedig a távoli hozzáféréssel és a folyamatos elérhetőséggel érdemli ki a helyét. A Plex-alternatívák összehasonlítása végigveszi, melyik szerver melyik klienshez illik.

Ami Önre marad, ha minden telepítve van

Minden fent említett program egy feladattal együtt érkezik. Valaki javítja, figyeli a memóriáját, megújítja a tanúsítványát, és kideríti, hogy visszaállítható-e a mentés. Egy saját kezelésű VPS-en ez a valaki Ön, és a teher minden egyes olyan helyzettel nő, amely ugyanarra a gépre kerül.

A telepítési felét érdemes lerövidíteni. Ha a választott szoftver egykattintásos alkalmazásként elérhető, az lerövidíti a telepítési lépést, ahelyett hogy egy üres szerverrel és egy nyitott dokumentációs lappal hagyná magára. Egy Cloudzy Linux VPS megadja ezt a kiindulópontot, így az első óra arra megy, amiért a szervert megvásárolta. Az üzemeltetési fele mindenképp Önnél marad. Ezt a részt nem lehet kiszervezni.

Gyakran ismételt kérdések

Szükségem van vezérlőpultra egy VPS-en?

Csak ha egynél több feladatot végez el Ön helyett. Egy panel akkor érdemli ki a memóriáját, ha több webhelyet, több nem műszaki felhasználót, valamint levelezést vagy DNS-t kezel, amelyet egyébként kézzel állítana be. E küszöb alatt csak egy réteg Ön és egy olyan szolgáltatás között, amelyet közvetlenül is adminisztrálhatna, és a RAM-ért versenyez ezzel a szolgáltatással. A linuxos vezérlőpultok összehasonlítása részletezi, mennyibe kerül mindegyik funkciókban és licencekben.

Dockerrel vagy natívan telepítsek szoftvert egy VPS-re?

Használjon konténereket több szolgáltatásból álló stackekhez, más gazdagépre költöztetni kívánt munkaterhelésekhez, vagy olyan függőségekhez, amelyek egyébként ütköznének. Telepítsen natívan, ha egyetlen hosszú életű szolgáltatást egy kis VPS-en így könnyebb kezelni. Egy 1 GB-os szerver, amely egy webszervert és egy adatbázist futtat, nem feltétlenül profitál a Dockerből; egy nagyobb, több szolgáltatásból álló stack gyakran igen, de ezt nem egyedül a RAM dönti el.

Futtathatok AI-modellt GPU nélküli VPS-en?

Igen, kis kvantált modellek esetén. A RAM dönti el, hogy a modell betölthető-e az operációs rendszer és minden más futó folyamat mellé; a CPU teljesítménye határozza meg, milyen gyorsan fut betöltés után. A nagyobb modellek, a nagyobb párhuzamosság vagy a szigorúbb késleltetési célok általában elegendő VRAM-mal rendelkező GPU felé terelik.

Kell Windows egy trading VPS-hez?

A MetaTrader 4 és a MetaTrader 5 esetében a Windows a legegyszerűbb natív lehetőség, nem szigorú követelmény. A MetaQuotes a MetaTrader Linuxon, Wine-on keresztüli futtatását is támogatja. Más trading munkaterhelések, köztük a Python-alapú algoritmikus eszközök és az olyan kriptofizetési szoftverek, mint a BTCPay Server, közvetlenül Linuxon futhatnak. Az operációs rendszerről az a platform dönt, amelyen keresztül kereskedik.

Futtathat egy VPS több ilyen felhasználási módot is?

Igen, és általában a memória korlátozza, hogy hányat. Néhány könnyű szolgáltatás megfér egymás mellett 4 GB-on, míg egy játékszerver és egy AI-modell gyorsan versenyezhet a RAM-ért. A másik szempont a kárhatás sugara: ha egy nyilvánosan elérhető szolgáltatást olyasmi mellé tesz, ami fontos Önnek, egy behatolás mindkettőt veszélybe sodorhatja. Válassza el az internet felé nézőt a fontostól, mielőtt bármi mást szétválasztana.