Authentik को Docker Compose पर कैसे सेटअप करें

आपके द्वारा होस्ट किए जाने वाले प्रत्येक ऐप के लिए एक लॉगिन

Authentik एक self-hosted SSO (single sign-on) सर्वर है: आपके उपयोगकर्ता एक बार साइन इन करते हैं, और इसके पीछे के सभी ऐप्स अपना पासवर्ड मांगने के बजाय उस session को स्वीकार कर लेते हैं। इसका इंस्टॉलेशन एक आधिकारिक Docker Compose फ़ाइल और दो generated secrets के माध्यम से होता है। असली काम इसके बाद शुरू होता है: एक reverse proxy को इसकी ओर पॉइंट करना, और forward auth के पीछे एक मौजूदा ऐप को सेट करना।

Authentik उस Compose फ़ाइल में तीन services के रूप में आता है: एक PostgreSQL डेटाबेस, एक server प्रोसेस, और एक worker प्रोसेस। सर्वर कंटेनर embedded outpost को भी चलाता है, जो वह घटक है जो हर सुरक्षित ऐप के लिए "क्या यह अनुरोध साइन इन है?" का उत्तर देता है। 25 अक्टूबर 2026 तक, Version 2026.8.5 वर्तमान release है। इसे 21 अक्टूबर 2026 को 2026.8 सीरीज के नवीनतम पैच के रूप में प्रकाशित किया गया था, जिसकी शुरुआत 18 अगस्त को 2026.8.0 के साथ हुई थी, और यह आधिकारिक Compose फ़ाइल में डिफ़ॉल्ट इमेज टैग के रूप में 14 अक्टूबर के 2026.8.4 की जगह लेता है। प्रोजेक्ट के लिए कम से कम 2 CPU cores और 2 GB RAM वाले होस्ट की आवश्यकता होती है। इसे न्यूनतम आवश्यकता मानें। एक दिन तक चलने के बाद PostgreSQL और worker दोनों मेमोरी का उपयोग करते हैं।

शुरू करने से पहले आपकी आवश्यकताएं

आपको Docker Engine के साथ Compose v2 plugin की आवश्यकता है, जिसे आप docker compose version के साथ सत्यापित कर सकते हैं। यदि यह वर्ज़न दिखाने के बजाय कोई त्रुटि देता है, तो आगे बढ़ने से पहले plugin इंस्टॉल करें; इसकी बुनियादी जानकारी running apps with Docker Compose on a VPS में दी गई है। आपको सर्वर की ओर इशारा करने वाले एक DNS A record की भी आवश्यकता है, जो नीचे दिए गए उदाहरणों में auth.example.com है, क्योंकि Authentik ब्राउज़र द्वारा उपयोग किए गए hostname से अपने redirect URLs बनाता है।

Stack को root के बजाय docker समूह के एक सामान्य उपयोगकर्ता के रूप में चलाएं। उस समूह की सदस्यता host पर root के बराबर होती है, इसलिए इसे केवल एक deploy account को दें और किसी अन्य को नहीं, जैसा कि least-privilege user accounts on a VPS में बताया गया है।

आधिकारिक 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 -d

docker compose ps को तीन कंटेनर दिखाने चाहिए, जो सभी up हों, और postgresql को healthy रिपोर्ट करना चाहिए जब इसकी जांच पूरी हो जाए। पहली बार शुरू करने पर डेटाबेस माइग्रेशन चलता है, इसलिए वेब इंटरफेस के उत्तर देने से पहले एक मिनट का समय दें।

दोनों generated values अलग-अलग कारणों से महत्वपूर्ण हैं। PG_PASS PostgreSQL पासवर्ड है। Authentik के इंस्टॉलेशन दस्तावेज़ कहते हैं कि 99 वर्णों से अधिक लंबे पासवर्ड समर्थित नहीं हैं, इसलिए अपने द्वारा चुने गए किसी भी पासवर्ड को इससे छोटा रखें; generated पासवर्ड काफी छोटा है। AUTHENTIK_SECRET_KEY वह key है जिसका उपयोग Authentik कुकीज़ को साइन करने के लिए करता है, और इसके कॉन्फ़िगरेशन दस्तावेज़ कहते हैं कि इसे बदलने से सक्रिय sessions अमान्य हो जाते हैं, इसलिए बाद में एक नई key सभी साइन-इन उपयोगकर्ताओं को लॉग आउट कर देगी। .env को mode 600 पर रखें और अपने बैकअप के साथ कहीं सुरक्षित स्थान पर इसकी एक कॉपी रखें, ताकि रिस्टोर करने पर सर्वर उसी key के साथ वापस आए जिसके साथ वह चल रहा था।

