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

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

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

Authentik उस Compose फ़ाइल में तीन सेवाओं के रूप में आता है: एक PostgreSQL डेटाबेस, एक server प्रोसेस, और एक worker प्रोसेस। सर्वर कंटेनर एम्बेडेड आउटपोस्ट (embedded outpost) को भी चलाता है, जो वह घटक है जो प्रत्येक सुरक्षित ऐप के लिए "क्या यह अनुरोध साइन इन है?" का उत्तर देता है। जुलाई 2026 तक Version 2026.5 वर्तमान रिलीज़ है, और प्रोजेक्ट कम से कम 2 CPU कोर और 2 GB RAM वाले होस्ट की मांग करता है। इसे न्यूनतम आवश्यकता मानें। एक दिन तक चलने के बाद PostgreSQL और वर्कर दोनों मेमोरी का उपयोग करते हैं।

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

आपको 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 में तीन कंटेनर दिखाई देने चाहिए, जिसमें postgresql को healthy रिपोर्ट करना चाहिए और server तथा worker को running रिपोर्ट करना चाहिए। पहली बार स्टार्ट होने पर डेटाबेस माइग्रेशन चलते हैं, इसलिए वेब इंटरफ़ेस के जवाब देने से पहले एक मिनट का समय दें।

दोनों जनरेट किए गए मान अलग-अलग कारणों से महत्वपूर्ण हैं। PG_PASS PostgreSQL पासवर्ड है, और इसकी अधिकतम सीमा 99 वर्णों की है। AUTHENTIK_SECRET_KEY सत्रों (sessions) और टोकन को साइन करता है, इसलिए इसे बाद में बदलने पर सभी उपयोगकर्ता लॉग आउट हो जाएंगे और आपके द्वारा जारी किए गए सभी API टोकन अमान्य हो जाएंगे। .env को मोड 600 पर रखें और इसकी एक प्रति सुरक्षित स्थान पर रखें, क्योंकि बिना अपनी संबंधित गुप्त कुंजी (secret key) के रिस्टोर किए गए डेटाबेस में कोई भी लॉग इन नहीं कर पाएगा।

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

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

बाकी सब कुछ उसी .env फाइल में जाता है। Authentik एक डबल अंडरस्कोर को नेस्टेड कॉन्फ़िगरेशन की (nested configuration key) के रूप में मैप करता है, इसलिए AUTHENTIK_EMAIL__HOST से email.host सेट होता है। एक सिंगल अंडरस्कोर को बिना किसी चेतावनी के अनदेखा कर दिया जाता है, जो इस बात का सबसे आम कारण है कि कोई सेटिंग काम क्यों नहीं करती।

• AUTHENTIK_BOOTSTRAP_PASSWORD पहली बार स्टार्ट होने पर इन-बिल्ट akadmin यूजर का पासवर्ड सेट करता है, ताकि आपको कभी भी किसी पब्लिक वेब फॉर्म में इसे टाइप न करना पड़े। AUTHENTIK_BOOTSTRAP_EMAIL और AUTHENTIK_BOOTSTRAP_TOKEN उसी तरह उस यूजर का ईमेल पता और एक API टोकन सेट करते हैं।
• COMPOSE_PORT_HTTP और COMPOSE_PORT_HTTPS पब्लिश किए गए पोर्ट्स को 9000 और 9443 के डिफॉल्ट से हटाकर कहीं और ले जाते हैं।
• AUTHENTIK_EMAIL__HOST, AUTHENTIK_EMAIL__PORT, AUTHENTIK_EMAIL__USERNAME, AUTHENTIK_EMAIL__PASSWORD, AUTHENTIK_EMAIL__USE_TLS और AUTHENTIK_EMAIL__FROM आउटबाउंड मेल को कॉन्फ़िगर करते हैं। इनके बिना Authentik पोर्ट 25 पर localhost का प्रयास करता है, जिससे पासवर्ड-रीसेट मेल वर्कर लॉग में कनेक्शन एरर के रूप में समाप्त हो जाते हैं।
• AUTHENTIK_LOG_LEVEL=debug लॉगिन फ्लो के सही से काम न करने पर आवश्यक विवरण को चालू करता है। बाद में इसे वापस info पर सेट कर दें।
• AUTHENTIK_ERROR_REPORTING__ENABLED डिफॉल्ट रूप से false होता है। इसे केवल तभी true पर सेट करें यदि आप अपस्ट्रीम क्रैश रिपोर्ट भेजने में सहज हैं।

