Authentik SSO நிறுவுவது எப்படி: Docker Compose வழிகாட்டி

நீங்கள் ஹோஸ்ட் செய்யும் ஒவ்வொரு செயலிக்கும் ஒரே லாகின்

Authentik என்பது ஒரு self-hosted SSO (single sign-on) server ஆகும்: பயனர்கள் ஒருமுறை லாகின் செய்தால் போதும், அதன் பின்னால் உள்ள ஒவ்வொரு செயலியும் தனித்தனியாக கடவுச்சொல் கேட்காமல் அந்த session-ஐ ஏற்றுக்கொள்கிறது. இதன் நிறுவல் ஒரு அதிகாரப்பூர்வ Docker Compose கோப்பு மற்றும் உருவாக்கப்பட்ட இரண்டு secrets மூலம் நடைபெறுகிறது. இதற்குப் பிறகு செய்ய வேண்டியவைதான் முக்கியமானவை: ஒரு reverse proxy-ஐ இதனுடன் இணைப்பது மற்றும் ஏற்கனவே உள்ள ஒரு செயலியை forward auth-ன் கீழ் கொண்டு வருவது.

Authentik அந்த Compose கோப்பில் மூன்று சேவைகளாக இயங்குகிறது: ஒரு PostgreSQL database, ஒரு server process, மற்றும் ஒரு worker process. server container-ல் embedded outpost-ம் இயங்குகிறது; இதுவே பாதுகாக்கப்பட்ட ஒவ்வொரு செயலிக்கும் "இந்த கோரிக்கை லாகின் செய்யப்பட்டுள்ளதா?" என்ற கேள்விக்கு பதிலளிக்கும் அங்கமாகும். 25 அக்டோபர் 2026 நிலவரப்படி, 2026.8.5 பதிப்பு தற்போதைய release ஆகும். இது 21 அக்டோபர் 2026 அன்று 2026.8 தொடரின் சமீபத்திய patch-ஆக வெளியிடப்பட்டது. இந்தத் தொடர் 18 ஆகஸ்ட் அன்று 2026.8.0 உடன் தொடங்கியது. இது 14 அக்டோபர் அன்று வெளியான 2026.8.4 பதிப்பிற்குப் பதிலாக அதிகாரப்பூர்வ Compose கோப்பில் default image tag-ஆக மாற்றப்பட்டுள்ளது. இந்தத் திட்டத்திற்கு குறைந்தபட்சம் 2 CPU cores மற்றும் 2 GB RAM கொண்ட host தேவை. இதை அடிப்படைத் தேவையாகக் கருதுங்கள். ஒரு நாள் இயங்கிய பிறகு, PostgreSQL மற்றும் worker ஆகிய இரண்டும் நினைவகத்தை (memory) ஆக்கிரமிக்கும்.

தொடங்குவதற்கு முன் உங்களுக்குத் தேவையானவை

உங்களிடம் Docker Engine மற்றும் அதனுடன் Compose v2 plugin இருக்க வேண்டும். இதை docker compose version கட்டளை மூலம் உறுதிப்படுத்தலாம். இது பதிப்பு எண்ணிற்குப் பதிலாக பிழையைக் காட்டினால், அடுத்த கட்டத்திற்குச் செல்லும் முன் plugin-ஐ நிறுவவும்; இதன் அடிப்படை விவரங்கள் VPS-ல் Docker Compose மூலம் செயலிகளை இயக்குதல் என்ற பகுதியில் உள்ளன. மேலும், உங்கள் server-ஐச் சுட்டிக்காட்டும் DNS A record ஒன்று தேவை. கீழே உள்ள உதாரணங்களில் auth.example.com பயன்படுத்தப்பட்டுள்ளது, ஏனெனில் Authentik தனது redirect URL-களை browser பயன்படுத்திய hostname-ஐ வைத்தே உருவாக்குகிறது.

இந்த stack-ஐ root பயனராக இயக்காமல், docker குழுவில் உள்ள ஒரு சாதாரண பயனராக இயக்கவும். இந்த குழுவில் உறுப்பினராக இருப்பது, host-ல் root அதிகாரத்திற்குச் சமமானது. எனவே, VPS-ல் குறைந்தபட்ச அதிகாரங்களைக் கொண்ட பயனர் கணக்குகள் என்ற வழிகாட்டுதலின்படி, ஒரு deploy கணக்கிற்கு மட்டும் இந்த அனுமதியை வழங்கவும், மற்றவர்களுக்கு வழங்க வேண்டாம்.