Compose फ़ाइल ${VAR:?message} फॉर्म के साथ दोनों values को आवश्यक के रूप में चिह्नित करती है: PostgreSQL सर्विस पर ${PG_PASS:?database password required} और सर्वर व वर्कर पर ${AUTHENTIK_SECRET_KEY:?secret key required}। इसका मतलब है कि फ़ाइल गायब होने पर Compose शुरू होने से इनकार कर देता है। गलत डायरेक्टरी से docker compose up -d चलाने पर required variable AUTHENTIK_SECRET_KEY is missing a value: secret key required जैसी लाइन प्रिंट होती है और यह रुक जाता है। वह संदेश एक पाथ समस्या है, कॉन्फ़िगरेशन समस्या नहीं।

महत्वपूर्ण environment values

बाकी सभी मान उसी .env file में रखे जाते हैं। Authentik double underscore को nested configuration key में map करता है, इसलिए AUTHENTIK_EMAIL__HOST, email.host सेट करता है। Single underscore nested key में map नहीं होता। यही सबसे सामान्य कारण है कि कोई setting कोई प्रभाव नहीं दिखाती।

• AUTHENTIK_BOOTSTRAP_PASSWORD पहले start पर built-in akadmin user का password सेट करता है, इसलिए आपको public web form में password दर्ज नहीं करना पड़ता। AUTHENTIK_BOOTSTRAP_EMAIL और AUTHENTIK_BOOTSTRAP_TOKEN उसी तरह उस user का address और API token सेट करते हैं।
• COMPOSE_PORT_HTTP और COMPOSE_PORT_HTTPS published ports को default 9000 और 9443 से बदल देते हैं।
• AUTHENTIK_EMAIL__HOST, AUTHENTIK_EMAIL__PORT, AUTHENTIK_EMAIL__USERNAME, AUTHENTIK_EMAIL__PASSWORD, AUTHENTIK_EMAIL__USE_TLS और AUTHENTIK_EMAIL__FROM outbound mail configure करते हैं। इनके बिना Authentik port 25 पर localhost को आज़माता है, इसलिए password-reset mails worker log में connection error के रूप में दिखाई देते हैं।
• AUTHENTIK_LOG_LEVEL=debug उस detail को enable करता है जिसकी आपको login flow में समस्या होने पर आवश्यकता होती है। इसके बाद इसे वापस info पर सेट करें।
• AUTHENTIK_ERROR_REPORTING__ENABLED का default मान false है। इसे केवल true पर सेट करें, यदि आप crash reports upstream भेजने के लिए तैयार हैं।

ये plain file में रखे गए secrets हैं। इसलिए directory को उसी तरह सुरक्षित रखें, जैसे किसी अन्य credential store को रखते हैं। 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 रखें

Port 9000 को internet पर publish करने से service काम करती है, लेकिन आपको TLS (transport layer security) और एक वास्तविक hostname चाहिए। यदि आप पहले से कई Compose apps के लिए Traefik को reverse proxy के रूप में इस्तेमाल करना वाले setup को चला रहे हैं, तो 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: true

इसे docker compose up -d से apply करें। Compose override को अपने-आप merge करता है, इसलिए server service official file की सभी settings रखती है और labels भी प्राप्त करती है। curl -I https://auth.example.com/if/user/ से जाँच करें; इसे HTTP/2 200 का उत्तर देना चाहिए। Traefik से मिलने वाला 404 page not found बताता है कि request से मेल खाने वाला कोई router नहीं मिला। जाँचें कि labels container तक पहुँचे हैं, Host() rule hostname से ठीक-ठीक मेल करता है, और request उस HTTPS entry point पर पहुँची है जिस पर router listen करता है।

Hostname काम करने लगे तो override में published ports को 127.0.0.1 से bind करें, ताकि अंदर आने का एकमात्र रास्ता proxy के माध्यम से हो।

एक app को forward auth से सुरक्षित करें

