একটি VPS-এ Keycloak বনাম authentik বনাম Zitadel

একটি VPS-এর জন্য কোন SSO server উপযুক্ত

Keycloak, authentik এবং Zitadel হলো self-hosted single sign-on (SSO) server। সার্ভারের প্রতিটি app-এ একই login ব্যবহারের প্রয়োজন হলে সাধারণত এই server-গুলোর কথা আসে। একটি ছোট VPS-এ এগুলো একে অপরের সরাসরি বিকল্প নয়। তিন বা চারটি self-hosted app চালানো VPS-এর জন্য authentik নিরাপদ default। কারণ এই তিনটির মধ্যে এটিই একমাত্র server, যা নিজস্ব login ব্যবস্থা না থাকা app-এর সামনে login screen বসাতে পারে। আপনি যে app-গুলো সুরক্ষিত করবেন, সেগুলো যদি ইতিমধ্যে standard protocol সমর্থন করে এবং Java virtual machine (JVM)-এর জন্য পর্যাপ্ত memory বরাদ্দ করতে পারেন, তাহলে Keycloak উপযুক্ত। Zitadel API-এর মাধ্যমে product release করার জন্য developer-দের লক্ষ্য করে তৈরি। 4 GB-এর কম memory-তে আমি এটি চালানোর চেষ্টা করব না।

আগে পছন্দ ঠিক করুন, তারপর install করুন। পছন্দ করার পর VPS-এ authentik install করার ব্যবহারিক নির্দেশনা ধাপে ধাপে setup প্রক্রিয়া দেখায়।

প্রতিটির বাস্তবে কত RAM প্রয়োজন?

প্রথমে resource floor দেখুন, কারণ কোনো feature বিবেচনা করার আগেই এটি সম্ভাব্য তালিকা নির্ধারণ করে। নিচের সংখ্যাগুলো প্রতিটি project-এর নিজস্ব প্রকাশিত তথ্য, যা August 2026-এ পর্যালোচনা করা হয়েছে। এগুলো vendor-এর নির্দেশনা; load test-এর ফল নয়।

[
  {
    "label": "authentik",
    "vendor_min_ram_mb": 2048,
    "base_containers": 3
  },
  {
    "label": "Keycloak",
    "vendor_min_ram_mb": 1250,
    "base_containers": 2
  },
  {
    "label": "Zitadel",
    "vendor_min_ram_mb": 2048,
    "base_containers": 4
  }
]

authentik-এর Docker Compose install page-এ "a host with at least 2 CPU cores and 2 GB of RAM" চাওয়া হয়েছে। অর্থাৎ 2048 MB। প্রকাশিত compose file-এ 3টি container চলে: PostgreSQL, server এবং worker।

Keycloak 3টির মধ্যে সবচেয়ে নির্দিষ্ট সংখ্যা প্রকাশ করেছে। তার sizing guide-এ বলা হয়েছে, "the base memory usage for a Pod including caches of Realm data and 10,000 cached sessions is 1250 MB of RAM"। এই 1250 MB শুধু Java process-এর জন্য; database এতে ধরা নেই। একই page-এ ব্যাখ্যা করা হয়েছে, container limit কেন এত গুরুত্বপূর্ণ: Keycloak memory limit-এর 70% heap হিসেবে নেয় এবং এর বাইরে প্রায় 300 MB non-heap memory ব্যবহার করে। Container-কে 1 GB দিলে এটি প্রায় 717 MB heap নির্ধারণ করে, কিন্তু তার সঙ্গে আরও 300 MB non-heap memory প্রয়োজন হয়। ফলে session data cache-এ ঢোকার আগেই limit শেষ হয়ে যায়।

Zitadel-এর compose page-এও 2 GB, অর্থাৎ একই 2048 MB, চাওয়া হয়েছে। তবে এই সংখ্যা প্রথমবার চালানোর জন্য। Production page-টিই দেখা উচিত। Zitadel process-এর নিজের জন্য "approximately 512MB of RAM and can operate with less than one CPU core" প্রয়োজন। ব্যয়বহুল অংশ হলো database: "about one CPU core per 100 requests per second (req/s) and 4GB of RAM per core"। Password hashing-এর জন্য "4 CPU cores available for this purpose" দরকার, কারণ login-এর চাপ CPU usage হঠাৎ বাড়িয়ে দেয়। Official v4 compose-এ অতিরিক্ত কিছু যোগ করার আগে 4টি container চলে: proxy হিসেবে Traefik, Zitadel API, আলাদা Login UI container এবং PostgreSQL। Redis এবং OpenTelemetry collector optional compose profile-এর মাধ্যমে চালানো যায়।

