Authentik SSO సెటప్ చేయడం ఎలా: Docker Compose గైడ్

మీరు హోస్ట్ చేసే ప్రతి అప్లికేషన్‌కు ఒకే లాగిన్

Authentik అనేది ఒక self-hosted SSO (single sign-on) సర్వర్: మీ వినియోగదారులు ఒక్కసారి లాగిన్ అయితే చాలు, ప్రతి అప్లికేషన్ తన సొంత పాస్‌వర్డ్ అడగకుండా ఆ సెషన్‌ను అంగీకరిస్తుంది. దీని ఇన్‌స్టాలేషన్ కోసం అధికారిక Docker Compose ఫైల్ మరియు రెండు జనరేట్ చేసిన సీక్రెట్స్ అవసరం. దీని తర్వాత అసలైన పని మొదలవుతుంది: ఒక reverse proxy ని దీనికి అనుసంధానించడం మరియు ఇప్పటికే ఉన్న ఒక అప్లికేషన్‌ను forward auth వెనుక ఉంచడం.

Authentik ఆ Compose ఫైల్‌లో మూడు సర్వీసులుగా వస్తుంది: ఒక PostgreSQL డేటాబేస్, ఒక server ప్రాసెస్, మరియు ఒక worker ప్రాసెస్. సర్వర్ కంటైనర్ ఎంబెడెడ్ అవుట్‌పోస్ట్‌ను కూడా రన్ చేస్తుంది, ఇది ప్రతి ప్రొటెక్టెడ్ అప్లికేషన్ కోసం "ఈ అభ్యర్థన లాగిన్ అయి ఉందా?" అనే ప్రశ్నకు సమాధానం ఇచ్చే భాగం. జూలై 2026 నాటికి 2026.5 వెర్షన్ ప్రస్తుత రిలీజ్, మరియు ఈ ప్రాజెక్ట్ కోసం కనీసం 2 CPU కోర్లు మరియు 2 GB RAM ఉన్న హోస్ట్ అవసరమని నిర్దేశించబడింది. దీన్ని కనీస అవసరంగా పరిగణించండి. సర్వర్ ఒక రోజు రన్ అయిన తర్వాత PostgreSQL మరియు వర్కర్ రెండూ మెమరీని ఆక్రమిస్తాయి.

ప్రారంభించడానికి ముందు మీకు కావలసినవి

మీకు Docker Engine తో పాటు Compose v2 ప్లగిన్ అవసరం. దీనిని మీరు docker compose version ద్వారా నిర్ధారించుకోవచ్చు. ఒకవేళ ఇది వెర్షన్ నంబర్‌కు బదులుగా ఎర్రర్‌ను చూపిస్తే, ముందుకు వెళ్లే ముందు ప్లగిన్‌ను ఇన్‌స్టాల్ చేయండి; దీనికి సంబంధించిన ప్రాథమిక అంశాలు VPS పై Docker Compose తో అప్లికేషన్లను రన్ చేయడం లో ఉన్నాయి. అలాగే సర్వర్‌ను సూచించే ఒక DNS A రికార్డు కూడా మీకు అవసరం. కింద ఉన్న ఉదాహరణలలో దీనిని auth.example.com గా పేర్కొన్నాము, ఎందుకంటే బ్రౌజర్ ఉపయోగించిన హోస్ట్‌నేమ్ ఆధారంగానే Authentik తన redirect URLలను రూపొందిస్తుంది.

ఈ స్టాక్‌ను root యూజర్‌గా కాకుండా, docker గ్రూపులో ఉన్న సాధారణ యూజర్‌గా రన్ చేయండి. ఈ గ్రూపులో సభ్యత్వం ఉండటం అంటే హోస్ట్ మెషీన్‌పై root అధికారాలు కలిగి ఉండటంతో సమానం. కాబట్టి, 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 అనేది సెషన్‌లు మరియు టోకెన్‌లను సైన్ చేస్తుంది, కాబట్టి దీన్ని తర్వాత మార్చడం వల్ల వినియోగదారులందరూ లాగ్ అవుట్ అవుతారు మరియు మీరు జారీ చేసిన ప్రతి API టోకెన్ చెల్లదు. .env ఫైల్‌ను 600 మోడ్‌లో ఉంచండి మరియు దాని కాపీని సురక్షితమైన చోట భద్రపరచండి, ఎందుకంటే దానికి సరిపోయే సీక్రెట్ కీ లేకుండా పునరుద్ధరించబడిన డేటాబేస్‌లోకి ఎవరూ లాగిన్ అవ్వలేరు.

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 విలువలు