அதிகாரப்பூர்வ 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 கட்டளை மூன்று containers-ம் இயங்குவதைக் காட்ட வேண்டும், மேலும் postgresql அதன் சோதனையை முடித்தவுடன் healthy என்று காட்ட வேண்டும். முதல் தொடக்கத்தின் போது database migrations நடக்கும், எனவே web interface பதிலளிக்க ஒரு நிமிடம் காத்திருக்கவும்.

உருவாக்கப்பட்ட இரண்டு மதிப்புகளும் வெவ்வேறு காரணங்களுக்காக முக்கியமானவை. PG_PASS என்பது PostgreSQL கடவுச்சொல். Authentik நிறுவல் ஆவணங்களின்படி, 99 எழுத்துகளுக்கு மேல் உள்ள கடவுச்சொற்கள் ஆதரிக்கப்படாது, எனவே நீங்கள் உருவாக்கும் கடவுச்சொல்லை அதற்குள் வைத்திருக்கவும்; உருவாக்கப்பட்ட கடவுச்சொல் இதைவிட மிகச் சிறியது. AUTHENTIK_SECRET_KEY என்பது cookies-ஐ கையொப்பமிட Authentik பயன்படுத்தும் key ஆகும். இதை மாற்றினால் செயலில் உள்ள sessions செல்லாததாகிவிடும் என்று ஆவணங்கள் கூறுகின்றன, எனவே புதிய key-ஐ மாற்றினால் லாகின் செய்துள்ள அனைவரும் வெளியேற்றப்படுவார்கள். .env-ஐ mode 600-ல் வைத்திருக்கவும், அதன் நகலை உங்கள் backups-உடன் பாதுகாப்பான இடத்தில் வைக்கவும், அப்போதுதான் restore செய்யும்போது அதே key-உடன் server மீண்டும் இயங்கும்.

Compose கோப்பு இந்த இரண்டு மதிப்புகளையும் ${VAR:?message} படிவத்தின் மூலம் கட்டாயமாக்குகிறது: PostgreSQL சேவையில் ${PG_PASS:?database password required} மற்றும் server மற்றும் worker-ல் ${AUTHENTIK_SECRET_KEY:?secret key required}. அதாவது, கோப்பு விடுபட்டால் Compose தொடங்க மறுக்கும். தவறான கோப்பகத்திலிருந்து docker compose up -d-ஐ இயக்கினால், required variable AUTHENTIK_SECRET_KEY is missing a value: secret key required போன்ற ஒரு வரியைக் காட்டி நின்றுவிடும். அந்தச் செய்தி ஒரு path சிக்கலே தவிர, config சிக்கல் அல்ல.

முக்கியமான environment மதிப்புகள்

மற்ற அனைத்தும் அதே .env கோப்பில் அமையும். Authentik, double underscore-ஐ ஒரு nested configuration key-ஆக மாற்றுகிறது, எனவே AUTHENTIK_EMAIL__HOST என்பது email.host-ஐ அமைக்கிறது. Single underscore-ஐப் பயன்படுத்தினால் அது nested key-ஆக மாறாது; ஒரு setting வேலை செய்யவில்லை என்றால், பெரும்பாலும் இதுவே காரணமாக இருக்கும்.