Authentik के proxy provider में तीन modes होते हैं, और गलत mode चुनने में एक घंटा लग सकता है। Proxy का अर्थ है कि outpost स्वयं upstream app तक traffic भेजता है। Forward auth (single application) का अर्थ है कि आपका अपना reverse proxy traffic भेजता रहता है और केवल Authentik से पूछता है कि request में sign-in है या नहीं। Forward auth (domain level) एक ही parent domain के अंतर्गत सभी apps को एक provider से सुरक्षित करता है, लेकिन हर application के लिए अलग authorization rules लागू नहीं किए जा सकते। यदि सामने Traefik है, तो आपको forward auth (single application) चुनना चाहिए। यदि आप अभ्यास के लिए कोई वास्तविक app चाहते हैं, तो self-hosted AFFiNE workspace अच्छा पहला विकल्प है। ऐसे internal tool को आप अपने devices से accessible रखना चाहेंगे, अन्य स्थानों से नहीं। 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 को edit करें और नए application को selected applications में ले जाएँ। Outpost केवल उन्हीं applications के लिए उत्तर देता है जो उसे दिए गए हैं। इसलिए अंतिम चरण छोड़ने पर सही तरह configure किया गया provider भी कोई response नहीं देता।

Middleware को Authentik container पर एक बार define करें और हर protected 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-version

authResponseHeaders उन headers की list है जिन्हें Traefik Authentik के उत्तर से लेकर upstream को भेजी जाने वाली request में copy करता है। इसे छोड़ देने पर app सुरक्षित तो रहती है, लेकिन उसे user की पहचान नहीं मिलती। इसलिए X-authentik-username पढ़कर automatic login करने वाली कोई भी सुविधा logged out रहती है। यह समस्या खास तौर पर उस app के सामने स्पष्ट होती है जिसका अपना sign-in होता है, जैसे self-hosted openGym workout tracker और उसका passkey login। इन headers के कारण उसी page के लिए दो prompts के बजाय केवल एक prompt दिखता है।

Protected app के लिए एक नहीं, दो routers चाहिए:

    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 पर नहीं। यदि कोई router उस path prefix को Authentik service तक नहीं भेजता, तो request आपके app तक पहुँचती है। App 404 लौटाता है और login पूरा नहीं होता। अधिक बड़ा priority ही यह सुनिश्चित करता है कि उसी domain पर मौजूद सामान्य Host() rule के बजाय specific path rule लागू हो।

इसे private browser window में test करें। आपको auth.example.com पर भेजा जाना चाहिए, वहाँ sign in करें और फिर app पर वापस आएँ। Authentik side पर docker compose logs -f server हर attempt के लिए authorization event दिखाता है। इससे पता चलता है कि request Authentik तक पहुँची या नहीं।

वे विफलताएं जिनका आप वास्तव में सामना करेंगे

ऐप और लॉगिन पेज के बीच अंतहीन रीडायरेक्ट लूप। प्रदाता पर बाहरी होस्ट उस होस्ट से मेल नहीं खाता है जिसका उपयोग ब्राउज़र करता है, आमतौर पर प्रदाता में http:// और एड्रेस बार में https:// का अंतर होता है। सेशन कुकी फिर एक अलग ऑरिजिन के लिए सेट हो जाती है, इसलिए हर बार वापस आने पर यह एक नए अज्ञात अनुरोध (anonymous request) जैसा दिखता है। बाहरी होस्ट को ठीक करें और पुनः परीक्षण करने से पहले दोनों डोमेन के लिए कुकीज़ साफ़ करें।

/outpost.goauthentik.io/start पर 404 त्रुटि। आउटपोस्ट राउटर गायब है, या उस होस्ट के लिए इसकी प्राथमिकता कैच-ऑल राउटर से कम है।

ऐप बिना लॉगिन मांगे लोड हो जाता है। middlewares लेबल एक ऐसे मिडलवेयर का नाम बताता है जो मौजूद नहीं है। Traefik इसके बारे में चेतावनी नहीं देता है, इसलिए authentik@docker में टाइपो का मतलब है कि कोई मिडलवेयर नहीं चल रहा है। Traefik डैशबोर्ड खोलें और पुष्टि करें कि राउटर में मिडलवेयर सूचीबद्ध है।

सफल लॉगिन के बाद Authentik से 403 त्रुटि। उपयोगकर्ता प्रमाणित (authenticated) है लेकिन अधिकृत (authorized) नहीं है: एप्लिकेशन में एक पॉलिसी बाइंडिंग या समूह की आवश्यकता है, जिसे यह उपयोगकर्ता पूरा नहीं करता है। एडमिन इंटरफ़ेस में इवेंट्स लॉग उस पॉलिसी का नाम बताता है जिसने इसे अस्वीकार किया है।

जब Keycloak अधिक उपयुक्त विकल्प है

