A legjobb saját üzemeltetésű CIAM B2B SaaS-fejlesztőknek

Ha megnézte néhány SaaS CIAM-platform árazását, valószínűleg feltűnt, milyen drágák tudnak lenni, és nagy eséllyel elgondolkodott egy saját üzemeltetésű megoldáson.

Ez a cikk arról a négy saját üzemeltetésű CIAM-platformról szól, amelyet egy kis B2B SaaS-csapat valóban el tud látni anélkül, hogy második főállássá válna: ZITADEL, FusionAuth, Logto és Ory Hydra. Nem mind azonos felépítésű, és hogy melyik a jó Önnek, kevésbé függ egy funkciólistától, sokkal inkább attól, milyen B2B terméket épít. Egy héten át futtattam őket egymás mellett egyetlen VPS-en, hogy összeállítsam ezt az összehasonlítást, és az alábbi az a változat, amelyet elküldenék egy alapítónak, aki CIAM-ügyben ír nekem.

Egy dolgot előre: itt a CIAM mint termékfunkció a téma, nem a saját csapatnak szóló belső SSO.

A rövid verzió

Négy saját üzemeltetésű CIAM-platform, egy-egy sorban:

• ZITADEL ha több-bérlős működést és B2B szervezeteket szeretne, dobozból kibontva.
• FusionAuth ha kidolgozott admin felületet és hosszú, kiszámítható kiadástörténetet szeretne.
• Logto ha az első napon a legtisztább fejlesztői élményt szeretné.
• Ory Hydra ha protokollszinten fejleszt, és az OAuth 2.0 motorra van szüksége, nem egy kész bejelentkezési alkalmazásra.

Röviden: egy tipikus B2B SaaS esetében a ZITADEL a legbiztonságosabb első választás, a cikk többi része pedig ezt az érvelést bontja ki.

Miért más döntés a CIAM, mint a munkatársi SSO

Ha a belső csapat SSO-ja leáll, a kár általában behatárolt. A mérnökök talán egy órára elveszítik a hozzáférést a Grafanához vagy egy másik belső eszközhöz. Ha a CIAM áll le, a fizető ügyfelek egyáltalán nem tudnak belépni a termékbe. Ezzel a kérdés átfordul arról, hogy „melyik hitelesítési eszköz kényelmes a csapatunknak?”, arra, hogy „melyik hitelesítési rendszerben bízhatunk meg magának a terméknek a részeként?”

A CIAM, vagyis az a fajta identitásinfrastruktúra, amire egy B2B SaaS-nak szüksége van, olyan alapelemeket is igényel, amelyeket sok munkatársi SSO-eszköz nem helyez előtérbe. Az ügyfele nem egyetlen felhasználó, hanem egy szervezet (egy tenant), saját felhasználókkal, szerepkörökkel, arculattal és esetleg saját SAML-kapcsolattal egy vállalati IdP felé. Nem csupán embereket hitelesít, hanem az egyik cég felhasználóit különíti el a másikétól ugyanazon a terméken belül. Az alábbi négy eszköz erre a B2B alakra céloz, mindegyik a maga módján. A Keycloak mostanra teljes értékű Organizations funkciót kapott, így elintézni azzal, hogy csak munkatársi célra való, elavult lenne; a kihagyását a GYIK-ban magyarázom.

Az építés, vásárlás és saját üzemeltetés háromszöge itt is másképp fest. Az OAuth nulláról való megírása felesleges hiba. Ön SaaS-terméket szállít, nem identitásszolgáltatót. Menedzselt szolgáltatást venni (Auth0, Clerk, WorkOS) akkor helyes döntés, ha a csapatnak nulla üzemeltetési kapacitása és józan költségvetése van. Egy kétfős startupnak soha nem javasolnám, hogy az első napon saját maga üzemeltesse a hitelesítést. A saját üzemeltetés akkor válik ésszerűvé, amikor a menedzselt CIAM MAU-alapú ára meghaladja az infrastruktúra költségét plusz a folyamatos mérnöki időt, vagy amikor közvetlen kontrollra van szüksége a telepítés és az adatsík felett. Az általam ismert csapatoknál ez a pont általában a „van egy igazi termékünk” és a „van egy igazi customer success csapatunk” közé esik.