• AUTHENTIK_BOOTSTRAP_PASSWORD, முதல் தொடக்கத்தின்போதே உள்ளமைக்கப்பட்ட akadmin பயனருக்கான கடவுச்சொல்லை அமைக்கிறது, எனவே நீங்கள் பொது இணையதளப் படிவத்தில் அதை உள்ளிட வேண்டியதில்லை. AUTHENTIK_BOOTSTRAP_EMAIL மற்றும் AUTHENTIK_BOOTSTRAP_TOKEN ஆகியவை அந்தப் பயனரின் மின்னஞ்சல் முகவரி மற்றும் API token-ஐ அதே முறையில் அமைக்கின்றன.
• COMPOSE_PORT_HTTP மற்றும் COMPOSE_PORT_HTTPS ஆகியவை default-ஆக உள்ள 9000 மற்றும் 9443 ports-க்கு மாற்றாக வேறு ports-ஐ அமைக்கின்றன.
• AUTHENTIK_EMAIL__HOST, AUTHENTIK_EMAIL__PORT, AUTHENTIK_EMAIL__USERNAME, AUTHENTIK_EMAIL__PASSWORD, AUTHENTIK_EMAIL__USE_TLS மற்றும் AUTHENTIK_EMAIL__FROM ஆகியவை வெளிச்செல்லும் மின்னஞ்சல் (outbound mail) அமைப்புகளைக் கட்டமைக்கின்றன. இவை இல்லையென்றால், Authentik ஆனது port 25-ல் localhost-ஐப் பயன்படுத்த முயலும், இதனால் கடவுச்சொல் மாற்றும் மின்னஞ்சல்கள் worker log-ல் connection error-ஆகக் காட்டும்.
• AUTHENTIK_LOG_LEVEL=debug, login flow சரியாகச் செயல்படாதபோது உங்களுக்குத் தேவையான கூடுதல் விவரங்களைக் காட்டும். வேலை முடிந்ததும் அதை மீண்டும் info-க்கு மாற்றவும்.
• AUTHENTIK_ERROR_REPORTING__ENABLED என்பது default-ஆக false என்று இருக்கும். நீங்கள் crash reports-ஐ upstream-க்கு அனுப்ப விரும்பினால் மட்டுமே அதை true என மாற்றவும்.

இவை plain file-ல் உள்ள ரகசியங்கள் என்பதால், இந்த directory-ஐ மற்ற credential store-களைப் போலவே பாதுகாப்பாகக் கையாளவும். உங்கள் laptop-ல் குறிப்புகளாக வைத்திருப்பதை விட, self-hosted Vaultwarden instance போன்ற password manager-ல் இதன் நகலைச் சேமிப்பது சிறந்தது.

முதல் லாகின் மற்றும் admin கணக்கு

ஒரு browser-ல் http://SERVER_IP:9000-ஐத் திறக்கவும். Authentik அதன் ஆரம்ப அமைவு முறையைக் காட்டி, default akadmin பயனருக்கு கடவுச்சொல்லை அமைக்கக் கேட்கும். நீங்கள் ஏற்கனவே AUTHENTIK_BOOTSTRAP_PASSWORD-ஐ அமைத்திருந்தால், அந்தப் படி முடிந்து நேரடியாக லாகின் பக்கத்திற்குச் செல்வீர்கள்.

Directory மற்றும் Users பகுதிக்குச் சென்று உங்களுக்கென ஒரு சாதாரண admin பயனரை உருவாக்கவும், அவரை authentik Admins குழுவில் சேர்க்கவும், அந்த கணக்கின் மூலம் லாகின் செய்யவும். akadmin-ஐ ஒரு அவசரக்கால கணக்காக (break-glass account) வைத்து, அதன் நீண்ட கடவுச்சொல்லை offline-ல் சேமிக்கவும். ஏதேனும் ஒரு சிக்கலால் நீங்கள் லாக்-அவுட் செய்யப்பட்டால், docker compose run --rm server create_recovery_key 10 akadmin-ஐ /opt/authentik-லிருந்து இயக்கினால், அது உங்களை நேரடியாக akadmin ஆக லாகின் செய்யும் இணைப்பை வழங்கும். அந்த இணைப்பை வைத்திருப்பவர் அதே அணுகலைப் பெறுவார், எனவே அதை கடவுச்சொல் போலவே பாதுகாப்பாகக் கையாளவும். ஒரு பொதுவான கணக்கைப் பயன்படுத்தி அன்றாட வேலைகளைச் செய்வது audit log-ஐ அழித்துவிடும், ஏனெனில் ஒவ்வொரு நிகழ்வும் akadmin என்று மட்டுமே காட்டும், யார் செய்தார்கள் என்று தெரியாது. இந்த வாதம் Authentik-க்கு அப்பாலும் பொருந்தும்: ஒவ்வொரு நபருக்கும் தனித்தனி agent-ஐ வழங்கும் self-hosted OneCLI harness போன்ற அமைப்புகள், ஒரு குழுவினர் பகிரும் லாகின்-ஐ விட, ஒரு தனி மனிதனின் அடையாளத்தை வைத்திருந்தால் மட்டுமே தெளிவான தடயத்தை வழங்கும்.