Keycloak पुराना project है और इसे Red Hat का समर्थन प्राप्त है। Classic enterprise identity के लिए यह अधिक मजबूत विकल्प है। इसमें बड़े SAML federation deployments, एक साथ कई external identity providers से login broker करना, और documented migration path के रूप में realm export और import शामिल हैं। कुछ organisations के लिए commercial support का उपलब्ध होना भी महत्वपूर्ण होता है। इसकी सीमा यह है कि Keycloak का अपना proxy नहीं है। इसलिए ऐसे app को सुरक्षित करने के लिए जो OIDC (OpenID Connect) या SAML में से किसी का भी उपयोग नहीं करता, इसके साथ oauth2-proxy जैसा कोई component चलाना पड़ता है। Authentik का built-in proxy provider यही काम करता है और पहले से integrated है। इसी कारण mixed apps चलाने वाले अधिकांश self-hosters अंततः 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 के तहत रिस्टोर करने से हर सक्रिय session अमान्य हो जाता है, इसलिए मूल key को रखने का मतलब है कि रिस्टोर किया गया सर्वर वैसे ही काम करता रहेगा जैसा वह पहले था।

अपग्रेड एक टैग परिवर्तन है। .env में AUTHENTIK_TAG को उस release पर सेट करें जिसे आप चाहते हैं, फिर docker compose pull चलाएं और उसके बाद docker compose up -d करें। यदि आपने कभी AUTHENTIK_TAG सेट नहीं किया है, तो वर्शन सीधे compose.yml में लिखे गए डिफ़ॉल्ट से आता है, इसलिए उस फ़ाइल की एक नई कॉपी डाउनलोड करना ही अपग्रेड है, और यही वह मार्ग है जिसका वर्णन आधिकारिक अपग्रेड दस्तावेज़ करते हैं। पहले release नोट्स पढ़ें। Authentik तिथि-आधारित वर्शन का उपयोग करता है, और अक्टूबर 2026 तक इसके दस्तावेज़ कहते हैं कि अपग्रेड को प्रमुख releases के क्रम का पालन करना चाहिए: जिस सीरीज को आप चला रहे हैं उसके नवीनतम पैच पर जाएं, फिर किसी को छोड़े बिना क्रम में प्रत्येक बाद की सीरीज के माध्यम से आगे बढ़ें। Authentik डाउनग्रेडिंग का समर्थन नहीं करता है, इसलिए पुल करने से पहले डेटाबेस डंप लें, बाद में नहीं।

FAQ

क्या Authentik को self-host करना मुफ़्त है?

Open source edition मुफ़्त है और ऊपर बताई गई सभी सुविधाएँ शामिल करती है: proxy provider, forward auth, OIDC (OpenID Connect), SAML और flows engine। Paid enterprise tier में support और कुछ enterprise सुविधाएँ मिलती हैं, लेकिन यहाँ बताई गई किसी भी चीज़ के लिए licence की आवश्यकता नहीं है।

क्या Authentik का उपयोग करने के लिए Traefik आवश्यक है?

नहीं। Forward auth, auth_request के माध्यम से nginx और forward_auth के माध्यम से Caddy के साथ काम करता है। हर मामले में pattern एक जैसा है: reverse proxy प्रत्येक request के बारे में Authentik से पूछता है, और protected hostname पर path prefix /outpost.goauthentik.io/ को app के बजाय Authentik तक route करना आवश्यक है।

मेरी protected app login और error के बीच लगातार redirect क्यों हो रही है?

Proxy provider में configured external host, browser द्वारा उपयोग किए जा रहे URL से match नहीं करता। सबसे आम स्थिति http और https के बीच mismatch है। Session cookie एक origin के लिए जारी होती है और दूसरे origin पर पढ़ी जाती है, इसलिए Authentik को हर बार anonymous request दिखाई देती है। External host सही करें, फिर दोबारा test करने से पहले दोनों hostnames की cookies clear करें।

Authentik को कितनी RAM चाहिए?

October 2026 तक documented minimum 2 CPU cores और 2 GB RAM है। इसमें PostgreSQL, server और worker तीनों शामिल हैं। 2 GB की machine पर memory pressure kernel का OOM killer सक्रिय कर सकता है। यह उस process को समाप्त करता है जिसका badness score सबसे अधिक होता है। यह score लगभग उसके द्वारा उपयोग की जा रही allowed memory की हिस्सेदारी और उसके oom_score_adj का योग होता है। यदि worker समाप्त होता है, तो background tasks और outbound email रुक जाते हैं, जबकि login page काम करता रहता है। यदि वही server वे apps भी चलाता है जिन्हें आप protect कर रहे हैं, तो 4 GB RAM दें।