ये एक सादी फाइल में मौजूद सीक्रेट्स हैं, इसलिए इस डायरेक्टरी के साथ वैसा ही व्यवहार करें जैसा आप किसी अन्य क्रेडेंशियल स्टोर के साथ करते हैं। अपने लैपटॉप पर किसी नोट के बजाय, self-hosted Vaultwarden instance जैसा पासवर्ड मैनेजर रिकवरी कॉपी के लिए एक बेहतर स्थान है।

प्रथम लॉगिन और एडमिन अकाउंट

ब्राउज़र में http://SERVER_IP:9000 खोलें। Authentik अपना प्रारंभिक सेटअप फ्लो दिखाता है और आपसे डिफ़ॉल्ट akadmin उपयोगकर्ता के लिए पासवर्ड सेट करने को कहता है। यदि आपने पहले ही AUTHENTIK_BOOTSTRAP_PASSWORD सेट कर लिया है, तो वह चरण पूरा हो चुका है और आप सीधे लॉगिन पेज पर पहुँच जाएंगे।

Directory और फिर Users के अंतर्गत अपने लिए एक सामान्य एडमिन उपयोगकर्ता बनाएं, उसे authentik Admins समूह में जोड़ें, और उस अकाउंट से साइन इन करें। akadmin को एक ब्रेक-ग्लास अकाउंट के रूप में छोड़ दें, जिसका लंबा पासवर्ड ऑफलाइन सुरक्षित रखा गया हो। एक साझा इन-बिल्ट अकाउंट के तहत दैनिक कार्य करने से ऑडिट लॉग नष्ट हो जाता है, क्योंकि प्रत्येक इवेंट में akadmin लिखा होता है और यह पता नहीं चलता कि वह किसने किया है। यह तर्क Authentik के डाउनस्ट्रीम पर भी लागू होता है: एक self-hosted OneCLI harness जो प्रत्येक व्यक्ति को अपना स्वयं का agent देता है केवल तभी एक पठनीय ट्रेल छोड़ता है यदि उस तक पहुँचने वाली पहचान किसी एक व्यक्ति की हो, न कि ऐसे लॉगिन की जिसे पूरी टीम साझा करती है।

Authentik को अपने reverse proxy के पीछे रखें

Port 9000 को इंटरनेट पर publish करना काम करता है, लेकिन आपको TLS (transport layer security) और एक वास्तविक hostname की आवश्यकता है। यदि आप पहले से ही Traefik as a reverse proxy for multiple Compose apps से 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 के साथ लागू करें। Compose स्वचालित रूप से override को merge कर देता है, इसलिए server service आधिकारिक file की सभी सेटिंग्स को बनाए रखती है और labels प्राप्त कर लेती है। curl -I https://auth.example.com/if/user/ के साथ जाँच करें, जिसे HTTP/2 200 का उत्तर देना चाहिए। Traefik से 404 page not found का मतलब है कि container proxy network पर नहीं है, और Traefik उस container तक नहीं पहुँच सकता जिसे वह देख नहीं सकता।

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

Forward auth के साथ एक app को सुरक्षित करना

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

Middleware को एक बार Authentik container पर define करें, और हर सुरक्षित 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-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 की सूची है जिन्हें Traefik, Authentik के जवाब से copy करके उस request पर लगाता है जिसे वह upstream भेजता है। इसे छोड़ देने पर app सुरक्षित तो रहेगा, लेकिन उसे यह कभी पता नहीं चलेगा कि user कौन है, इसलिए जो भी automatic login के लिए X-authentik-username को पढ़ता है, वह logged out ही रहेगा। यह कमी उस app के सामने सबसे स्पष्ट होती है जिसमें अपना खुद का sign-in होता है, जैसे कि a self-hosted openGym workout tracker और उसका passkey login, जहाँ headers का अंतर एक ही page के लिए एक या दो बार login prompt आने का कारण बनता है।