তাই Keycloak এবং authentik 4 GB VPS-এ চলতে পারে, এবং আপনি যে app-গুলো সুরক্ষিত করছেন সেগুলোর জন্যও কিছু memory অবশিষ্ট থাকে। Zitadel 2 GB-এ start করবে, কিন্তু প্রতিটি login-এর সময় নিজের PostgreSQL-এর সঙ্গে memory ভাগ করবে। আমি Zitadel 4 GB-এর কম memory-তে চালাব না। একই server-এ app-ও host করলে আমি 8 GB চাইব।

প্রতিটি আপনার সার্ভারে আসলে কী চালায়

authentik হলো PostgreSQL এবং একই image-এর দুটি কপি—একটি server ও একটি worker। server HTTP অনুরোধের উত্তর দেয় এবং একটি embedded outpost চালায়। worker directory sync ও email-এর মতো background task চালায়। প্রকাশিত install নির্দেশনা সংক্ষিপ্ত।

wget https://docs.goauthentik.io/compose.yml
echo "PG_PASS=$(openssl rand -base64 36 | tr -d '\n')" >> .env
echo "AUTHENTIK_SECRET_KEY=$(openssl rand -base64 60 | tr -d '\n')" >> .env
docker compose pull
docker compose up -d

server 9000 এবং 9443 port প্রকাশ করে। 9000 port-এ প্রথমবার গেলে initial setup flow চালু হয়। সেখানে default akadmin user-এর password সেট করেন। ওই port Internet থেকে পৌঁছানো যায় এমন করার আগে সামনে একটি বৈধ certificate-সহ reverse proxy বসান।

Keycloak হলো একটি process এবং আপনার দেওয়া একটি database। quickstart-এ একটি মাত্র container থাকে।

docker run -p 127.0.0.1:8080:8080 \
  -e KC_BOOTSTRAP_ADMIN_USERNAME=admin \
  -e KC_BOOTSTRAP_ADMIN_PASSWORD=admin \
  quay.io/keycloak/keycloak:26.7.1 start-dev

start-dev ঘুরে দেখার জন্য। এটি একটি local development database এবং TLS (transport layer security) ছাড়া চলে। তাই এভাবে চালু করা container পরে সরিয়ে ফেললে তার realm-ও হারাবেন। Production-এর জন্য এর পরিবর্তে start ব্যবহার করুন। এতে KC_DB-এর মাধ্যমে একটি প্রকৃত PostgreSQL এবং KC_HOSTNAME-এর মাধ্যমে একটি public hostname দিতে হয়। Keycloak-এর production guide-এ আরও বলা আছে, server-এ আসা ও server থেকে যাওয়া সব communication-এর জন্য secure channel প্রয়োজন। তাই সেখানে HTTPS ঐচ্ছিক নয়।

Zitadel হলো উপরে বর্ণিত চার-container stack।

mkdir zitadel-compose && cd zitadel-compose
curl -fsSLO https://raw.githubusercontent.com/zitadel/zitadel/main/deploy/compose/docker-compose.yml
curl -fsSLO https://raw.githubusercontent.com/zitadel/zitadel/main/deploy/compose/.env.example
cp .env.example .env
docker compose up -d --wait

প্রথমবার start করার আগে .env-এ ZITADEL_MASTERKEY সেট করুন। এটি database-এ secret encrypt করতে Zitadel যে 32 character key ব্যবহার করে। তাই এটি হারালে ওই secret-গুলিতে access হারাবেন। আপনি যদি এই ধরনের stack চালানোর কাজে নতুন হন, VPS-এর জন্য Docker Compose-এর মৌলিক বিষয়গুলো পড়ুন। সেখানে volume এবং restart-policy সংক্রান্ত সেই পছন্দগুলো ব্যাখ্যা করা হয়েছে, যেগুলো নির্ধারণ করে reboot-এর পর আপনার identity provider চালু থাকবে কি না।

প্রতিটি কোন protocol সমর্থন করে?