మిగిలినవన్నీ ఒకే .env ఫైల్‌లో ఉంటాయి. Authentik డబుల్ అండర్‌స్కోర్‌ను నెస్టెడ్ కాన్ఫిగరేషన్ కీగా మారుస్తుంది, కాబట్టి 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కి సెట్ చేయండి.

ఇవి ప్లెయిన్ ఫైల్‌లో ఉండే రహస్యాలు (secrets), కాబట్టి ఈ డైరెక్టరీని మీరు ఇతర క్రెడెన్షియల్ స్టోర్‌లను ఎలా చూస్తారో అలాగే చూడండి. మీ ల్యాప్‌టాప్‌లో నోట్‌గా ఉంచడం కంటే, self-hosted Vaultwarden instance వంటి పాస్‌వర్డ్ మేనేజర్ రికవరీ కాపీని దాచుకోవడానికి సురక్షితమైన ప్రదేశం.

మొదటి లాగిన్ మరియు అడ్మిన్ ఖాతా

బ్రౌజర్‌లో http://SERVER_IP:9000 ని తెరవండి. Authentik దాని ప్రారంభ సెటప్ విధానాన్ని చూపిస్తుంది మరియు డిఫాల్ట్ akadmin వినియోగదారు కోసం పాస్‌వర్డ్‌ను సెట్ చేయమని మిమ్మల్ని అడుగుతుంది. మీరు ఇప్పటికే AUTHENTIK_BOOTSTRAP_PASSWORD సెట్ చేసి ఉంటే, ఆ దశ పూర్తయినట్లే మరియు మీరు నేరుగా లాగిన్ పేజీకి వెళ్తారు.

Directory, తరువాత Users కింద మీ కోసం ఒక సాధారణ admin user ను సృష్టించండి. దాన్ని authentik Admins group కు జోడించి, ఆ account తో sign in చేయండి. akadmin ను break-glass account గా ఉంచి, పొడవైన password ను offline లో భద్రపరచండి.

అందరూ ఉపయోగించే built-in account తో రోజువారీ పనులు చేయడం audit log ను నాశనం చేస్తుంది. ప్రతి event లో akadmin మాత్రమే కనిపిస్తుంది; దాన్ని ఎవరు చేశారో తెలియదు. ఈ కారణం Authentik తర్వాతి స్థాయికీ వర్తిస్తుంది. ఉదాహరణకు, ప్రతి వ్యక్తికి వారి స్వంత agent ను అందించే self-hosted OneCLI harness ను ఉపయోగించినా, దానికి చేరే identity ఒకే వ్యక్తికి చెందినదై ఉండాలి. మొత్తం team పంచుకునే login అయితే మాత్రమే చదవగలిగే trail ఏర్పడదు.

Authentik ను మీ reverse proxy వెనుక ఉంచడం

పోర్ట్ 9000 ను నేరుగా ఇంటర్నెట్‌కు పబ్లిష్ చేయడం పనిచేస్తుంది, కానీ మీకు TLS (transport layer security) మరియు సరైన hostname అవసరం. మీరు ఇప్పటికే Traefik as a reverse proxy for multiple Compose apps లోని సెటప్‌ను వాడుతుంటే, ఒక override ఫైల్ ద్వారా Authentik ను అదే external proxy నెట్‌వర్క్‌కు జత చేయండి. 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 సర్వీస్ అధికారిక ఫైల్‌లోని అన్ని అంశాలను కలిగి ఉండి, అదనంగా ఈ labels ను పొందుతుంది. curl -I https://auth.example.com/if/user/ తో తనిఖీ చేయండి, ఇది HTTP/2 200 అని సమాధానం ఇవ్వాలి. Traefik నుండి 404 page not found వస్తుందంటే, ఆ container proxy నెట్‌వర్క్‌లో లేదని అర్థం; అప్పుడు Traefik ఆ container ను చేరుకోలేదు కాబట్టి దానికి ట్రాఫిక్‌ను పంపలేదు.