Ha a saját alkalmazásaihoz keres SSO-t, nem az ügyfelei alkalmazásaihoz, az egy másik összehasonlítás, nem ez. Térjünk át a favoritjainkra.

A négy eszköz, egyenként

Azért ezt a négyet választottam, mert eléggé CIAM-alakúak ahhoz, hogy termékinfrastruktúraként lehessen értékelni őket, ne csak belső SSO-ként. A ZITADEL, a FusionAuth, a Logto és az Ory mind valódi saját üzemeltetési utat és elég lendületet kínál ahhoz, hogy komolyan vegyük. A csak könyvtárként létező, a munkatársi SSO-ra hangolt és a kevésbé érett megoldások jobb helyen vannak a GYIK-ban.

ZITADEL

A ZITADEL egy svájci fejlesztésű, Go nyelven írt identitásplatform, event-sourced architektúrával és PostgreSQL háttérrel. 2026. július 27-i állapot szerint a legfrissebb GitHub-kiadása a the 4.16 series, current as of July 2026. A ZITADEL a v3-tól kezdve Apache 2.0-ról AGPL-3.0-ra váltott; normál SaaS-használat mellett a gyakorlati hatás általában kevésbé ijesztő, mint amilyennek hangzik, a részleteket a GYIK-ban tárgyalom.

Mi teszi a ZITADEL-t különlegessé B2B SaaS esetén: a szervezetek és a több-bérlős működés elsőosztályú alapelemek, nem olyan funkciók, amelyeket általános objektumokból raksz össze. Létrehoz egy Organization-t, az saját felhasználókat, szabályokat, arculatot és hozzáférési beállításokat kap, és projekteket rendelhet hozzá, hogy az adminjai maguk kezeljék a saját felhasználóik szerepkiosztását. Nem kell az általános felhasználók fölé kitalálnia a „bérlő” fogalmát. Eleve azzal indul.

A fejlesztői élmény API-first: a jelenlegi v2 REST erőforrás-API-k mellett gRPC és REST hozzáférés is van a régi v1 szolgáltatásokhoz. Hivatalos és közösségi SDK-k fedik le a bevett szerveroldali stackeket. Az admin konzol működőképes, de visszafogottabb, mint a FusionAuth-é.

Az én olvasatom: Ha B2B SaaS-t épít, és tudja, hogy bérlői lesznek, én a ZITADEL-lel kezdenék. A saját üzemeltetésű lehetőségek közül ez az, amelyik a legegyértelműbben a B2B bejelentkezési probléma köré épült.

FusionAuth

A FusionAuth az Inversoft, LLC (egy Delaware-i LLC, FusionAuth néven működve) egyesült államokbeli platformja, amely régebb óta van a piacon, mint a másik három, és ez jó értelemben látszik is. Az admin felület érezhetően megtervezettebb a többinél, a dokumentáció érett, a kiadási ütem pedig kiegyensúlyozott, nem hajszolt. Ha valaha örökölt egy négyéves hitelesítési integrációt, és magában megköszönte az előző mérnöknek, hogy az unalmas opciót választotta, akkor a FusionAuth az a CIAM-változat, amely kiérdemli ezt a köszönetet.

A licencelés az, amin sokan felbuknak: a FusionAuth Community ingyenesen üzemeltethető saját szerveren, de a termék magja nem nyílt forráskódú. A terméket a következő szabályozza: a FusionAuth saját licence, és ezek a korlátok akkor számítanak, ha újraterjeszteni, beágyazni, átmárkázni, továbbértékesíteni vagy a saját ügyfelei számára üzemeltetni szeretné a FusionAuth-t. A saját üzemeltetésű Community változat lefedi a B2B SaaS alapesetét; a fizetős csomagok további funkciókat adnak például IdP által kezdeményezett SAML, fejlett MFA és alkalmazásspecifikus témák, míg a SCIM, a Tenant Manager és az alkalmazásszintű MFA-szabályok az Enterprise csomagban vannak.

A B2B alakról: a FusionAuth bérlőket és alkalmazásokat modellez, de az absztrakció inkább „bérlőnkénti konténerizált hitelesítés”, mint „B2B szervezetek mint tartományobjektum”. Működik (szállítottam rá termékeket), de a több-bérlős működés inkább elszigetelési alapelemnek hat, mint teljes értékű B2B modellnek. A hivatalos SDK-k és kliens könyvtárak széles kínálatot adnak:

• Angular
• React
• Vue
• iOS
• Android
• Go
• Java
• .NET
• PHP
• Python
• Ruby
• TypeScript

A szerveroldali könyvtárak vékony API-kliensek. Az admin konzolt a többihez képest könnyebb átadni egy nem mérnök üzemeltetőnek.

Az én olvasatom: Ha a csapata többre értékeli a letisztult felületet és a hosszú, kiszámítható múltat, mint a natív B2B alapelemeket, akkor FusionAuth. Ez a lista legunalmasabb választása, és ez dicséret.

Logto

A Logto a négy közül a legújabb, a Silverhand Inc. fejleszti, és MPL-2.0 licenc alatt áll, és ez az, amelyiknek a legláthatóbban fontos a saját irányítópultja. Az első napi beüzemelés viszonylag gyors. Kiépíti, végigkattint a varázslón, és nagyjából tizenöt perc alatt működő OIDC-szolgáltatója van, tisztességes alapértelmezett bejelentkezési felülettel (megmértem azon a héten, amikor mind a négyet egymás mellett futtattam). A hivatalos gyorsindítók lefedik a modern keretrendszereket és szerveroldali stackeket, tehát ha a stackje „Next.js + Postgres + valami”, otthon fogja érezni magát.

A B2B-válasza a következő nevet viseli: Logto Organizations. Lefedi az alapvető B2B alapelemeket: szervezeti tagság, szervezeti hatókörű szerepkörök, tagmeghívók, just-in-time kiépítés és vállalati SSO-integráció. A szervezeti modell fiatalabb, mint a ZITADEL-é, ezért minden szokatlan SAML-, SCIM- vagy föderációs folyamatot letesztelnék a célügyfeleivel, mielőtt elköteleződik.

A kompromisszum az érettség: a Logto itt a legújabb lehetőség. Az ütemterv gyorsan halad, ami nagyszerű, amikor egy szükséges funkció megérkezik, és kényelmetlen, amikor egy törő változtatás. Ha a B2B SaaS-a a több-bérlős spektrum egyszerűbb végén van (kevés szervezet és semmi egzotikus föderációs igény), a Logto fejlesztői élménye megkönnyíti a döntés többi részét.

Az én olvasatom: Ha a leggyorsabb első napot szeretné, és a B2B igényei egyelőre viszonylag egyszerűek, akkor Logto.

Ory Hydra (és az Ory stack)

Az Ory Hydra az Ory ökoszisztéma OAuth 2.0 / OpenID Connect kiszolgálója, Apache-2.0 licenc alatt. A teljes Ory stack a Hydra mellé teszi az Ory Kratos-t (identitás- és felhasználókezelés, önkiszolgáló bejelentkezés, regisztráció, MFA és fiók-visszaállítás), az Ory Keto-t (Zanzibar stílusú engedélyezési kiszolgáló, amely szabálydöntési pontként működik) és az Ory Oathkeeper-t (identitás- és hozzáférési proxy, amely hitelesíti, engedélyezi és módosítja a bejövő HTTP-kéréseket). Azt rakja össze, amire szüksége van. Minden Go nyelven íródott, és az API-k tiszták.

A bökkenő (és ez nem hiba; a megfelelő csapatnak inkább erény), hogy a Hydra a motor, nem az alkalmazás. Tervezésénél fogva a Hydra egy külön bejelentkezési és hozzájárulási alkalmazáshoz csatlakozik , amelyet Ön biztosít. Ha kész bejelentkezési képernyőt szeretne, ez nem az az eszköz. Ha viszont olyasmit épít, ahol a hitelesítési folyamat a termék része (fejlesztői platform, egyedi B2B portál vagy saját onboardinggal rendelkező API-first termék), akkor épp az előírt felület hiánya az, amit akar.

A B2B történet nem kulcsrakész, hanem összeállítható. A több-bérlős működést úgy modellezheti, hogy Kratos sémákat és Keto relációkat köt a saját szervezeti rétegéhez, és ez működik is, csak a bekötést Ön végzi. Az ára több vezetékezés, a haszna az élmény feletti kontroll. Az Ory dokumentációja mélyen lefedi a protokollfelületet, de az összeállítható modell feltételezi, hogy szívesen hoz protokollszintű döntéseket. Ha az „audience claim” vagy a „PKCE” semmit nem mond Önnek, kezdje a másik hárommal.