Authentik-ஐ உங்கள் reverse proxy-க்கு பின்னால் அமைத்தல்

Port 9000-ஐ இணையத்தில் வெளியிடுவது வேலை செய்யும், ஆனால் உங்களுக்கு TLS (transport layer security) மற்றும் முறையான hostname தேவை. நீங்கள் ஏற்கனவே Traefik as a reverse proxy for multiple Compose apps-ல் உள்ள அமைப்பை இயக்குகிறீர்கள் என்றால், ஒரு 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-ஐ இணைத்துக்கொள்ளும், எனவே server service அதிகாரப்பூர்வ கோப்பில் உள்ள அனைத்தையும் தக்கவைத்துக்கொண்டு இந்த labels-ஐயும் பெற்றுக்கொள்ளும். curl -I https://auth.example.com/if/user/ மூலம் சரிபார்க்கவும், இது HTTP/2 200 என்று பதிலளிக்க வேண்டும். Traefik-லிருந்து வரும் 404 page not found என்பது எந்த router-ம் அந்த கோரிக்கையுடன் பொருந்தவில்லை என்று அர்த்தம். Labels container-க்கு சென்றடைந்துள்ளதா, Host() விதி hostname-உடன் சரியாகப் பொருந்துகிறதா, மற்றும் கோரிக்கை router listening-ல் உள்ள HTTPS entry point-க்கு வந்துள்ளதா என்பதைச் சரிபார்க்கவும்.

Hostname வேலை செய்யத் தொடங்கியதும், override-ல் உள்ள published ports-ஐ 127.0.0.1-க்கு bind செய்யுங்கள், அப்போதுதான் proxy வழியாக மட்டுமே உள்ளே நுழைய முடியும்.

Forward auth மூலம் ஒரு செயலியைப் பாதுகாத்தல்

Authentik-ன் proxy provider மூன்று முறைகளைக் கொண்டுள்ளது, அவற்றில் தவறானதைத் தேர்ந்தெடுப்பது நேரத்தை வீணடிக்கும். Proxy முறை என்பது, outpost-ஆனது போக்குவரத்தை (traffic) நேரடியாக upstream செயலிக்கு அனுப்புவதைக் குறிக்கும். Forward auth (single application) முறை என்பது, உங்கள் reverse proxy போக்குவரத்தைக் கையாண்டு, அந்த request அங்கீகரிக்கப்பட்டதா என்பதை மட்டும் Authentik-இடம் கேட்பதைக் குறிக்கும். Forward auth (domain level) முறை, ஒரு parent domain-ன் கீழ் உள்ள அனைத்து செயலிகளையும் ஒரே provider மூலம் பாதுகாக்கும், ஆனால் ஒவ்வொரு செயலிக்கும் தனித்தனி அங்கீகார விதிகளை (authorization rules) அமைக்க முடியாது. Traefik-ஐ முன்னால் பயன்படுத்தும்போது, நீங்கள் forward auth (single application) முறையையே தேர்ந்தெடுக்க வேண்டும். பயிற்சி செய்ய ஒரு செயலியைத் தேடுகிறீர்கள் என்றால், self-hosted AFFiNE workspace ஒரு சிறந்த தேர்வாகும், ஏனெனில் இது உங்கள் சாதனங்களிலிருந்து மட்டும் அணுகப்பட வேண்டிய ஒரு internal tool ஆகும். ஒரு குழுவிற்கான கருவியாக இருந்தால், self-hosted Chatwoot support desk-ஐ அதே provider-ன் பின்னால் வைப்பதன் மூலம், பயனர்கள் ஒவ்வொரு முறையும் கடவுச்சொல்லைப் பகிராமல், ஒருமுறை உள்நுழைந்தாலே போதுமானது.

Web interface-ல், Applications பகுதிக்குச் சென்று Providers-ஐத் திறக்கவும். ஒரு Proxy Provider-ஐ உருவாக்கி, forward auth single application முறையைத் தேர்ந்தெடுக்கவும். பிறகு external host-ஐ https://app.example.com என அமைக்கவும். அந்த provider-ஐக் குறிக்கும் வகையில் ஒரு Application-ஐ உருவாக்கவும். பின்னர் Outposts பகுதிக்குச் சென்று, authentik Embedded Outpost-ஐத் திருத்தி, புதிய application-ஐ அதன் selected applications பட்டியலில் சேர்க்கவும். ஒரு outpost தனக்கு வழங்கப்பட்ட application-களுக்கு மட்டுமே பதிலளிக்கும் என்பதால், இந்த கடைசிப் படியைத் தவிர்த்தால், சரியாக உள்ளமைக்கப்பட்ட provider-ம் எந்த முடிவையும் தராது.