Hostname సరిగ్గా పనిచేయడం మొదలయ్యాక, override లో పబ్లిష్ చేసిన పోర్ట్‌లను 127.0.0.1 కి bind చేయండి. దీనివల్ల proxy ద్వారా మాత్రమే లోపలికి ప్రవేశం సాధ్యమవుతుంది.

ఒక అప్లికేషన్‌ను forward authతో రక్షించడం

Authentik యొక్క proxy provider కు మూడు modes ఉన్నాయి. తప్పు mode ఎంచుకుంటే ఒక గంట వరకు సమయం వృథా కావచ్చు. Proxy అంటే outpost స్వయంగా traffic ను upstream app కు forward చేస్తుంది. Forward auth (single application) అంటే మీ reverse proxy traffic ను ముందుకు పంపుతూనే, request కు sign in అయిందా అని Authentik ను మాత్రమే అడుగుతుంది. Forward auth (domain level) ఒకే parent domain కింద ఉన్న ప్రతి app ను ఒకే provider తో రక్షిస్తుంది. అయితే ప్రతి application కు విడిగా authorization rules నిర్వచించే అవకాశం తగ్గుతుంది. ముందు Traefik ఉన్న సందర్భంలో forward auth (single application) ఎంచుకోవాలి. అభ్యాసం కోసం ఒక నిర్దిష్ట app కావాలంటే self-hosted AFFiNE workspace మంచి మొదటి ఎంపిక. మీ స్వంత devices నుంచి మాత్రమే అందుబాటులో ఉండాలి, ఇతర చోట్ల నుంచి ఉండకూడదు అనుకునే internal tool కు ఇది సరిపోతుంది. Team tool అయితే ఈ విధానం మరింత ఉపయోగకరం. అదే provider వెనుక self-hosted Chatwoot support desk ఉంచితే 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ని ఎడిట్ చేయండి, మరియు కొత్త అప్లికేషన్‌ను దాని selected applications జాబితాలోకి చేర్చండి. Outpost తనకు కేటాయించిన అప్లికేషన్‌లకు మాత్రమే సమాధానం ఇస్తుంది, కాబట్టి ఈ చివరి దశను మర్చిపోతే, సరిగ్గా కాన్ఫిగర్ చేసిన provider కూడా ఏమీ చూపదు.

Middlewareను Authentik కంటైనర్‌పై ఒకసారి నిర్వచించి, ప్రతి protected అప్లికేషన్ నుంచి దానిని రిఫరెన్స్ చేయండి:

      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 బ్రౌజర్‌ను auth.example.comపై కాకుండా, app యొక్క hostnameపై ఉన్న /outpost.goauthentik.io/ కింద ఉన్న pathకి పంపుతుంది. ఆ path prefixని Authentik సేవకు పంపే router లేకపోతే, అభ్యర్థన మీ అప్లికేషన్‌కు చేరుతుంది, అక్కడ 404 error వస్తుంది, లాగిన్ ప్రక్రియ పూర్తి కాదు. అధిక priority ఉండటం వల్లే ఒకే domainపై ఉన్న సాధారణ Host() నియమం కంటే, ఈ నిర్దిష్ట path నియమం పనిచేస్తుంది.

దీనిని private browser windowలో పరీక్షించండి. మీరు auth.example.comకి పంపబడాలి, సైన్-ఇన్ చేయాలి, ఆపై తిరిగి అప్లికేషన్‌కు రావాలి. Authentik వైపు ఉన్న docker compose logs -f server ప్రతి ప్రయత్నానికి ఒక authorization ఈవెంట్‌ను ప్రింట్ చేస్తుంది, దీని ద్వారా అభ్యర్థన Authentikకి చేరిందో లేదో తెలుస్తుంది.

మీరు ఎదుర్కొనే వాస్తవ వైఫల్యాలు