Az én olvasatom: Ha protokollszinten épít valamit (hitelesítési átjárót, egyedi folyamatokat, fejlesztői platformot), és a szokásos alkalmazások szűknek érződnek, az Ory a jó válasz. Egy tipikus B2B SaaS-nak, amely ma szeretne működő bejelentkezést, nem az.

Az összehasonlítás egy pillantásra

Íme a négy eszköz összefoglalója egyetlen táblázatban: a második átolvasáshoz hasznos, a fenti profilok elolvasását nem helyettesíti.

Melyikkel érdemes kezdeni?

Négy rövid forgatókönyv, amely lefedi a legtöbb csapatot, amellyel erről beszélnék.

B2B SaaS-t épít, és tudja, hogy bérlői lesznek. Kezdje a ZITADEL-lel. A több-bérlős működés és a szervezeti alapelemek pontosan erre készültek, az API-felület átfogó, és kevesebb időt tölt a bérlőmodell kitalálásával, mint a másik háromnál. Az AGPL-re váltás megérdemel egy licencátvizsgálást, de egy módosítatlan, külön integrált telepítés általában egyszerű SaaS-forgatókönyv.

A kidolgozott admin felületet és egy stabil, kiszámítható platformot szeretné. FusionAuth. A Community csomag sok csapat alapigényeit lefedi; szánjon időt a licenc és a funkciómátrix alapos elolvasására. Az olyan funkciók, mint az IdP által kezdeményezett SAML, a fejlett MFA és az alkalmazásspecifikus témák fizetős csomagot igényelnek, míg a SCIM, a Tenant Manager és az alkalmazásszintű MFA-szabályok az Enterprise csomagban vannak.

A B2B igényei ma egyszerűek, és a leggyorsabb első napot szeretné. Logto. Az első napi fejlesztői élménye volt a leggyorsabb az összehasonlító tesztemben. Fogadja el, hogy egy fiatalabb ökoszisztémára tesz, és gondolja újra a döntést, ha az igényei olyan föderációs peremesetekké nőnek, amelyeket nem tesztelt.

Olyasmit épít, ahol a hitelesítési folyamatok a termékélmény részei. Ory Hydra (plusz Kratos, plusz Keto, ha jogosultságok kellenek). Több kódot fog írni. Több kontrollja lesz. Ha ez a csere nem magától értetődő Önnek, akkor nem Ön az Ory közönsége. Válassza a másik hármat.

Ha kettő is ráillik ezek közül, alapértelmezésben válassza a ZITADEL-t. Ez illik a legszélesebb körben, és ezt adnám egy kis alapítói csapat kezébe sok további kérdés nélkül.

Mibe kerül a saját üzemeltetés (működési szempontból)

Most jön a cikk kevésbé romantikus része.

A PostgreSQL mentési fegyelme mostantól olyasmi, amitől az üzlete függ. Ezekben a telepítésekben a védendő identitásállapot magában foglalhat felhasználói rekordokat, hash-elt hitelesítő adatokat, MFA-titkokat, OAuth kliens hitelesítő adatokat és munkamenet-adatokat. Ha ez az állapot elvész, az ügyfelei elveszíthetik a bejelentkezés lehetőségét. Állítson be automatikus mentéseket még az első valódi felhasználó regisztrációja előtt, tesztelje a visszaállítást, és a mentések állapotát tegye ugyanabba a riasztási csatornába, mint az alkalmazás rendelkezésre állását.

A kiadási tempó idővel változik. A ZITADEL v4.16.1 2026. július 17-én jelent meg, több júniusi kiadás után, és itt minden projekt a saját ütemét és kompatibilitási politikáját tartja. Kezelje ezt az ütemet karbantartási kérdésként, ne a minőség megítélésének rövidítéseként. Olvassa el a kiadási jegyzeteket, mielőtt lefuttatja a docker compose pull parancsot, és ütemezzen visszatérő javítási ablakot. Ha hónapokig kihagyja az identitásszolgáltató frissítéseit, az első komoly átvilágításnál lemaradhat a biztonsági és kompatibilitási javításokról.