তিনটিই OpenID Connect (OIDC) সমর্থন করে। এটি OAuth 2.0-এর ওপর নির্মিত login layer, যা আধুনিক app ব্যবহার করে। তিনটিই SAML 2.0 (security assertion markup language) সমর্থন করে। এটি পুরোনো standard, যা enterprise software এখনও release করে। প্রকৃত পার্থক্য LDAP (lightweight directory access protocol) নিয়ে। এখানে একই শব্দ দুটি বিপরীত কাজ বোঝায়।

LDAP থেকে পড়া বলতে বোঝায়, SSO server আপনার আগে থেকেই চালু থাকা directory-এর বিরুদ্ধে password যাচাই করে। Keycloak এটি user federation-এর মাধ্যমে করে। Zitadel-ও তা করতে পারে। এর documentation-এ ZITADEL-এ "connect an LDAP server as an identity provider" করার পদ্ধতি বর্ণনা করা হয়েছে।

LDAP পরিবেশন করা বলতে বোঝায়, শুধু LDAP সমর্থনকারী কোনো app আপনার SSO server-এ এমনভাবে bind করতে পারে, যেন সেটিই directory। এই কাজটি কেবল authentik করে। এর LDAP provider একটি dedicated LDAP outpost-এর মাধ্যমে "all users and groups in authentik's database searchable via the LDAP directory" করে। LDAPS port 636-এ available। এটি read-only। তাই bind এবং search কাজ করে, কিন্তু write কাজ করে না। password-এর শেষে semicolon দিয়ে একটি one-time code যোগ করতে হয়, যেমন password;123456। bind চলাকালে SMS authenticator সমর্থিত নয়।

আপনার তালিকায় কোনো app যদি শুধু LDAP সমর্থন করে, তাহলে তুলনা এখানেই শেষ। Keycloak এবং Zitadel ওই bind-এর উত্তর দিতে পারে না। তাই তাদের পাশাপাশি একটি দ্বিতীয় directory চালাতে হবে এবং দুটি user list-এর মধ্যে synchronization বজায় রাখতে হবে।

যেসব অ্যাপে কোনো login ব্যবস্থাই নেই, সেগুলোর ক্ষেত্রে কী করবেন?

এর সমাধান হলো forward auth। Self-hosted সার্ভারে এটি নিয়মিত প্রয়োজন হয়। অনুরোধ upstream-এ পাঠানোর আগে আপনার reverse proxy SSO server-কে জিজ্ঞেস করে অনুরোধটি অনুমোদিত কি না। এর পেছনের অ্যাপ SSO সম্পর্কে কিছুই জানতে পারে না। এটি এমন অনুরোধ পায়, যা proxy ইতিমধ্যে যাচাই করেছে। সাধারণত header-এ username-ও থাকে।

authentik-এর proxy provider এই কাজের জন্য নথিভুক্ত 3টি mode দেয়। "Proxy" mode-এ authentik outpost নিজেই upstream app-এ traffic পাঠায়। "Forward auth (single application)" mode-এ traffic আপনার বিদ্যমান reverse proxy-তেই থাকে, আর authentik শুধু authentication check করে। "Forward auth (domain level)" mode-এ একটি parent domain-এর অধীনে থাকা প্রতিটি app-কে একটি provider দিয়ে সুরক্ষিত করা যায়। Domain level ব্যবহার করা সুবিধাজনক। তবে এর একটি নথিভুক্ত সীমাবদ্ধতা আছে: এটি "cannot enforce different application-level authorization rules for each protected application"। অর্থাৎ, ওই domain-এর অধীনে থাকা সব app একই policy set ব্যবহার করে।

Keycloak-এ এর কোনো built-in ব্যবস্থা নেই। এর companion proxy Keycloak Gatekeeper-এর নাম পরে Louketo Proxy করা হয়েছিল। এরপর GitHub-এ সেটি archived করা হয়। এর সর্বশেষ commit ছিল August 2023-এ। OIDC support নেই এমন কোনো app সুরক্ষিত করতে হলে তার সামনে একটি আলাদা component চালাতে হয়। সাধারণত Keycloak client-এ নির্দেশিত oauth2-proxy ব্যবহার করা হয়। Zitadel-এরও নিজস্ব forward auth mode নেই। তাই সেখানেও একইভাবে একটি অতিরিক্ত component install, monitor এবং upgrade করতে হয়।