అప్లికేషన్ మరియు లాగిన్ పేజీ మధ్య అంతులేని redirect loop. ప్రొవైడర్‌లోని external host, బ్రౌజర్ ఉపయోగిస్తున్న దానితో సరిపోలడం లేదు, సాధారణంగా ప్రొవైడర్‌లో ఉన్న http:// మరియు అడ్రస్ బార్‌లో ఉన్న https:// మధ్య వ్యత్యాసం ఉంటుంది. దీనివల్ల session cookie వేరే origin కోసం సెట్ చేయబడుతుంది, కాబట్టి ప్రతిసారీ తిరిగి వచ్చే అభ్యర్థన కొత్త anonymous అభ్యర్థనలా కనిపిస్తుంది. external host ను సరిచేసి, మళ్ళీ పరీక్షించే ముందు రెండు డొమైన్‌ల కోసం cookies ను క్లియర్ చేయండి.

/outpost.goauthentik.io/start వద్ద 404 ఎర్రర్. outpost router లేదు, లేదా ఆ host కోసం ఉన్న catch-all router కంటే దీని priority తక్కువగా ఉంది.

లాగిన్ అడగకుండానే అప్లికేషన్ లోడ్ అవుతోంది. middlewares లేబుల్ లేని middleware ను సూచిస్తోంది. Traefik దీని గురించి హెచ్చరించదు, కాబట్టి authentik@docker లో చిన్న అక్షర దోషం ఉన్నా ఏ middleware రన్ అవ్వదు. Traefik dashboard ఓపెన్ చేసి, router లో ఆ middleware జాబితా చేయబడిందో లేదో నిర్ధారించుకోండి.

సక్సెస్‌ఫుల్ లాగిన్ తర్వాత Authentik నుంచి 403 ఎర్రర్. వినియోగదారుడు authenticated అయ్యారు కానీ authorized కాలేదు: అప్లికేషన్‌కు ఒక policy binding లేదా group requirement ఉంది, అది ఈ వినియోగదారునికి వర్తించడం లేదు. అడ్మిన్ ఇంటర్‌ఫేస్‌లోని Events లాగ్‌లో ఏ పాలసీ దీనిని తిరస్కరించిందో చూడవచ్చు.

Keycloak ఎప్పుడు సరైన ఎంపిక అవుతుంది

Keycloak అనేది పాత ప్రాజెక్ట్, దీనికి Red Hat మద్దతు ఉంది. సాంప్రదాయ ఎంటర్‌ప్రైజ్ ఐడెంటిటీ పనులకు ఇది బలమైన ఎంపిక: భారీ SAML ఫెడరేషన్, ఒకేసారి అనేక బాహ్య ఐడెంటిటీ ప్రొవైడర్ల నుండి లాగిన్‌లను బ్రోకర్ చేయడం, మరియు డాక్యుమెంట్ చేయబడిన మైగ్రేషన్ మార్గంగా realm ఎగుమతి మరియు దిగుమతి వంటివి ఇందులో ఉన్నాయి. వాణిజ్యపరమైన మద్దతు ఉండటం కొన్ని సంస్థలకు ముఖ్యమైన అంశం. అయితే, Keycloak కు సొంతంగా ప్రాక్సీ లేదు; కాబట్టి OIDC (OpenID Connect) తెలియని అప్లికేషన్‌ను రక్షించాలంటే, దాని పక్కన oauth2-proxy వంటివి నడపాల్సి ఉంటుంది. Authentik లోని అంతర్నిర్మిత ప్రాక్సీ ప్రొవైడర్ ఇప్పటికే కలిసి ఉంటుంది, అందుకే వివిధ రకాల అప్లికేషన్లు కలిగిన చాలా మంది self-hosters దీనిని ఎంచుకుంటారు.

బ్యాకప్‌లు మరియు అప్‌గ్రేడ్‌లు

రీస్టోర్ సాధ్యపడాలంటే మూడు విషయాలు అవసరం: PostgreSQL డేటాబేస్, ./data డైరెక్టరీ, మరియు .env.

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

ఆ డంప్‌ను మరియు .env ను కలిపి భద్రపరచండి. కేవలం డంప్ మాత్రమే సరిపోదు, ఎందుకంటే సెషన్ మరియు టోకెన్ డేటాను రక్షించే సీక్రెట్ కీ .env లో ఉంటుంది.