A hétköznapi dolgok, amelyek mindig hátulról érkeznek: a TLS-tanúsítványok megújítása (használjon fordított proxyt Let's Encrypt-tel, automatizálja a megújítást, és riasszon hibára), a kimenő levelező beállítása a visszaigazoló és jelszó-visszaállító levelekhez (SES, SendGrid, Postmark: válasszon egyet, és állítsa be rendesen az SPF/DKIM/DMARC rekordokat, különben a jelszó-visszaállító levelek a spamben kötnek ki), az OAuth kliens hitelesítő adatok cseréje, amikor egy mérnök távozik, és a bejelentkezési végpontok forgalomkorlátozása, hogy egy credential stuffing támadás ne szögezze le a processzort.

Profi tipp: ha menedzselt Postgres-t használ, ne feltételezze, hogy a futásidejű adatbázis-felhasználó a sémát is létre tudja hozni. Hozza létre előre az adatbázist és a felhasználót, adja meg a szükséges tulajdonosi vagy telepítési jogokat, és az első beállítást azokkal a hitelesítő adatokkal futtassa, amelyeket az adott eszköz vár. Különben az első futás egy homályos adatbázis-jogosultsági hibával elhasalhat, és egy órát eléget rossz nyomon.

Amit a saját üzemeltetés dollárban megspórol, azt tulajdonlásban kéri vissza. A telepítés után tervezzen be havi néhány mérnökórát az identitásréteg egészségben tartására. Azok a csapatok, amelyek nulla időt szánnak rá, a költséget általában később fedezik fel: egy kiesés közben, egy furcsa SAML peremesetnél vagy az első biztonsági átvilágításon.

Hol érdemes telepíteni

Egy Docker Compose-t futtató Linux VPS ésszerű kiindulópont lehet kiértékeléshez és szerény terheléshez, de a produkciós méretezés és a magas rendelkezésre állás a forgalomtól, a biztonsági követelményektől és a leállástűrésétől függ. Így helyezkednek el a szokásos telepítési lehetőségek:

• Megosztott tárhely egyiket sem tudja futtatni. Perzisztens tárolóra, egyedi portokra, root hozzáférésre a konténerfuttatáshoz és valódi adatbázis-háttérre van szükségük. A lista nagy részénél a PostgreSQL az alapértelmezett út, de szó szerint nem ez az egyetlen támogatott adatbázis minden eszköznél.
• Kubernetes mind a négyet futtatni tudja, de a gyártói út egyenetlen. ZITADEL, FusionAuth, és Ory saját Helm chartokat tesznek közzé, míg a Logto saját üzemeltetési dokumentációja a Docker és a virtuálisgép-alapú telepítésre koncentrál. Egy kis B2B SaaS-nak, amely még nem jutott el odáig, hogy a Kubernetes máshol megtérüljön, ez rendszerint túltervezés. Akkor nyúljon hozzá, amikor az infrastruktúrája többi része már ott fut.
• Bare metal rendben van, ha már úgyis azon fut. A legtöbb B2B SaaS-csapat nem.

Egy kis, egycsomópontos próbaüzemnél 4 GB RAM-ról, 2 vCPU-ról és 60 GB NVMe tárhelyről indulnék, majd terheléstesztelném a valódi bejelentkezési folyamatot. Ez tervezési alap, nem univerzális produkciós minimum. Az alkalmazások viszonylag könnyűek, de a PostgreSQL memóriát, a jelszó-hashelés pedig CPU-tartalékot igényel. A ZITADEL produkciós útmutatója azt ajánlja, hogy négy CPU-mag legyen elérhető a jelszó-hashelési csúcsokra.

Ha a termék valóssá vált és a forgalom tartós, mérések alapján méretezzen újra. A gyors tároló a PostgreSQL késleltetésén segít, míg a CPU-tartalék az egyidejű jelszó-hashelésnél számít. Figyelje a memóriát, az adatbázis I/O-t, a bejelentkezési késleltetést és a CPU telítettségét, ahelyett hogy feltételezné, egyetlen erőforrás számít a legjobban.

A CIAM éles üzemeltetése azt jelenti, hogy a rendelkezésre állása mostantól az Ön gondja. Mi ilyen terheléshez Cloudzy Linux VPS példányokat futtatunk, NVMe tárolóval és 99,95%-os rendelkezésreállási SLA-val az alapul szolgáló platformon. A Cloudzy emellett kínál egy egykattintásos ZITADEL VPS-t ha inkább kihagyná a kezdeti kiépítő szkriptet; a másik három hivatalos konténerképeket kínál Docker-alapú telepítéshez. Vezetői szintű képet arról, hogyan illeszkedik a hozzáférés-vezérlés a biztonsági helyzete többi részéhez, az IAM bevált gyakorlatok útmutató veszi végig a témát a szabályzatok felől.

Gyakran ismételt kérdések

Érinti a ZITADEL AGPL licence a SaaS-omat?

Módosítatlan, külön integrált telepítés esetén általában nem, de ez nem jogi tanácsadás. A ZITADEL AGPL-kötelezettségei magára a ZITADEL-re vonatkoznak. Ha módosítja a ZITADEL-t, és azt a módosított változatot hálózati szolgáltatásként üzemelteti, a licenc előírhatja, hogy a megfelelő forráskódot AGPL alatt tegye elérhetővé. A ZITADEL közzétett álláspontja szerint egy módosítatlan példány puszta használata a SaaS-a identitásszolgáltatásaként önmagában nem kötelezi arra, hogy a különálló alkalmazását AGPL alatt licencelje. Olvassa el a ZITADEL licencbejelentését és kérjen jogi tanácsot, ha módosítja, továbbterjeszti, beágyazza vagy harmadik feleknek kínálja a szoftvert. Kereskedelmi licenc is elérhető.

Miért nincs a listán a Keycloak vagy az Authentik?

A Keycloak és az Authentik kiváló saját üzemeltetésű identitáseszközök (magam is használom őket), de a Keycloak-ot azért kihagyni, mert hiányoznak belőle a B2B szervezetek, ma már téves lenne: a jelenlegi Keycloak-kiadások tartalmaznak Organizations funkciót, szervezeti csoportokat és delegált adminisztrációs vezérlőket. Azért hagytam ki, mert ez az összehasonlítás négy olyan lehetőségre koncentrál, amely közvetlenebb utat kínál egy kis csapatos B2B SaaS-nak; a Keycloak saját kiértékelést érdemel, ha a JVM-üzemeltetés, az ökoszisztéma mélysége és a realm-szintű rugalmasság számít. Az Authentik továbbra is jobban illik a munkatársi és belső alkalmazásokhoz kapcsolódó SSO-hoz, mint a termékbe épített bérlőmodellezéshez.

Olcsóbb a saját üzemeltetés, mint az Auth0?

Alacsony MAU mellett gyakran nem. A mérnökórái többe kerülnek, mint az Auth0 számlája a korai startup szinten. A saját üzemeltetés gazdaságilag ott nyer, ahol a menedzselt CIAM MAU-alapú ára meghaladja egy kis VPS és a havi néhány mérnökóra együttes költségét. A pontos megtérülési pont a csapata óradíjától, a MAU növekedési görbéjétől és attól függ, hogy a terméknek szüksége van-e olyan vállalati funkciókra, amelyek az Auth0 drágább csomagjaiba tolják. Tekintse a megtakarítást valósnak, de nem azonnalinak.

Mekkora a minimális VPS-méret egy éles CIAM-hoz?

Egy kis, egycsomópontos próbaüzemhez 4 GB RAM, 2 vCPU és NVMe tároló ésszerű kiindulópont, nem produkciós garancia. Az adatbázis méretéből, az egyidejű bejelentkezési terhelésből, a jelszó-hashelés költségéből és a rendelkezésre állási célból méretezzen. A ZITADEL saját produkciós útmutatója négy elérhető CPU-magot javasol a hashelési csúcsokra; más eszközök és forgalmi minták saját terhelésteszteket igényelnek.

Áttérhetek később menedzselt CIAM-ról saját üzemeltetésre?

Igen, de tervezze meg valódi projektként. A jelszó-visszaállítás nem elkerülhetetlen: az exportálhatóság és a támogatott hash-formátumok eltérnek, és egyes célrendszerek támogatják a tömeges vagy just-in-time felhasználómigrációt , míg mások visszaállítást követelnek. Az MFA-faktorok, az OAuth kliensek, az aktív munkamenetek, az e-mail-ellenőrzési állapot és a bérlő- vagy szerepkör-leképezések külön kezelést igényelnek. Ha már most gyanítja, hogy később saját üzemeltetésre vált, jegyezze fel ezeket az export- és migrációs korlátokat, mielőtt kiválasztja a menedzselt szolgáltatót.