सुरक्षित 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 को auth.example.com पर नहीं, बल्कि app के hostname पर /outpost.goauthentik.io/ के अंतर्गत एक path पर वापस भेजता है। यदि कोई router उस path prefix को Authentik service तक नहीं भेजता है, तो request आपके app पर पहुँचती है, जो 404 error देता है, और login कभी पूरा नहीं होता। उच्च priority ही वह कारण है जिससे एक ही domain पर विशिष्ट path rule, सामान्य Host() rule पर भारी पड़ता है।

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

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

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

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

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

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

जब Keycloak एक बेहतर विकल्प हो

Keycloak एक पुराना प्रोजेक्ट है, जिसे Red Hat का समर्थन प्राप्त है। यह क्लासिक एंटरप्राइज आइडेंटिटी कार्यों के लिए एक मजबूत विकल्प है: जैसे कि भारी SAML फेडरेशन, एक साथ कई बाहरी आइडेंटिटी प्रोवाइडर्स से लॉगिन को ब्रोकर करना, और माइग्रेशन के लिए डॉक्यूमेंटेड पाथ के रूप में realm को एक्सपोर्ट और इम्पोर्ट करना। कुछ संगठनों के लिए इसके पीछे मिलने वाला कमर्शियल सपोर्ट कागजों पर मायने रखता है। इसकी कमी यह है कि Keycloak का अपना कोई प्रॉक्सी नहीं है, इसलिए जो ऐप OIDC (OpenID Connect) का उपयोग नहीं करते, उन्हें सुरक्षित करने के लिए oauth2-proxy जैसे किसी टूल को साथ में चलाना पड़ता है। Authentik का इन-बिल्ट प्रॉक्सी प्रोवाइडर वही घटक है, जो पहले से ही इंटीग्रेटेड है। यही कारण है कि अधिकांश self-hosters, जिनके पास विभिन्न प्रकार के ऐप्स का मिश्रण है, Authentik को चुनते हैं।

Backups and upgrades

Restore को संभव बनाने के लिए तीन चीजें आवश्यक हैं: PostgreSQL database, ./data directory, और .env।

cd /opt/authentik
docker compose exec -T postgresql pg_dump -U authentik authentik | gzip > authentik-$(date +%F).sql.gz

उस dump और .env को एक साथ सुरक्षित रखें। केवल dump पर्याप्त नहीं है, क्योंकि session और token data को सुरक्षित रखने वाली secret key .env में होती है।

Upgrades एक tag change है। .env में AUTHENTIK_TAG को उस release पर set करें जिसे आप चाहते हैं, फिर docker compose pull चलाएं और उसके बाद docker compose up -d का उपयोग करें। पहले release notes पढ़ें, क्योंकि Authentik date-based versions का उपयोग करता है और कुछ releases में ऐसे migrations होते हैं जिनके लिए आपको पिछले version से upgrade करना आवश्यक होता है। Database dump को pull करने से पहले लें, बाद में नहीं।

FAQ

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

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

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

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

मेरा protected app बार-बार login और error के बीच क्यों घूमता रहता है?

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

Authentik को कितनी RAM की आवश्यकता होती है?

जुलाई 2026 तक, दस्तावेज़ों के अनुसार न्यूनतम आवश्यकता 2 CPU cores और 2 GB RAM है, जिसमें PostgreSQL, server और worker शामिल हैं। 2 GB वाले box पर, memory pressure होने पर kernel सबसे पहले worker process को ही kill करता है, और इसका लक्षण यह है कि background tasks और outbound email रुक जाते हैं जबकि login page काम करता रहता है। यदि उसी server पर वे apps भी चल रहे हैं जिन्हें आप protect कर रहे हैं, तो इसे 4 GB RAM दें।