అప్‌గ్రేడ్‌లు అంటే ట్యాగ్ మార్పు మాత్రమే. .env లో AUTHENTIK_TAG ను మీకు కావలసిన రిలీజ్ వెర్షన్‌కు సెట్ చేయండి, ఆపై docker compose pull ను రన్ చేసి, దాని తర్వాత docker compose up -d ను అమలు చేయండి. ముందుగా రిలీజ్ నోట్స్‌ను చదవండి, ఎందుకంటే Authentik తేదీ ఆధారిత వెర్షన్లను ఉపయోగిస్తుంది మరియు కొన్ని రిలీజ్‌లలో మునుపటి వెర్షన్ నుండి అప్‌గ్రేడ్ అయ్యేటప్పుడు అవసరమైన మైగ్రేషన్లు ఉంటాయి. డేటాబేస్ డంప్‌ను పుల్ (pull) చేయడానికి ముందే తీసుకోండి, తర్వాత కాదు.

FAQ

Authentik ను self-host చేసుకోవడం ఉచితమేనా?

దీని open source ఎడిషన్ ఉచితం మరియు పైన పేర్కొన్న అన్ని ఫీచర్లను అందిస్తుంది: proxy provider, forward auth, OIDC (OpenID Connect), SAML, మరియు flows engine. చెల్లింపుతో కూడిన enterprise tier లో మద్దతు (support) మరియు కొన్ని ప్రత్యేక ఫీచర్లు ఉంటాయి, కానీ ఇక్కడ వివరించిన దేనికీ లైసెన్స్ అవసరం లేదు.

Authentik ఉపయోగించడానికి నాకు Traefik అవసరమా?

అవసరం లేదు. Forward auth అనేది nginx తో auth_request ద్వారా మరియు Caddy తో forward_auth ద్వారా పనిచేస్తుంది. అన్ని సందర్భాల్లోనూ పద్ధతి ఒకటే: ప్రతి అభ్యర్థన (request) గురించి reverse proxy, Authentik ను అడుగుతుంది. రక్షించబడిన hostname పై ఉన్న path prefix /outpost.goauthentik.io/, అప్లికేషన్‌కు బదులుగా Authentik వైపు మళ్లించబడాలి.

నా protected app ఎందుకు login మరియు error పేజీల మధ్య నిరంతరం తిరుగుతోంది?

Proxy provider లో కాన్ఫిగర్ చేసిన external host, బ్రౌజర్ ఉపయోగిస్తున్న URL తో సరిపోలడం లేదు. సాధారణంగా ఇది http మరియు https మధ్య తేడాల వల్ల జరుగుతుంది. Session cookie ఒక origin కోసం జారీ చేయబడి, మరొక దానిపై చదవబడుతోంది, కాబట్టి Authentik ప్రతిసారీ అభ్యర్థనను anonymous గా గుర్తిస్తుంది. External host ను సరిచేసి, మళ్ళీ పరీక్షించే ముందు రెండు hostname ల కోసం cookies ను క్లియర్ చేయండి.

Authentik కు ఎంత RAM అవసరం?

జూలై 2026 నాటికి, డాక్యుమెంట్ చేయబడిన కనీస అవసరం 2 CPU కోర్లు మరియు 2 GB RAM. ఇది PostgreSQL, సర్వర్ మరియు వర్కర్‌ను కలిపి పరిగణనలోకి తీసుకుంటుంది. 2 GB ఉన్న సర్వర్‌లో, మెమరీ ఒత్తిడి పెరిగినప్పుడు kernel మొదట వర్కర్ ప్రాసెస్‌ను నిలిపివేస్తుంది. దీనివల్ల లాగిన్ పేజీ పనిచేస్తున్నప్పటికీ, బ్యాక్‌గ్రౌండ్ టాస్క్‌లు మరియు అవుట్‌బౌండ్ ఈమెయిల్స్ ఆగిపోతాయి. మీరు రక్షిస్తున్న అప్లికేషన్లు కూడా అదే సర్వర్‌లో నడుస్తుంటే, దానికి 4 GB RAM కేటాయించండి.