এই অতিরিক্ত hop-এ এসে reverse proxy configuration আর সহজ থাকে না। তাই এতে auth middleware যুক্ত করার আগে Traefik কীভাবে একাধিক Docker Compose app-এর সামনে কাজ করে পড়ুন।

আপগ্রেডের পথ কতটা জটিল?

August 2026 অনুযায়ী বর্তমান release হলো Keycloak 26.7.1, authentik 2026.5.6 এবং Zitadel v4.16.3। তিনটিই PostgreSQL-এর বিরুদ্ধে schema migration চালায়। অর্থাৎ প্রতিটি upgrade-এই database পরিবর্তন হয়। প্রতিবার আগে database-এর backup নিন। এই একটি অভ্যাসই এই তুলনার যেকোনো feature-এর চেয়ে বেশি গুরুত্বপূর্ণ।

authentik-এর নিয়ম সবচেয়ে কঠোর এবং তারা এটি স্পষ্টভাবে জানায়: "Major release-এর ক্রম অনুসরণ করেই upgrade করতে হবে; পুরোনো major version থেকে সরাসরি সর্বশেষ version-এ যাওয়া যাবে না।" প্রতিটি version-এ পরবর্তী version-এ যাওয়ার আগে সেই version-এর সর্বশেষ patch-এ upgrade করতে হবে, এবং "authentik downgrading সমর্থন করে না"। Calendar-versioned project-এ এক বছর পিছিয়ে থাকলে একটি upgrade একাধিক upgrade-এর ধারায় পরিণত হয়। প্রতিটি ধাপে আলাদা database migration থাকে।

Keycloak-এর upgrade guide-এ অনুসরণ করার ক্রম দেওয়া আছে: আগের version থেকে migration পরিবর্তনগুলো পর্যালোচনা করুন, server upgrade করুন, তারপর adapter-গুলো upgrade করুন। Database migration স্বয়ংক্রিয়ভাবে চলে। চাইলে সেটি export করে হাতে প্রয়োগও করতে পারেন। পরিবর্তন কার্যকর হওয়ার আগে পড়ে দেখার প্রয়োজন হলে এটি কার্যকর। Keycloak ব্যবহারের মূল খরচ হলো এই পর্যালোচনা। এর release notes-এ deprecation এবং আচরণগত পরিবর্তনের তথ্য থাকে। এগুলো সহজে এড়িয়ে যাওয়া যায়, কিন্তু বাদ পড়লে পরে সংশোধন করা ব্যয়বহুল হয়।

Zitadel তার init এবং setup phase-কে চলমান server থেকে আলাদা রাখে। Production guidance-এ scaling-এর সময় setup কাজটি পুনরায় না চালানোর জন্য এগুলো আলাদা রাখার পরামর্শ দেওয়া হয়েছে। একটি single VPS-এ এর অর্থ সাধারণত API healthy দেখানোর আগে setup ধাপটি সম্পূর্ণ হতে হবে। এ কারণেই compose file-এ health check রয়েছে এবং start command-এ --wait ব্যবহার করা হয়েছে।

কোন প্রকল্পটি কার জন্য তৈরি এবং কোথায় প্রতিটির সীমাবদ্ধতা

Keycloak হলো Red Hat-এর identity server। এটি realm, group, role mapping এবং বিদ্যমান corporate directory থাকা organization-এর জন্য তৈরি। তিনটির মধ্যে standards implementation হিসেবে এটিই সবচেয়ে সম্পূর্ণ। তবে 2 GB VPS-এ চারটি self-hosted app চালানোর ক্ষেত্রে, যেখানে অর্ধেক app-এ OIDC support নেই, এটি উপযুক্ত নয়। JVM-এর জন্য 1250 MB memory বরাদ্দ করতে হয়। Company-কেন্দ্রিক realm model শিখতে হয়। তারপর যেসব app আপনার জন্য গুরুত্বপূর্ণ, সেগুলোর জন্যও oauth2-proxy install করতে হয়।