Middleware-ஐ Authentik container-ல் ஒருமுறை வரையறுத்து, அதைப் பாதுகாக்கப்பட்ட ஒவ்வொரு செயலியிலிருந்தும் குறிப்பிடவும்:

      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 என்பது Authentik-ன் பதிலிலிருந்து Traefik நகலெடுத்து upstream-க்கு அனுப்பும் headers-ன் பட்டியல் ஆகும். இதைத் தவிர்த்தால், செயலி பாதுகாக்கப்பட்டிருக்கும், ஆனால் பயனர் யார் என்பது அதற்குத் தெரியாது. எனவே, தானியங்கி உள்நுழைவிற்காக X-authentik-username-ஐப் பயன்படுத்தும் எந்தவொரு செயலியும் உள்நுழையப்படாமலேயே இருக்கும். self-hosted openGym workout tracker போன்ற சொந்தமாக உள்நுழைவு வசதி கொண்ட செயலிகளில் இந்த இடைவெளி தெளிவாகத் தெரியும்; headers சரியாக இருந்தால் மட்டுமே ஒரே பக்கத்திற்கு இரண்டு முறை உள்நுழைய வேண்டிய அவசியம் இருக்காது.

பாதுகாக்கப்பட்ட செயலிக்கு ஒரு router போதாது, இரண்டு 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-ஐத்தான் அனைவரும் மறந்துவிடுகிறார்கள். உள்நுழைந்த பிறகு, Authentik உலாவியை (browser) auth.example.com-க்கு பதிலாக, செயலியின் hostname-ல் உள்ள /outpost.goauthentik.io/ என்ற பாதைக்குத் திருப்பிவிடும். அந்தப் பாதையை Authentik சேவைக்கு அனுப்பும் router இல்லையென்றால், request செயலிக்குச் சென்று 404 பிழையைத் தரும், உள்நுழைவு முழுமையடையாது. அதிகப்படியான priority முன்னுரிமைதான், அதே domain-ல் உள்ள சாதாரண Host() விதியை விட, இந்த குறிப்பிட்ட பாதை விதியைச் செயல்பட வைக்கிறது.

இதை ஒரு private browser window-ல் சோதிக்கவும். நீங்கள் auth.example.com-க்கு அனுப்பப்பட்டு, உள்நுழைந்து, மீண்டும் செயலிக்குத் திரும்ப வேண்டும். Authentik பக்கத்தில் உள்ள docker compose logs -f server ஒவ்வொரு முயற்சியின் போதும் ஒரு authorization event-ஐ அச்சிடும்; இதன் மூலம் request Authentik-ஐ அடைந்ததா என்பதை உறுதிப்படுத்தலாம்.

நீங்கள் உண்மையில் எதிர்கொள்ளும் தோல்விகள்

Application மற்றும் login பக்கத்திற்கு இடையே முடிவற்ற redirect loop. Provider-ல் உள்ள external host, browser பயன்படுத்தும் host-உடன் ஒத்துப்போவதில்லை. பொதுவாக, address bar-ல் உள்ள https://-க்கு மாறாக, provider-ல் http:// என அமைக்கப்பட்டிருக்கும். இதனால் session cookie வேறு ஒரு origin-க்கு அமைக்கப்படுகிறது; ஒவ்வொரு முறையும் வரும் கோரிக்கையும் புதிய anonymous கோரிக்கையாகவே கருதப்படுகிறது. External host-ஐச் சரிசெய்து, மீண்டும் சோதிக்கும் முன் இரு domain-களுக்கும் உள்ள cookies-ஐ நீக்கவும்.

/outpost.goauthentik.io/start-ல் 404 பிழை. Outpost router விடுபட்டுள்ளது அல்லது அந்த host-க்கான catch-all router-ஐ விட இதன் முன்னுரிமை (priority) குறைவாக உள்ளது.

