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

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

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

அந்த Compose கோப்பில் Authentik மூன்று சேவைகளாக வழங்கப்படுகிறது: ஒரு PostgreSQL database, ஒரு server process, மற்றும் ஒரு worker process. சர்வர் container-ல் embedded outpost-ம் இயங்குகிறது; இது பாதுகாக்கப்பட்ட ஒவ்வொரு செயலிக்கும் "இந்த கோரிக்கை உள்நுழைந்துள்ளதா?" என்ற கேள்விக்கு பதிலளிக்கும் அங்கமாகும். ஜூலை 2026 நிலவரப்படி, Version 2026.5 தற்போதைய வெளியீடாக உள்ளது. இந்தத் திட்டத்திற்கு குறைந்தபட்சம் 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 நிலையையும், server மற்றும் worker ஆகியவை running நிலையையும் காட்ட வேண்டும். முதல்முறை தொடங்கும்போதே database migrations நடைபெறும் என்பதால், web interface பதிலளிக்கத் தொடங்குவதற்கு ஒரு நிமிடம் அவகாசம் அளிக்கவும்.

உருவாக்கப்பட்ட இரண்டு மதிப்புகளும் வெவ்வேறு காரணங்களுக்காக முக்கியமானவை. PG_PASS என்பது PostgreSQL கடவுச்சொல், இதற்கு 99 எழுத்துகள் என்ற வரம்பு உள்ளது. AUTHENTIK_SECRET_KEY என்பது sessions மற்றும் tokens-ஐ உறுதிப்படுத்தப் பயன்படுகிறது; எனவே, இதை மாற்றினால் அனைத்து பயனர்களும் வெளியேற்றப்படுவார்கள் மற்றும் நீங்கள் வழங்கிய அனைத்து API tokens-களும் செல்லாததாகிவிடும். .env கோப்பின் அனுமதியை 600 என்ற நிலையில் வைத்து, அதன் நகலை பாதுகாப்பான இடத்தில் சேமிக்கவும். ஏனெனில், அதற்குரிய secret key இல்லாமல் restore செய்யப்படும் database-க்குள் யாராலும் நுழைய முடியாது.

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

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

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

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

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

முதல் உள்நுழைவு மற்றும் நிர்வாகக் கணக்கு

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

Directory பின்னர் Users என்பதற்குள் உங்களுக்கென ஒரு சாதாரண admin user-ஐ உருவாக்கி, அதை authentik Admins group-ல் சேர்த்து, அந்த account மூலம் sign in செய்யவும். நீண்ட password-ஐ offline-ல் சேமித்து, akadmin-ஐ break-glass account-ஆக மட்டும் வைத்திருக்கவும். பகிரப்பட்ட built-in account-ஐ பயன்படுத்தி தினசரி பணிகளைச் செய்வது audit log-ஐ பயனற்றதாக்கும்; ஒவ்வொரு event-லும் akadmin என்று மட்டுமே பதிவாகும், அதை செய்தவர் யார் என்பது தெரியாது. இந்த காரணம் Authentik-க்கு அடுத்துள்ள அமைப்புகளுக்கும் பொருந்தும்: ஒவ்வொரு நபருக்கும் தனித்தனி agent வழங்கும் self-hosted OneCLI harness-க்கு வரும் identity, முழுக் குழுவும் பகிரும் login ஆக இல்லாமல் ஒரே மனிதருக்குச் சொந்தமானதாக இருந்தால் மட்டுமே வாசிக்கக்கூடிய audit trail உருவாகும்.

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

Port 9000-ஐ இணையத்தில் வெளியிடுவது வேலை செய்யும், ஆனால் உங்களுக்கு TLS (transport layer security) மற்றும் முறையான hostname தேவை. நீங்கள் ஏற்கனவே Traefik as a reverse proxy for multiple Compose apps-ல் உள்ள அமைப்பைப் பயன்படுத்துகிறீர்கள் என்றால், ஒரு override கோப்பைப் பயன்படுத்தி 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 என்பது, container proxy network-ல் இல்லை என்பதையும், Traefik-ஆல் அந்த container-ஐ அடைய முடியவில்லை என்பதையும் குறிக்கிறது.

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

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

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

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 தனக்கு வழங்கப்பட்ட செயலிகளுக்கு மட்டுமே பதிலளிக்கும் என்பதால், இந்த கடைசிப் படியைத் தவிர்த்தால், சரியாக உள்ளமைக்கப்பட்ட 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-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-ஐப் பயன்படுத்தும் எந்தவொரு செயலியும் உள்நுழைய முடியாது.