authentik self-hosting ব্যবহারকারীদের জন্য তৈরি। এর feature list-এ সেটি স্পষ্ট। এটি forward auth এবং LDAP provider সরবরাহ করে। Visual editor-এ login flow তৈরি করা যায়। তবে vendor support contract অথবা এমন release train প্রয়োজন হলে এটি সীমাবদ্ধ। Calendar versioning, downgrade path না থাকা এবং version skip করা না যাওয়া—এসব বাস্তব operational কাজ বাড়ায়। Flow editor শেখার জন্য একটি সম্পূর্ণ নতুন model বুঝতে হয়, যদিও আপনার প্রকৃত সমস্যা হয়তো শুধু একটি OIDC client নিয়ে।

Zitadel এমন developer-দের জন্য তৈরি, যারা নিজেদের তৈরি product-এর মধ্যে authentication যুক্ত করছেন। এর API শক্তিশালী এবং multi-tenancy একটি মৌলিক feature। এই পরিস্থিতিতেই এটি সবচেয়ে কম উপযুক্ত। চারটি container, forward auth না থাকা এবং প্রতি core-এর জন্য 4 GB database sizing—password manager ও wiki চালানো একটি VPS-এর জন্য এই architecture সঠিক নয়।

একটি VPS-এ আমি কী চালাব এবং কীভাবে

একটি VPS-এ তিন বা চারটি self-hosted অ্যাপ থাকলে authentik চালান। তিনটিই আপনাকে একটি login screen দেয়। সিদ্ধান্তের মূল কারণ হলো, আপনার কিছু অ্যাপ কখনো OIDC সমর্থন করবে না। authentik অন্য কোনো অতিরিক্ত component ছাড়াই built-in forward auth দিয়ে এই সমস্যা সমাধান করে।

সম্ভব হলে এর জন্য 4 GB দিন। এর পাশে থাকা অ্যাপগুলো ছোট হলে তবেই 2 GB ব্যবহার করুন। port 9000 public internet থেকে আড়ালে রাখুন এবং সামনে থাকা একটি reverse proxy-তে TLS termination করুন। প্রতি রাতে PostgreSQL dump নিন এবং VPS-এর বাইরে সংরক্ষণ করুন। কারণ backup ছাড়া একটি identity provider-এর ওপর নির্ভরশীল প্রতিটি অ্যাপের জন্য এটি single point of failure। stack-টি root হিসেবে নয়, একটি dedicated unprivileged account হিসেবে চালান: একটি VPS-এ least privilege user সেটআপ করা-এ প্রয়োজনীয় account এবং file ownership সম্পর্কে বলা হয়েছে।

আপনার সুরক্ষিত প্রতিটি অ্যাপ ইতিমধ্যে OIDC বা SAML সমর্থন করলে, অথবা Keycloak realm-এর দেওয়া সূক্ষ্ম role model প্রয়োজন হলে Keycloak বেছে নিন। অন্যদের sign up করার জন্য কোনো application তৈরি করলে এবং তার API ও tenant model প্রয়োজন হলে Zitadel বেছে নিন। এই পোস্টের আলোচ্য একটি box-এ তিনটি অ্যাপ চালানোর পরিস্থিতির জন্য এ দুটির কোনোটিই উপযুক্ত নয়।

যে ব্যর্থতার ধরনগুলো প্রথমে দেখা যায়

Restart-এর পরে Keycloak-এ কোনো data নেই। আপনি এটি start-dev দিয়ে চালু করেছেন, যা একটি local development database ব্যবহার করে। কোনো volume ছাড়া container-এ container মুছে ফেললে realm-ও মুছে যায়। KC_DB=postgres-এ আসল database নির্দেশ করে start-এ পরিবর্তন করুন।

ছোট host-এ authentik worker container অদৃশ্য হয়ে যায়। Worker এবং server একই image ব্যবহার করে এবং উভয়ই Python process চালায়। PostgreSQL-ও 2 GB host-এর memory-র একটি অংশ ব্যবহার করতে চায়। কোন service বন্ধ হয়েছে তা নিশ্চিত করতে docker compose ps চালান। এরপর app-এর bug খোঁজার আগে out-of-memory kill হয়েছে কি না দেখতে dmesg পরীক্ষা করুন।