Login கேட்காமலேயே application ஏற்றப்படுகிறது. middlewares label, இல்லாத ஒரு middleware-ஐக் குறிக்கிறது. Traefik இதைப் பற்றி எச்சரிக்கை செய்யாது, எனவே authentik@docker-ல் உள்ள எழுத்துப் பிழை (typo) எந்த middleware-உம் இயங்கவில்லை என்பதையே குறிக்கும். Traefik dashboard-ஐத் திறந்து, router-ல் அந்த middleware பட்டியலிடப்பட்டுள்ளதா என்பதை உறுதிப்படுத்தவும்.

வெற்றிகரமான login-க்குப் பிறகு Authentik-லிருந்து 403 பிழை. பயனர் அங்கீகரிக்கப்பட்டார் (authenticated), ஆனால் அனுமதி பெறவில்லை (authorized). அந்த application-க்கு ஒரு policy binding அல்லது group requirement உள்ளது, அதை இந்த பயனர் பூர்த்தி செய்யவில்லை. Admin interface-ல் உள்ள Events log, எந்த policy இந்த அணுகலை மறுத்தது என்பதைக் காட்டும்.

Keycloak எப்போது சிறந்த தேர்வாகிறது

Keycloak என்பது Red Hat ஆதரவுடன் இயங்கும் ஒரு பழைய project ஆகும். இது பாரம்பரியமான enterprise identity பணிகளுக்கு மிகவும் பொருத்தமானது. இதில் SAML federation, ஒரே நேரத்தில் பல external identity providers மூலம் logins-ஐ brokering செய்தல், மற்றும் ஆவணப்படுத்தப்பட்ட migration வழியாக realm export/import செய்தல் போன்ற வசதிகள் உள்ளன. சில நிறுவனங்களுக்கு இதன் வணிக ரீதியான ஆதரவு (commercial support) முக்கியமானது. இதன் குறைபாடு என்னவென்றால், Keycloak-ல் சொந்தமாக proxy வசதி இல்லை. எனவே, OIDC (OpenID Connect) அல்லது SAML ஆகியவற்றை ஆதரிக்காத ஒரு application-ஐப் பாதுகாக்க, அதன் அருகில் oauth2-proxy போன்ற ஒன்றை இயக்க வேண்டியிருக்கும். Authentik-ல் உள்ள built-in proxy provider ஏற்கனவே ஒருங்கிணைக்கப்பட்ட ஒரு வசதியாகும். பல்வேறு வகையான applications-ஐத் தாங்களே host செய்யும் பெரும்பாலான பயனர்கள் இதனாலேயே Authentik-ஐத் தேர்ந்தெடுக்கிறார்கள்.

Backups மற்றும் மேம்படுத்தல்கள்

மூன்று விஷயங்கள் restore-ஐ சாத்தியமாக்குகின்றன: PostgreSQL database, ./data கோப்பகம், மற்றும் .env.

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

அந்த dump மற்றும் .env-ஐ ஒன்றாகச் சேமிக்கவும். அந்த dump-ல் AUTHENTIK_SECRET_KEY-ன் நகல் இருக்காது, மேலும் வேறொரு key-ன் கீழ் restore செய்தால் செயலில் உள்ள அனைத்து sessions-ம் செல்லாததாகிவிடும், எனவே அசல் key-ஐ வைத்திருப்பது restore செய்யப்பட்ட server-ஐ பழைய நிலையிலேயே தொடர உதவும்.

மேம்படுத்தல்கள் (upgrades) என்பது ஒரு tag மாற்றம். .env-ல் AUTHENTIK_TAG-ஐ நீங்கள் விரும்பும் பதிப்பிற்கு அமைக்கவும், பின்னர் docker compose pull மற்றும் அதைத் தொடர்ந்து docker compose up -d-ஐ இயக்கவும். நீங்கள் AUTHENTIK_TAG-ஐ ஒருபோதும் அமைக்கவில்லை என்றால், பதிப்பு compose.yml-ல் எழுதப்பட்ட default மதிப்பிலிருந்து வரும், எனவே அந்த கோப்பின் புதிய நகலைப் பதிவிறக்குவதே மேம்படுத்தல் ஆகும், இதுவே அதிகாரப்பூர்வ மேம்படுத்தல் ஆவணங்கள் விவரிக்கும் வழியாகும். முதலில் release notes-ஐப் படிக்கவும். Authentik தேதி அடிப்படையிலான பதிப்புகளைப் பயன்படுத்துகிறது, அக்டோபர் 2026 நிலவரப்படி, மேம்படுத்தல்கள் major releases வரிசையைப் பின்பற்ற வேண்டும் என்று ஆவணங்கள் கூறுகின்றன: நீங்கள் இயக்கும் தொடரின் சமீபத்திய patch-க்குச் செல்லவும், பின்னர் எந்தத் தொடரையும் தவிர்க்காமல் வரிசையாக அடுத்தடுத்த தொடர்களுக்குச் செல்லவும். Authentik downgrading-ஐ ஆதரிக்காது, எனவே pull செய்வதற்கு முன்பே database dump-ஐ எடுக்கவும்.