பாதுகாக்கப்பட்ட செயலிக்கு ஒன்றுக்கு பதிலாக இரண்டு 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 இல்லையென்றால், கோரிக்கை செயலிக்குச் சென்று 404 பிழையைத் தரும், உள்நுழைவு முழுமையடையாது. அதிகப்படியான priority மதிப்பானது, அதே டொமைனில் உள்ள சாதாரண Host() விதியை விட, குறிப்பிட்ட பாதை விதியைச் செயல்பட வைக்கிறது.

இதை ஒரு private browser window-ல் சோதிக்கவும். நீங்கள் auth.example.com-க்கு அனுப்பப்பட்டு, உள்நுழைந்து, மீண்டும் செயலிக்கு வர வேண்டும். Authentik பக்கத்தில் உள்ள docker compose logs -f server, ஒவ்வொரு முயற்சிக்கும் ஒரு authorization நிகழ்வைப் பதிவு செய்யும். இதன் மூலம் கோரிக்கை 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-லிருந்து login-களை brokering செய்தல், மற்றும் ஆவணப்படுத்தப்பட்ட migration வழியாக realm-களை export மற்றும் import செய்தல் போன்றவற்றுக்கு இது சிறந்தது. சில நிறுவனங்களுக்கு இதன் வணிக ரீதியான ஆதரவு (commercial support) முக்கியமானது. இதன் பின்னடைவு என்னவென்றால், Keycloak-ல் சொந்தமாக proxy வசதி இல்லை. எனவே, OIDC (OpenID Connect) வசதி இல்லாத ஒரு application-ஐப் பாதுகாக்க, அதன் அருகில் oauth2-proxy போன்ற ஒன்றை இயக்க வேண்டியிருக்கும். Authentik-ல் உள்ள built-in proxy provider இந்த வசதியை ஏற்கனவே ஒருங்கிணைத்து வழங்குகிறது. இதனால்தான், பல்வேறு வகையான application-களைக் கொண்ட பெரும்பாலான self-hosters-கள் Authentik-ஐத் தேர்ந்தெடுக்கிறார்கள்.

Backups and upgrades

மீட்புச் செயல்முறை சாத்தியமாக மூன்று விஷயங்கள் தேவை: 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 ஆகியவற்றை ஒன்றாகச் சேமிக்கவும். session மற்றும் token தரவுகளைப் பாதுகாக்கும் secret key .env-ல் இருப்பதால், dump மட்டும் போதுமானதல்ல.

Upgrades என்பது ஒரு tag மாற்றம் ஆகும். .env-ல் உள்ள AUTHENTIK_TAG-ஐ நீங்கள் விரும்பும் release-க்கு மாற்றவும், பிறகு docker compose pull-ஐ இயக்கி அதைத் தொடர்ந்து docker compose up -d-ஐ இயக்கவும். முதலில் release notes-ஐப் படிக்கவும், ஏனெனில் Authentik தேதி அடிப்படையிலான versions-ஐப் பயன்படுத்துகிறது. சில releases-ல் migrations இருக்கும், அதற்கு முந்தைய version-லிருந்து நீங்கள் upgrade செய்ய வேண்டியிருக்கும். Database dump-ஐ pull செய்வதற்கு முன்பே எடுக்கவும், செய்த பிறகு எடுக்க வேண்டாம்.

FAQ

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

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

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

இல்லை. Forward auth ஆனது nginx-ல் auth_request மூலமாகவும், Caddy-ல் forward_auth மூலமாகவும் செயல்படும். அனைத்து சூழல்களிலும் ஒரே மாதிரியான முறைதான் பின்பற்றப்படுகிறது: reverse proxy ஒவ்வொரு கோரிக்கையையும் (request) Authentik-இடம் சரிபார்க்கும், மேலும் பாதுகாக்கப்பட்ட hostname-ல் உள்ள path prefix /outpost.goauthentik.io/ ஆனது, 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 நிலவரப்படி, PostgreSQL, server மற்றும் worker ஆகியவற்றுக்குச் சேர்த்து குறைந்தபட்சம் 2 CPU cores மற்றும் 2 GB RAM தேவை என ஆவணப்படுத்தப்பட்டுள்ளது. 2 GB RAM கொண்ட server-ல், memory அழுத்தம் ஏற்படும்போது kernel முதலில் worker process-ஐத்தான் நிறுத்தும்; அப்போது login பக்கம் வேலை செய்யும், ஆனால் background பணிகள் மற்றும் மின்னஞ்சல் அனுப்புதல் நின்றுவிடும். நீங்கள் பாதுகாக்கும் application-களும் அதே server-ல் இயங்கினால், 4 GB RAM ஒதுக்குவது சிறந்தது.