আপনার proxy-এর পেছনে Zitadel-এর Console কাজ করে না। Zitadel API gRPC ব্যবহার করে, তাই upstream পর্যন্ত সম্পূর্ণ পথে HTTP/2 প্রয়োজন। Requirements page-এ upstream connection-এর জন্য HTTP/2 সমর্থনকারী reverse proxy চাওয়া হয়েছে। সেখানে পরীক্ষিত Traefik v3.x, NGINX v1.x, Caddy v2.x এবং Apache httpd 2.4.x-এর version-ও উল্লেখ করা আছে। কোনো proxy upstream connection-কে HTTP/1.1-এ নামিয়ে দিলে login page লোড হবে, কিন্তু Console কাজ করবে না।

প্রতিটি app আপনাকে আবার login screen-এ পাঠায়। SSO server-এর public URL এবং app-এ configured URL scheme ও port-সহ হুবহু একই হতে হবে। Keycloak এটিকে hostname setting বলে। Zitadel এটিকে external domain বলে। দুটির মধ্যে অমিল হলে app এমন একটি login URL-এ redirect করে, যেটিকে server নিজের URL হিসেবে স্বীকৃতি দেয় না। ফলে browser দুই URL-এর মধ্যে বারবার redirect হতে থাকে।

FAQ

2 GB VPS-এর জন্য কোনটি উপযুক্ত?

authentik এবং Keycloak। authentik-এর ঘোষিত প্রয়োজনীয়তা হলো কমপক্ষে 2 CPU core এবং 2 GB RAM-সহ একটি host। Keycloak-এর sizing guide-এ database বাদ দিয়ে server-এর জন্য base memory 1250 MB বলা হয়েছে। আপনি যে অ্যাপগুলো সুরক্ষিত করছেন সেগুলো যোগ করলে 2 GB-তে দুটিরই resource খুব সীমিত থাকবে। তাই স্বাচ্ছন্দ্যে চালানোর জন্য 4 GB-কে ন্যূনতম ধরা ভালো। Zitadel প্রথমবার চালানোর জন্য 2 GB প্রকাশ করেছে। তবে এর production guidance-এ password hashing-এর জন্য 4 CPU core এবং প্রতিটি database core-এর জন্য 4 GB RAM চাওয়া হয়েছে। তাই 2 GB-তে এটি বাস্তবসম্মত deployment নয়।

নিজস্ব login না থাকা কোনো অ্যাপকে কি Keycloak বা Zitadel সুরক্ষিত করতে পারে?

একা পারে না। কোনোটিই forward auth component সরবরাহ করে না। Keycloak-এর পুরোনো companion proxy Louketo Proxy GitHub-এ archived। এর সর্বশেষ commit August 2023-এ হয়েছে। তাই এর ওপর ভিত্তি করে নতুন deployment তৈরি করা উচিত নয়। আপনার reverse proxy এবং অ্যাপের মাঝখানে oauth2-proxy বা অনুরূপ কোনো component বসান। এরপর সেটিকে SSO server-এর একটি OIDC client-এর দিকে নির্দেশ করুন। authentik তার proxy provider-এর মাধ্যমে এটি native ভাবে করতে পারে। এর জন্য "Forward auth (single application)" অথবা "Forward auth (domain level)" mode ব্যবহার করুন।

শুধু LDAP সমর্থন করে এমন কোনো অ্যাপের জন্য কোনটি LDAP server হিসেবে কাজ করতে পারে?

authentik। এর LDAP provider একটি outpost-এ চলে এবং authentik-এর users ও groups-কে LDAP-এর মাধ্যমে searchable করে। LDAPS port 636-এ ব্যবহার করা যায়। এটি read-only। তাই bind এবং search কাজ করে, কিন্তু write কাজ করে না। Keycloak এবং Zitadel বিপরীতভাবে কাজ করে। দুটিই existing LDAP directory-কে user source হিসেবে পড়তে পারে। কোনোটিই কোনো অ্যাপের LDAP bind request-এর উত্তর দেয় না।

authentik upgrade করার সময় কি কোনো version বাদ দেওয়া যাবে?

না। Documentation অনুযায়ী upgrade-এর সময় major release-গুলোর sequence অনুসরণ করতে হবে। পুরোনো কোনো major version থেকে সরাসরি সর্বশেষ version-এ যাওয়া উচিত নয়। প্রথমে প্রতিটি version-এর সর্বশেষ patch release-এ যান। এরপর একবারে একটি version করে upgrade করুন। প্রতিটি ধাপের আগে PostgreSQL backup নিন। কারণ authentik downgrade সমর্থন করে না এবং migration কেবল সামনের দিকে চলে।