FAQ

Authentik-ஐ self-host செய்வது இலவசமா?

இதன் open source பதிப்பு இலவசமானது மற்றும் மேலே குறிப்பிடப்பட்ட அனைத்து வசதிகளையும் உள்ளடக்கியது: proxy provider, forward auth, OIDC (OpenID Connect), SAML, மற்றும் flows engine. கட்டணத்துடன் கூடிய enterprise tier கூடுதல் ஆதரவையும் சில சிறப்பு வசதிகளையும் வழங்குகிறது, ஆனால் இங்கு விவரிக்கப்பட்டுள்ள எதற்கும் உரிமம் (licence) தேவையில்லை.

Authentik-ஐப் பயன்படுத்த Traefik அவசியமா?

இல்லை. Forward auth ஆனது nginx-உடன் auth_request மூலமாகவும், Caddy-உடன் forward_auth மூலமாகவும் செயல்படும். அனைத்து சூழல்களிலும் ஒரே முறைதான் பின்பற்றப்படுகிறது: reverse proxy ஒவ்வொரு கோரிக்கையையும் (request) Authentik-இடம் சரிபார்க்கும், மேலும் பாதுகாக்கப்பட்ட hostname-ல் உள்ள /outpost.goauthentik.io/ என்ற path prefix, application-க்கு பதிலாக Authentik-ஐ நோக்கிச் செல்ல வேண்டும்.

எனது பாதுகாக்கப்பட்ட application ஏன் login பக்கத்திற்கும் error பக்கத்திற்கும் இடையே தொடர்ந்து மாறிக்கொண்டே இருக்கிறது?

Proxy provider-ல் உள்ளமைக்கப்பட்ட (configured) external host, browser பயன்படுத்தும் URL-உடன் ஒத்துப்போகவில்லை; பெரும்பாலும் http மற்றும் https ஆகியவற்றுக்கு இடையே உள்ள முரண்பாடே இதற்குக் காரணம். Session cookie ஒரு origin-க்காக வழங்கப்பட்டு வேறொன்றில் வாசிக்கப்படுவதால், Authentik ஒவ்வொரு முறையும் அதை ஒரு anonymous கோரிக்கையாகவே பார்க்கிறது. External host-ஐச் சரிசெய்துவிட்டு, மீண்டும் சோதிக்கும் முன் இரண்டு hostname-களுக்கும் உள்ள cookies-ஐயும் நீக்கவும்.

Authentik-க்கு எவ்வளவு RAM தேவை?

அக்டோபர் 2026 நிலவரப்படி, ஆவணப்படுத்தப்பட்ட குறைந்தபட்ச தேவை 2 CPU cores மற்றும் 2 GB RAM ஆகும்; இது PostgreSQL, server மற்றும் worker ஆகிய அனைத்தையும் உள்ளடக்கியது. 2 GB அளவுள்ள server-ல், memory அழுத்தம் காரணமாக kernel-ன் OOM killer தூண்டப்படலாம்; இது அதிக badness score கொண்ட process-ஐ முடித்துவிடும்: இது பெரும்பாலும் அனுமதிக்கப்பட்ட memory-ல் அது பயன்படுத்தும் பங்கு மற்றும் அதன் oom_score_adj ஆகியவற்றைப் பொறுத்தது. Worker process முடிவுக்கு வரும்போது, login பக்கம் வேலை செய்யும், ஆனால் background பணிகள் மற்றும் மின்னஞ்சல் அனுப்புதல் நின்றுவிடும். நீங்கள் பாதுகாக்கும் application-களும் அதே server-ல் இயங்கினால், 4 GB RAM வழங்குவது சிறந்தது.