দ্বারা Authentik দিয়ে self-hosted SSO সেটআপ করার নিয়ম
Docker Compose-এ Authentik চালিয়ে সব অ্যাপে এক login ব্যবহার করুন। গুরুত্বপূর্ণ env value, akadmin bootstrap এবং Traefik forward auth কনফিগার করার ধাপ দেখুন।
প্রতিটি অ্যাপের জন্য একটি লগইন
Authentik হলো একটি self-hosted SSO (single sign-on) সার্ভার: আপনার ব্যবহারকারীরা একবার সাইন ইন করলেই এর পেছনে থাকা প্রতিটি অ্যাপ সেই সেশনটি গ্রহণ করে, ফলে আলাদা করে পাসওয়ার্ড দেওয়ার প্রয়োজন হয় না। এর ইনস্টলেশন প্রক্রিয়াটি একটি অফিসিয়াল Docker Compose ফাইল এবং দুটি জেনারেট করা সিক্রেট-এর ওপর ভিত্তি করে তৈরি। আসল চিন্তার বিষয়টি আসে এর পরে: একটি reverse proxy-কে এর দিকে নির্দেশ করা এবং একটি বিদ্যমান অ্যাপকে forward auth-এর পেছনে স্থাপন করা।
Authentik-এর সেই Compose ফাইলে তিনটি সার্ভিস থাকে: একটি PostgreSQL ডাটাবেস, একটি server প্রসেস এবং একটি worker প্রসেস। সার্ভার কন্টেইনারটি embedded outpost-ও চালায়, যা এমন একটি কম্পোনেন্ট যা প্রতিটি সুরক্ষিত অ্যাপের জন্য "এই অনুরোধটি কি সাইন ইন করা?"—এই প্রশ্নের উত্তর দেয়। 25 অক্টোবর 2026 অনুযায়ী 2026.8.5 হলো বর্তমান রিলিজ। এটি 21 অক্টোবর 2026 তারিখে 2026.8 সিরিজের সর্বশেষ প্যাচ হিসেবে প্রকাশিত হয়েছিল, যা 18 আগস্ট 2026.8.0 দিয়ে শুরু হয়েছিল। এটি 14 অক্টোবর প্রকাশিত 2026.8.4-কে প্রতিস্থাপন করে অফিসিয়াল Compose ফাইলে ডিফল্ট ইমেজ ট্যাগ হিসেবে যুক্ত হয়েছে। প্রজেক্টটির জন্য অন্তত 2টি CPU কোর এবং 2 GB RAM বিশিষ্ট একটি হোস্ট প্রয়োজন। এটিকে সর্বনিম্ন প্রয়োজনীয়তা হিসেবে গণ্য করুন। সার্ভারটি একদিন চালু থাকার পর PostgreSQL এবং worker উভয়ই মেমোরি দখল করে রাখে।
শুরু করার আগে যা প্রয়োজন
আপনার Docker Engine-এর সঙ্গে Compose v2 plugin প্রয়োজন। এটি docker compose version চালিয়ে যাচাই করতে পারেন। Version-এর বদলে এটি error দেখালে পরবর্তী ধাপে যাওয়ার আগে plugin ইনস্টল করুন। প্রাথমিক নির্দেশনা VPS-এ Docker Compose দিয়ে অ্যাপ চালানো-এ রয়েছে। আপনার এমন একটি DNS A record-ও প্রয়োজন, যা server-এর দিকে নির্দেশ করে। নিচের উদাহরণে এটি auth.example.com, কারণ browser যে hostname ব্যবহার করেছে, Authentik সেটি থেকে redirect URL তৈরি করে।
root হিসেবে নয়, docker group-এর সাধারণ user হিসেবে stack চালান। এই group-এর সদস্যপদ host-এ root access-এর সমতুল্য। তাই VPS-এ least-privilege user account-এর নীতির মতো, এই group শুধু একটি deploy account-কে দিন এবং অন্য কাউকে নয়।
অফিসিয়াল Compose ফাইল দিয়ে ইনস্টলেশন
sudo install -d -o "$USER" -g "$USER" /opt/authentik
cd /opt/authentik
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 -ddocker compose ps কমান্ডটি তিনটি কন্টেইনারকেই চালু অবস্থায় দেখাবে এবং postgresql তার চেক পাস করার পর healthy রিপোর্ট করবে। প্রথমবার চালু করার সময় ডাটাবেস মাইগ্রেশন সম্পন্ন হয়, তাই ওয়েব ইন্টারফেস কাজ শুরু করার আগে এক মিনিট অপেক্ষা করুন।
উভয় জেনারেট করা ভ্যালুই গুরুত্বপূর্ণ, তবে ভিন্ন ভিন্ন কারণে। PG_PASS হলো PostgreSQL পাসওয়ার্ড। Authentik-এর ইনস্টলেশন ডকুমেন্টেশন অনুযায়ী 99 অক্ষরের বেশি পাসওয়ার্ড সমর্থিত নয়, তাই নিজের পছন্দমতো পাসওয়ার্ড দিলে তা এই সীমার মধ্যে রাখুন; জেনারেট করা পাসওয়ার্ডটি অনেক ছোট। AUTHENTIK_SECRET_KEY হলো সেই কি (key) যা Authentik কুকি সাইন করার জন্য ব্যবহার করে। কনফিগারেশন ডকুমেন্টেশন অনুযায়ী, এটি পরিবর্তন করলে সক্রিয় সেশনগুলো বাতিল হয়ে যায়, তাই পরবর্তীতে নতুন কি ব্যবহার করলে সাইন-ইন করা সকল ব্যবহারকারী লগ-আউট হয়ে যাবেন। .env-কে mode 600-এ রাখুন এবং ব্যাকআপের সাথে এর একটি কপি নিরাপদ স্থানে সংরক্ষণ করুন, যাতে রিস্টোর করার সময় একই কি ব্যবহার করা যায়।
Compose ফাইলটি ${VAR:?message} ফরমের মাধ্যমে উভয় ভ্যালুকে প্রয়োজনীয় হিসেবে চিহ্নিত করে: PostgreSQL সার্ভিসে ${PG_PASS:?database password required} এবং সার্ভার ও worker-এ ${AUTHENTIK_SECRET_KEY:?secret key required}। এর মানে হলো, ফাইলটি অনুপস্থিত থাকলে Compose চালু হতে অস্বীকার করবে। ভুল ডিরেক্টরি থেকে docker compose up -d চালালে required variable AUTHENTIK_SECRET_KEY is missing a value: secret key required-এর মতো একটি লাইন প্রিন্ট হবে এবং প্রক্রিয়াটি থেমে যাবে। এই বার্তাটি একটি পাথ সংক্রান্ত সমস্যা, কনফিগারেশন সমস্যা নয়।
গুরুত্বপূর্ণ environment value
বাকি সবকিছু একই .env ফাইলে থাকবে। Authentik double underscore-কে nested configuration key হিসেবে গণ্য করে। তাই AUTHENTIK_EMAIL__HOST, email.host সেট করে। Single underscore nested key-তে map হয় না। কোনো setting কাজ করছে না বলে মনে হওয়ার সবচেয়ে সাধারণ কারণ এটি।
- প্রথমবার চালু হওয়ার সময়
AUTHENTIK_BOOTSTRAP_PASSWORDবিল্ট-ইনakadminuser-এর password সেট করে। তাই public web form-এ কখনও password লিখতে হয় না। একইভাবেAUTHENTIK_BOOTSTRAP_EMAILএবংAUTHENTIK_BOOTSTRAP_TOKENওই user-এর address এবং API token সেট করে। COMPOSE_PORT_HTTPএবংCOMPOSE_PORT_HTTPSpublished port-গুলোকে default 9000 এবং 9443 থেকে সরিয়ে দেয়।AUTHENTIK_EMAIL__HOST,AUTHENTIK_EMAIL__PORT,AUTHENTIK_EMAIL__USERNAME,AUTHENTIK_EMAIL__PASSWORD,AUTHENTIK_EMAIL__USE_TLSএবংAUTHENTIK_EMAIL__FROMoutbound mail configure করে। এগুলো না থাকলে Authentik port 25-এlocalhostকরার চেষ্টা করে। ফলে password-reset mail পাঠানো যায় না এবং worker log-এ connection error দেখা যায়।- Login flow-তে সমস্যা হলে প্রয়োজনীয় বিস্তারিত তথ্য দেখাতে
AUTHENTIK_LOG_LEVEL=debugচালু করে। পরে এটিকেinfo-এ ফিরিয়ে দিন। - ডিফল্টভাবে
AUTHENTIK_ERROR_REPORTING__ENABLEDহলোfalse। Upstream-এ crash report পাঠাতে সম্মত হলেই কেবল এটিকেtrueকরুন।
এগুলো plain file-এ থাকা secret। তাই অন্য যেকোনো credential store-এর মতো এই directory-ও সুরক্ষিত রাখুন। Laptop-এ লেখা note-এর চেয়ে self-hosted Vaultwarden instance-এর মতো password manager-এ recovery copy রাখা নিরাপদ।
প্রথম লগইন এবং অ্যাডমিন অ্যাকাউন্ট
ব্রাউজারে http://SERVER_IP:9000 খুলুন। Authentik তার প্রাথমিক সেটআপ ফ্লো দেখাবে এবং ডিফল্ট akadmin ব্যবহারকারীর জন্য একটি পাসওয়ার্ড সেট করতে বলবে। যদি আপনি ইতিমধ্যে AUTHENTIK_BOOTSTRAP_PASSWORD সেট করে থাকেন, তবে সেই ধাপটি সম্পন্ন হয়েছে এবং আপনি সরাসরি লগইন পেজে চলে যাবেন।
Directory এবং Users মেনু থেকে নিজের জন্য একটি সাধারণ অ্যাডমিন ইউজার তৈরি করুন, তাকে authentik Admins গ্রুপে যুক্ত করুন এবং সেই অ্যাকাউন্ট দিয়ে সাইন ইন করুন। akadmin-কে একটি break-glass অ্যাকাউন্ট হিসেবে রাখুন যার দীর্ঘ পাসওয়ার্ড অফলাইনে সংরক্ষিত থাকবে। যদি কোনো ত্রুটিপূর্ণ ফ্লো বা স্টেজ আপনাকে লক করে দেয়, তবে /opt/authentik থেকে docker compose run --rm server create_recovery_key 10 akadmin কমান্ডটি চালালে একটি লিঙ্ক প্রিন্ট হবে যা আপনাকে সরাসরি akadmin হিসেবে সাইন ইন করাবে। যে কারো কাছে এই লিঙ্ক থাকলে সে একই অ্যাক্সেস পাবে, তাই এটিকে পাসওয়ার্ডের মতোই গোপন রাখুন। একটি শেয়ার করা বিল্ট-ইন অ্যাকাউন্ট দিয়ে দৈনন্দিন কাজ করলে অডিট লগ নষ্ট হয়ে যায়, কারণ প্রতিটি ইভেন্টে akadmin দেখায় এবং কে কাজটি করেছে তা বোঝা যায় না। এই যুক্তিটি Authentik-এর পরবর্তী ধাপের জন্যও প্রযোজ্য: যেমন একটি self-hosted OneCLI harness যা প্রত্যেক ব্যক্তিকে নিজস্ব এজেন্ট দেয়—এটি কেবল তখনই একটি পাঠযোগ্য ট্রেইল রাখে যদি সেখানে আসা পরিচয়টি কোনো নির্দিষ্ট ব্যক্তির হয়, কোনো শেয়ার করা অ্যাকাউন্টের নয়।
Reverse proxy-এর পেছনে Authentik রাখুন
Internet-এ port 9000 প্রকাশ করলে কাজ হয়, কিন্তু আপনার TLS (transport layer security) এবং একটি প্রকৃত hostname দরকার। আপনি যদি ইতিমধ্যে একাধিক Compose অ্যাপের জন্য Traefik reverse proxy-এর সেটআপ চালিয়ে থাকেন, তাহলে একটি override file ব্যবহার করে Authentik-কে একই external proxy network-এ যুক্ত করুন। compose.yml-এর পাশে docker-compose.override.yml তৈরি করুন:
services:
server:
networks:
- default
- proxy
labels:
traefik.enable: "true"
traefik.docker.network: proxy
traefik.http.routers.authentik.rule: Host(`auth.example.com`)
traefik.http.routers.authentik.entrypoints: websecure
traefik.http.routers.authentik.tls.certresolver: le
traefik.http.services.authentik.loadbalancer.server.port: "9000"
networks:
proxy:
external: truedocker compose up -d দিয়ে এটি প্রয়োগ করুন। Compose স্বয়ংক্রিয়ভাবে override একত্র করে। তাই server service official file-এর সবকিছু বজায় রাখে এবং labels পায়। curl -I https://auth.example.com/if/user/ দিয়ে পরীক্ষা করুন। এটি HTTP/2 200-এর উত্তর দেওয়া উচিত। Traefik থেকে 404 page not found পাওয়ার অর্থ হলো কোনো router অনুরোধটির সঙ্গে মেলেনি। labels container-এ পৌঁছেছে কি না, Host() rule hostname-এর সঙ্গে হুবহু মেলে কি না এবং অনুরোধটি router যে HTTPS entry point-এ listen করে সেখানে পৌঁছেছে কি না পরীক্ষা করুন।
Hostname কাজ করার পরে override-এ প্রকাশিত port-গুলো 127.0.0.1-এ bind করুন, যাতে proxy ছাড়া প্রবেশের অন্য কোনো পথ না থাকে।
forward auth দিয়ে একটি অ্যাপ সুরক্ষিত করুন
Authentik-এর proxy provider-এ তিনটি mode আছে, এবং ভুলটি বেছে নিলে এক ঘণ্টা নষ্ট হতে পারে। Proxy বলতে বোঝায়, outpost নিজেই upstream app-এ traffic forward করে। Forward auth (single application) বলতে বোঝায়, আপনার reverse proxy-ই traffic পাঠায় এবং request-টি signed in কি না তা শুধু Authentik-এর কাছে যাচাই করে। Forward auth (domain level) একটি parent domain-এর অধীনে থাকা প্রতিটি app-কে একটি provider দিয়ে সুরক্ষিত করে, তবে প্রতিটি app-এর authorization rule আলাদাভাবে পরিচালনা করতে হয়। সামনে Traefik থাকলে আপনার forward auth (single application) ব্যবহার করা উচিত। অনুশীলনের জন্য একটি নির্দিষ্ট app চাইলে একটি self-hosted AFFiNE workspace ভালো প্রথম প্রার্থী, কারণ এটি এমন একটি internal tool, যা আপনি নিজের device থেকে ব্যবহার করতে চান, অন্য কোথাও থেকে নয়। Team tool হলে সুবিধাটি আরও স্পষ্ট: একটি self-hosted Chatwoot support desk একই provider-এর পেছনে রাখুন। তাহলে inbox-এর উত্তরদাতারা প্রতিদিন একবার sign in করলেই হবে; অতিরিক্ত একটি password সবার মধ্যে ভাগ করতে হবে না।
Web interface-এ Applications, তারপর Providers খুলুন। একটি Proxy Provider তৈরি করুন, forward auth single application mode বেছে নিন এবং external host হিসেবে https://app.example.com সেট করুন। ওই provider-কে নির্দেশ করে একটি Application তৈরি করুন। এরপর Outposts খুলে authentik Embedded Outpost সম্পাদনা করুন এবং নতুন application-টিকে selected applications-এর মধ্যে যোগ করুন। Outpost শুধু তাকে দেওয়া application-গুলোর জন্য সাড়া দেয়। তাই শেষ ধাপটি বাদ দিলে সঠিকভাবে configured provider-ও কোনো response দেয় না।
Authentik container-এ middleware একবার সংজ্ঞায়িত করুন এবং প্রতিটি সুরক্ষিত app থেকে সেটি reference করুন:
traefik.http.middlewares.authentik.forwardauth.address: http://server:9000/outpost.goauthentik.io/auth/traefik
traefik.http.middlewares.authentik.forwardauth.trustForwardHeader: "true"
traefik.http.middlewares.authentik.forwardauth.authResponseHeaders: X-authentik-username,X-authentik-groups,X-authentik-entitlements,X-authentik-email,X-authentik-name,X-authentik-uid,X-authentik-jwt,X-authentik-meta-jwks,X-authentik-meta-outpost,X-authentik-meta-provider,X-authentik-meta-app,X-authentik-meta-versionauthResponseHeaders হলো সেই header-গুলোর তালিকা, যেগুলো Traefik Authentik-এর response থেকে কপি করে upstream-এ পাঠানো request-এ যোগ করে। এটি বাদ দিলে app সুরক্ষিত থাকবে, কিন্তু user কে তা জানতে পারবে না। ফলে automatic login-এর জন্য X-authentik-username পড়ে এমন কোনো ব্যবস্থা signed out অবস্থায় থাকবে। নিজের sign-in ব্যবস্থা থাকা কোনো app-এর সামনে এই ঘাটতিটি সবচেয়ে স্পষ্ট বোঝা যায়, যেমন একটি self-hosted openGym workout tracker এবং তার passkey login। একই page-এর জন্য header-গুলো একটি prompt এবং দুটি prompt-এর মধ্যে পার্থক্য তৈরি করে।
সুরক্ষিত app-এর জন্য একটি নয়, দুটি router প্রয়োজন:
labels:
traefik.enable: "true"
traefik.http.routers.myapp.rule: Host(`app.example.com`)
traefik.http.routers.myapp.entrypoints: websecure
traefik.http.routers.myapp.tls.certresolver: le
traefik.http.routers.myapp.middlewares: authentik@docker
traefik.http.routers.myapp-auth.rule: Host(`app.example.com`) && PathPrefix(`/outpost.goauthentik.io/`)
traefik.http.routers.myapp-auth.entrypoints: websecure
traefik.http.routers.myapp-auth.tls.certresolver: le
traefik.http.routers.myapp-auth.priority: "15"
traefik.http.routers.myapp-auth.service: authentikদ্বিতীয় router-টিই সবাই প্রায়ই বাদ দেয়। Sign in করার পরে Authentik browser-কে /outpost.goauthentik.io/-এর অধীনে থাকা একটি path-এ ফেরত পাঠায়, তবে সেটি app-এর hostname-এর অধীনে, auth.example.com-এর অধীনে নয়। ওই path prefix Authentik service-এ পাঠানোর জন্য router না থাকলে request app-এ পৌঁছায়। App 404 response দেয় এবং login সম্পন্ন হয় না। একই domain-এ থাকা সাধারণ Host() rule-এর চেয়ে নির্দিষ্ট path rule-টিকে অগ্রাধিকার দেওয়ার কাজটি করে বেশি priority।
Private browser window-এ পরীক্ষা করুন। আপনাকে auth.example.com-এ পাঠানো হবে, সেখানে sign in করুন এবং app-এ ফিরে আসুন। Authentik side-এর docker compose logs -f server প্রতিটি প্রচেষ্টার জন্য একটি authorization event দেখায়। এতে বোঝা যায় request-টি আদৌ Authentik-এ পৌঁছেছিল কি না।
আপনি বাস্তবে যে সমস্যাগুলোর মুখোমুখি হবেন
অ্যাপ এবং login page-এর মধ্যে অন্তহীন redirect loop। Provider-এ নির্ধারিত external host browser যে host ব্যবহার করে তার সঙ্গে মেলে না। সাধারণত provider-এ থাকা http:// এবং address bar-এ থাকা https://-এর মধ্যে এই অমিল দেখা যায়। ফলে session cookie ভিন্ন origin-এর জন্য সেট হয় এবং প্রতিবার ফিরে আসা অনুরোধকে নতুন anonymous request হিসেবে গণ্য করা হয়। Retest করার আগে external host ঠিক করুন এবং উভয় domain-এর cookie মুছে দিন।
/outpost.goauthentik.io/start-এ 404। Outpost router অনুপস্থিত, অথবা ওই host-এর catch-all router-এর তুলনায় তার priority কম।
Login চাওয়া ছাড়াই অ্যাপ load হয়। middlewares label এমন একটি middleware নির্দেশ করে, যা বিদ্যমান নয়। Traefik এ বিষয়ে warning দেখায় না। তাই authentik@docker-এ typo থাকলে কোনো middleware চালু হয় না। Traefik dashboard খুলে router-এর তালিকায় middleware-টি আছে কি না নিশ্চিত করুন।
সফল login-এর পরে Authentik থেকে 403। User authenticated হলেও authorized নয়। Application-এ এমন একটি policy binding বা group requirement রয়েছে, যা user পূরণ করেন না। Admin interface-এর Events log কোন policy অনুরোধটি প্রত্যাখ্যান করেছে তা দেখায়।
Keycloak যখন বেশি উপযুক্ত
Keycloak পুরোনো প্রকল্প এবং Red Hat-এর সমর্থনপুষ্ট। প্রচলিত enterprise identity ব্যবস্থাপনার জন্য এটি বেশি শক্তিশালী পছন্দ। বিশেষ করে ভারী SAML federation, একসঙ্গে একাধিক external identity provider থেকে login broker করা, এবং নথিবদ্ধ migration path হিসেবে realm export ও import-এর ক্ষেত্রে এটি কার্যকর। কিছু প্রতিষ্ঠানের কাছে এর commercial support-এর উপস্থিতিও গুরুত্বপূর্ণ। বিনিময়ে, Keycloak-এর নিজস্ব proxy নেই। তাই OIDC (OpenID Connect) বা SAML কোনোটিই সমর্থন করে না এমন অ্যাপ সুরক্ষিত করতে এর পাশে oauth2-proxy-এর মতো কোনো উপাদান চালাতে হয়। Authentik-এর built-in proxy provider এই কাজটি করে এবং এটি ইতিমধ্যেই সমন্বিত। এ কারণেই বিভিন্ন ধরনের অ্যাপ চালানো অধিকাংশ self-hoster শেষ পর্যন্ত Authentik বেছে নেন।
ব্যাকআপ এবং আপগ্রেড
তিনটি জিনিস রিস্টোর প্রক্রিয়াকে সম্ভব করে: PostgreSQL ডাটাবেস, ./data ডিরেক্টরি এবং .env।
cd /opt/authentik
docker compose exec -T postgresql pg_dump -U authentik authentik | gzip > authentik-$(date +%F).sql.gzসেই ডাম্প এবং .env একসাথে সংরক্ষণ করুন। ডাম্পটিতে AUTHENTIK_SECRET_KEY-এর কোনো কপি থাকে না এবং ভিন্ন কি (key) দিয়ে রিস্টোর করলে প্রতিটি সক্রিয় সেশন বাতিল হয়ে যায়, তাই মূল কি সংরক্ষণ করলে রিস্টোর করা সার্ভারটি আগের মতোই কাজ চালিয়ে যেতে পারে।
আপগ্রেড করার জন্য ট্যাগ পরিবর্তন করতে হয়। .env ফাইলে AUTHENTIK_TAG-কে আপনার কাঙ্ক্ষিত রিলিজে সেট করুন, তারপর docker compose pull এবং এরপর docker compose up -d চালান। যদি আপনি AUTHENTIK_TAG সেট না করে থাকেন, তবে ভার্সনটি সরাসরি compose.yml ফাইলে লেখা ডিফল্ট থেকে আসে, তাই সেই ফাইলের নতুন কপি ডাউনলোড করাই হলো আপগ্রেড করার উপায়, এবং অফিসিয়াল আপগ্রেড ডকুমেন্টেশনে এই পদ্ধতিই বর্ণনা করা হয়েছে। প্রথমে রিলিজ নোটগুলো পড়ুন। Authentik তারিখ-ভিত্তিক ভার্সন ব্যবহার করে এবং অক্টোবর 2026 অনুযায়ী তাদের ডকুমেন্টেশন বলছে যে, আপগ্রেড অবশ্যই মেজর রিলিজের ক্রম অনুসরণ করবে: আপনি যে সিরিজটি চালাচ্ছেন তার সর্বশেষ প্যাচে যান, তারপর কোনোটি বাদ না দিয়ে প্রতিটি পরবর্তী সিরিজে ধাপে ধাপে যান। Authentik ডাউনগ্রেড সমর্থন করে না, তাই পুল (pull) করার আগে ডাটাবেস ডাম্প নিন, পরে নয়।
FAQ
Authentik নিজে host করা কি বিনামূল্যে?
Open source edition বিনামূল্যে এবং এতে উপরের সব সুবিধা রয়েছে: proxy provider, forward auth, OIDC (OpenID Connect), SAML এবং flows engine। Paid enterprise tier-এ support এবং কিছু enterprise feature যোগ হয়, তবে এখানে কোনো licence প্রয়োজন নেই।
Authentik ব্যবহার করতে কি Traefik প্রয়োজন?
না। auth_request ব্যবহার করে nginx-এর সঙ্গে এবং forward_auth ব্যবহার করে Caddy-এর সঙ্গে forward auth কাজ করে। প্রতিটি ক্ষেত্রেই পদ্ধতিটি একই: reverse proxy প্রতিটি request সম্পর্কে Authentik-এর কাছে যাচাই করে, এবং protected hostname-এর /outpost.goauthentik.io/ path prefix-টি app-এর বদলে Authentik-এ route করতে হয়।
আমার protected app login এবং error-এর মধ্যে বারবার ঘুরতে থাকে কেন?
Proxy provider-এ configured external host browser যে URL ব্যবহার করছে, তার সঙ্গে মেলে না। সাধারণত http এবং https-এর মধ্যে এই অমিল থাকে। Session cookie একটি origin-এর জন্য জারি হয় এবং অন্য origin-এ পড়া হয়। তাই Authentik প্রতিবার anonymous request দেখতে পায়। External host ঠিক করুন। এরপর আবার test করার আগে উভয় hostname-এর cookie clear করুন।
Authentik-এর কত RAM প্রয়োজন?
October 2026 অনুযায়ী documented minimum হলো 2 CPU core এবং 2 GB RAM। এই হিসাব PostgreSQL, server এবং worker—তিনটিকে একসঙ্গে ধরে করা হয়েছে। 2 GB-এর server-এ memory pressure kernel-এর OOM killer সক্রিয় করতে পারে। এটি সর্বোচ্চ badness score-যুক্ত process বন্ধ করে। এই score মোটামুটি process-টি allowed memory-এর যে অংশ ব্যবহার করে, তার সঙ্গে তার oom_score_adj যোগ করে নির্ধারিত হয়। যদি worker বন্ধ হয়ে যায়, তাহলে login page সচল থাকলেও background task এবং outbound email বন্ধ হয়ে যায়। একই server-এ protected app-গুলোও চালালে 4 GB RAM দিন।