โดย Matt Connor 2026-07-31 · อัปเดตเมื่อ 2026-08-28

วิธีติดตั้ง Authentik SSO ด้วย Docker Compose อย่างละเอียด

Q: จำเป็นต้องใช้ Traefik เพื่อใช้งาน Authentik หรือไม่?

ไม่จำเป็น Forward auth สามารถใช้งานร่วมกับ nginx ผ่าน auth_request และ Caddy ผ่าน forward_auth ได้ รูปแบบการทำงานจะเหมือนกันในทุกกรณี คือ reverse proxy จะส่งคำถามไปยัง Authentik สำหรับทุกคำขอ และ path prefix /outpost.goauthentik.io/ บน hostname ที่ต้องการป้องกันจะต้องถูกกำหนดให้ส่งต่อไปยัง Authentik แทนที่จะส่งไปยังแอปพลิเคชันโดยตรง

เรียนรู้วิธีตั้งค่า Authentik ระบบ SSO แบบ self-hosted เพื่อจัดการการล็อกอินแอปทั้งหมดผ่านจุดเดียว ครอบคลุมการตั้งค่า env การใช้ akadmin และการทำ forward auth ผ่าน Traefik

การล็อกอินครั้งเดียวสำหรับทุกแอปที่คุณโฮสต์

Authentik คือเซิร์ฟเวอร์ SSO (single sign-on) แบบ self-hosted ซึ่งช่วยให้ผู้ใช้ของคุณล็อกอินเพียงครั้งเดียว แล้วทุกแอปที่อยู่เบื้องหลังจะยอมรับ session นั้นแทนการถามรหัสผ่านแยกต่างหาก การติดตั้งทำได้โดยใช้ไฟล์ Docker Compose อย่างเป็นทางการและ secret ที่สร้างขึ้นมา 2 รายการ ส่วนที่ต้องใช้การวางแผนอย่างจริงจังคือขั้นตอนหลังจากนั้น ได้แก่ การชี้ reverse proxy ไปยัง Authentik และการนำแอปที่มีอยู่เดิมมาไว้เบื้องหลัง forward auth

Authentik ประกอบด้วย 3 บริการในไฟล์ Compose ดังกล่าว ได้แก่ ฐานข้อมูล PostgreSQL, กระบวนการ server และกระบวนการ worker คอนเทนเนอร์ของเซิร์ฟเวอร์ยังรัน embedded outpost ซึ่งเป็นส่วนประกอบที่คอยตอบคำถามว่า "คำขอนี้ผ่านการล็อกอินแล้วหรือไม่" สำหรับทุกแอปที่ได้รับการป้องกัน เวอร์ชัน 2026.5 คือรุ่นที่ปล่อยออกมาล่าสุด ณ เดือนกรกฎาคม 2026 โดยโครงการแนะนำให้ใช้โฮสต์ที่มี CPU อย่างน้อย 2 คอร์ และ RAM 2 GB ให้ถือว่านี่คือสเปกขั้นต่ำ เนื่องจากทั้ง PostgreSQL และ worker จะใช้หน่วยความจำเพิ่มขึ้นหลังจากเครื่องเปิดใช้งานไปแล้วหนึ่งวัน

สิ่งที่ต้องเตรียมก่อนเริ่มต้น

คุณต้องมี Docker Engine พร้อมปลั๊กอิน Compose v2 ซึ่งสามารถตรวจสอบได้ด้วยคำสั่ง docker compose version หากคำสั่งดังกล่าวแสดงข้อผิดพลาดแทนที่จะเป็นเวอร์ชัน ให้ติดตั้งปลั๊กอินให้เรียบร้อยก่อนดำเนินการต่อ โดยสามารถดูพื้นฐานได้ที่ การรันแอปพลิเคชันด้วย Docker Compose บน VPS นอกจากนี้ คุณต้องมี DNS A record ที่ชี้มายังเซิร์ฟเวอร์ของคุณ ซึ่งในตัวอย่างด้านล่างจะใช้ auth.example.com เนื่องจาก Authentik จะสร้าง URL สำหรับเปลี่ยนเส้นทาง (redirect URL) โดยอ้างอิงจาก hostname ที่เบราว์เซอร์ใช้งาน

ให้รัน stack ในฐานะผู้ใช้ทั่วไปที่อยู่ในกลุ่ม docker แทนการรันด้วยสิทธิ์ root การเป็นสมาชิกของกลุ่มดังกล่าวมีสิทธิ์เทียบเท่ากับ root บนโฮสต์ ดังนั้นควรให้สิทธิ์นี้แก่บัญชีสำหรับ deploy เพียงบัญชีเดียวเท่านั้น โดยสามารถดูแนวทางได้ที่ บัญชีผู้ใช้แบบจำกัดสิทธิ์บน 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 ควรแสดงรายการคอนเทนเนอร์ 3 รายการ โดยที่ postgresql จะรายงานสถานะ healthy และ server กับ worker จะรายงานสถานะ running การเริ่มทำงานครั้งแรกจะดำเนินการย้ายข้อมูลฐานข้อมูล (database migrations) ดังนั้นโปรดรอประมาณหนึ่งนาทีก่อนที่อินเทอร์เฟซเว็บจะตอบสนอง

ค่าที่สร้างขึ้นทั้งสองค่ามีความสำคัญด้วยเหตุผลที่แตกต่างกัน PG_PASS คือรหัสผ่านของ PostgreSQL ซึ่งมีการจำกัดความยาวสูงสุดไว้ที่ 99 ตัวอักษร AUTHENTIK_SECRET_KEY ใช้สำหรับลงนามในเซสชันและโทเค็น ดังนั้นการเปลี่ยนค่านี้ในภายหลังจะทำให้ผู้ใช้ทุกคนออกจากระบบและทำให้โทเค็น 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) ไม่ใช่ปัญหาเรื่องการตั้งค่า (config)

ค่า environment ที่สำคัญ

การตั้งค่าส่วนที่เหลือทั้งหมดจะอยู่ในไฟล์ .env เดียวกัน Authentik จะแปลงเครื่องหมายขีดเส้นใต้คู่ (double underscore) ให้เป็นคีย์การตั้งค่าแบบซ้อน (nested configuration key) ดังนั้น AUTHENTIK_EMAIL__HOST จึงเป็นการกำหนดค่า email.host หากใช้ขีดเส้นใต้เพียงขีดเดียว ระบบจะเพิกเฉยโดยไม่มีการแจ้งเตือน ซึ่งเป็นสาเหตุที่พบบ่อยที่สุดที่ทำให้การตั้งค่าดูเหมือนไม่มีผลใดๆ

AUTHENTIK_BOOTSTRAP_PASSWORD ใช้กำหนดรหัสผ่านสำหรับผู้ใช้ akadmin ที่มีมาให้ในตัวเมื่อเริ่มระบบครั้งแรก เพื่อให้คุณไม่ต้องกรอกรหัสผ่านลงในเว็บฟอร์มสาธารณะ AUTHENTIK_BOOTSTRAP_EMAIL และ AUTHENTIK_BOOTSTRAP_TOKEN ใช้กำหนดที่อยู่อีเมลและ API token สำหรับผู้ใช้ดังกล่าวในลักษณะเดียวกัน
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 จะพยายามใช้ localhost ที่พอร์ต 25 ส่งผลให้อีเมลรีเซ็ตรหัสผ่านล้มเหลวและแสดงเป็นข้อผิดพลาดในการเชื่อมต่อใน log ของ worker
AUTHENTIK_LOG_LEVEL=debug ใช้เปิดระดับรายละเอียด log ที่คุณต้องการในขณะที่ flow การล็อกอินมีปัญหา อย่าลืมเปลี่ยนกลับเป็น info หลังจากแก้ไขเสร็จสิ้น
AUTHENTIK_ERROR_REPORTING__ENABLED มีค่าเริ่มต้นเป็น false ให้ตั้งค่าเป็น true ก็ต่อเมื่อคุณยินยอมที่จะส่งรายงานข้อผิดพลาดไปยังผู้พัฒนาต้นทางเท่านั้น

เนื่องจากข้อมูลเหล่านี้เป็นความลับที่อยู่ในไฟล์ข้อความธรรมดา คุณควรจัดการไดเรกทอรีดังกล่าวเช่นเดียวกับที่เก็บข้อมูลรับรอง (credential store) อื่นๆ การใช้โปรแกรมจัดการรหัสผ่าน เช่น อินสแตนซ์ Vaultwarden ที่คุณโฮสต์เอง เป็นที่จัดเก็บสำรองที่ปลอดภัยกว่าการจดบันทึกไว้ในแล็ปท็อปของคุณ

การเข้าสู่ระบบครั้งแรกและบัญชีผู้ดูแลระบบ

เปิด http://SERVER_IP:9000 ในเว็บเบราว์เซอร์ Authentik จะแสดงขั้นตอนการตั้งค่าเริ่มต้นและขอให้คุณกำหนดรหัสผ่านสำหรับผู้ใช้เริ่มต้น akadmin หากคุณได้ตั้งค่า AUTHENTIK_BOOTSTRAP_PASSWORD ไว้แล้ว ขั้นตอนนี้จะเสร็จสิ้นและคุณจะเข้าสู่หน้าล็อกอินโดยตรง

สร้างผู้ดูแลระบบทั่วไปสำหรับใช้งานที่ Directory แล้วเลือก Users จากนั้นเพิ่มผู้ใช้นั้นลงในกลุ่ม authentik Admins และลงชื่อเข้าใช้ด้วยบัญชีดังกล่าว เก็บ akadmin ไว้เป็นบัญชีฉุกเฉิน โดยตั้งรหัสผ่านที่ยาวและจัดเก็บแบบออฟไลน์ การทำงานประจำวันภายใต้บัญชีในตัวที่ใช้ร่วมกันจะทำให้ audit log ใช้ตรวจสอบไม่ได้ เพราะทุกเหตุการณ์ระบุเพียง akadmin และไม่ระบุว่าใครเป็นผู้ดำเนินการ เหตุผลนี้ใช้กับระบบปลายทางหลัง Authentik ด้วยเช่นกัน ตัวอย่างเช่น harness ของ OneCLI ที่ self-hosted และกำหนด agent ของตนเองให้แต่ละคน จะสร้างประวัติที่อ่านและตรวจสอบได้ก็ต่อเมื่อ identity ที่ส่งมาถึงระบบนั้นเป็นของบุคคลคนเดียว ไม่ใช่ login ที่ทั้งทีมใช้ร่วมกัน

การวาง Authentik ไว้หลัง reverse proxy

การเปิดพอร์ต 9000 สู่สาธารณะสามารถทำได้ แต่คุณควรใช้ TLS (transport layer security) และชื่อโฮสต์จริง หากคุณใช้งานการตั้งค่าจาก Traefik ในฐานะ reverse proxy สำหรับแอป Compose หลายตัว ให้เพิ่ม Authentik เข้าไปในเครือข่ายภายนอก proxy เดียวกันโดยใช้ไฟล์ override สร้างไฟล์ docker-compose.override.yml ไว้ข้างๆ compose.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 หากได้รับ 404 page not found จาก Traefik หมายความว่าคอนเทนเนอร์ไม่ได้อยู่ในเครือข่าย proxy และ Traefik ไม่สามารถส่งต่อคำขอไปยังคอนเทนเนอร์ที่เข้าถึงไม่ได้

เมื่อชื่อโฮสต์ทำงานได้แล้ว ให้เปลี่ยนการผูกพอร์ตที่เปิดใช้งานไปที่ 127.0.0.1 ในไฟล์ override เพื่อให้การเข้าถึงทำได้ผ่านทาง proxy เท่านั้น

การปกป้องแอปพลิเคชันด้วย forward auth

Authentik proxy provider มี 3 โหมด และการเลือกผิดอาจทำให้เสียเวลา 1 ชั่วโมง โหมด Proxy หมายถึง outpost เป็นผู้ส่งต่อ traffic ไปยัง upstream app เอง โหมด Forward auth (single application) หมายถึง reverse proxy ของคุณยังคงส่งต่อ traffic และเพียงสอบถาม Authentik ว่า request นั้น sign in แล้วหรือไม่ โหมด Forward auth (domain level) ใช้ป้องกันทุกแอปภายใต้ parent domain เดียวด้วย provider เดียว แต่ต้องแลกกับการกำหนด authorization rules แยกตามแอปได้จำกัดกว่า หากมี Traefik อยู่ด้านหน้า ให้ใช้ forward auth (single application) หากต้องการแอปตัวอย่างสำหรับฝึกตั้งค่า workspace AFFiNE แบบ self-hosted เป็นตัวเลือกแรกที่เหมาะสม เพราะเป็นเครื่องมือภายในที่ควรเข้าถึงได้จากอุปกรณ์ของคุณเองและไม่ควรเปิดให้ที่อื่นเข้าถึง เครื่องมือสำหรับทีมยิ่งแสดงประโยชน์ของวิธีนี้ได้ชัดเจนขึ้น: นำ support desk Chatwoot แบบ self-hosted ไว้หลัง provider เดียวกัน แล้วทุกคนที่ตอบ inbox จะ sign in เพียงครั้งเดียวต่อวัน แทนการแชร์ password เพิ่มอีกหนึ่งรายการ

ในหน้าเว็บอินเทอร์เฟซ ให้ไปที่ Applications แล้วเลือก Providers จากนั้นสร้าง Proxy Provider เลือกโหมด forward auth single application และตั้งค่า external host เป็น https://app.example.com จากนั้นสร้าง Application ที่ชี้ไปยัง provider ดังกล่าว ต่อมาให้ไปที่ Outposts แก้ไข authentik Embedded Outpost และย้ายแอปพลิเคชันใหม่เข้าไปในรายการ selected applications ตัว outpost จะตอบสนองเฉพาะแอปพลิเคชันที่ได้รับมอบหมายเท่านั้น ดังนั้นการข้ามขั้นตอนสุดท้ายนี้จึงเป็นสาเหตุที่ทำให้ provider ที่ตั้งค่าไว้อย่างถูกต้องยังคงไม่แสดงผลใดๆ

กำหนด middleware ไว้ที่เดียวบนคอนเทนเนอร์ของ Authentik และอ้างอิงจากทุกแอปที่ต้องการปกป้อง:

      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 คือรายการ header ที่ Traefik จะคัดลอกจากคำตอบของ Authentik ไปยังคำขอที่ส่งไปยังแอปพลิเคชันต้นทาง หากละเว้นส่วนนี้ แอปจะยังคงถูกปกป้องอยู่ แต่จะไม่ทราบว่าผู้ใช้คือใคร ส่งผลให้ระบบใดก็ตามที่อ่านค่า X-authentik-username เพื่อลงชื่อเข้าใช้อัตโนมัติจะยังคงอยู่ในสถานะไม่ได้ลงชื่อเข้าใช้

ตัวแอปพลิเคชันที่ถูกปกป้องจำเป็นต้องมี router สองตัว ไม่ใช่ตัวเดียว:

    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 จะส่งเบราว์เซอร์กลับไปยัง path ภายใต้ /outpost.goauthentik.io/ บน hostname ของ แอปพลิเคชัน ไม่ใช่บน auth.example.com หากไม่มี router ที่ส่ง path prefix นั้นไปยังบริการของ Authentik คำขอจะไปตกที่แอปพลิเคชันของคุณซึ่งจะตอบกลับเป็น 404 และการลงชื่อเข้าใช้จะไม่เสร็จสมบูรณ์ ค่า priority ที่สูงกว่าคือสิ่งที่ทำให้กฎของ path เฉพาะเจาะจงมีลำดับความสำคัญเหนือกว่ากฎ Host() ทั่วไปบนโดเมนเดียวกัน

ทดสอบในหน้าต่างเบราว์เซอร์แบบส่วนตัว คุณควรถูกส่งไปยัง auth.example.com เพื่อลงชื่อเข้าใช้ และกลับมายังแอปพลิเคชันได้สำเร็จ docker compose logs -f server ในฝั่งของ Authentik จะแสดงเหตุการณ์การตรวจสอบสิทธิ์ในทุกความพยายาม ซึ่งจะช่วยให้คุณทราบว่าคำขอส่งไปถึง Authentik หรือไม่

ความล้มเหลวที่คุณจะพบจริง

เกิดวงจรการ redirect ไม่สิ้นสุดระหว่างแอปพลิเคชันกับหน้าเข้าสู่ระบบ โฮสต์ภายนอกที่ตั้งค่าไว้ในผู้ให้บริการไม่ตรงกับที่เบราว์เซอร์ใช้งาน ซึ่งมักเกิดจาก http:// ในผู้ให้บริการไม่ตรงกับ https:// ในแถบที่อยู่ของเบราว์เซอร์ คุกกี้เซสชันจึงถูกตั้งค่าสำหรับ origin ที่ต่างออกไป ทำให้ทุกครั้งที่วนกลับมา ระบบมองว่าเป็นคำขอใหม่ที่ไม่ระบุตัวตน ให้แก้ไขโฮสต์ภายนอกและล้างคุกกี้สำหรับทั้งสองโดเมนก่อนทดสอบใหม่

เกิดข้อผิดพลาด 404 ที่ /outpost.goauthentik.io/start ตัว outpost router หายไป หรือมีลำดับความสำคัญต่ำกว่า catch-all router สำหรับโฮสต์นั้น

แอปพลิเคชันโหลดขึ้นมาโดยไม่ถามหาการเข้าสู่ระบบ ป้ายกำกับ middlewares ระบุถึง middleware ที่ไม่มีอยู่จริง Traefik จะไม่แจ้งเตือนเกี่ยวกับเรื่องนี้ ดังนั้นการพิมพ์ผิดใน authentik@docker จึงหมายความว่าไม่มี middleware ใดทำงาน ให้เปิด Traefik dashboard แล้วตรวจสอบว่า router แสดงรายการ middleware ดังกล่าวหรือไม่

เกิดข้อผิดพลาด 403 จาก Authentik หลังจากเข้าสู่ระบบสำเร็จ ผู้ใช้ผ่านการยืนยันตัวตนแล้วแต่ไม่ได้รับอนุญาต: แอปพลิเคชันมีการผูกนโยบาย (policy binding) หรือข้อกำหนดกลุ่มที่ผู้ใช้รายนี้ไม่ผ่านเกณฑ์ บันทึก Events ในหน้าผู้ดูแลระบบจะระบุนโยบายที่ปฏิเสธการเข้าถึงนั้นไว้

เมื่อ Keycloak เป็นตัวเลือกที่เหมาะสมกว่า

Keycloak เป็นโปรเจกต์ที่มีมาก่อนและได้รับการสนับสนุนจาก Red Hat จึงเป็นตัวเลือกที่แข็งแกร่งกว่าสำหรับงานด้านการจัดการตัวตนในระดับองค์กรแบบดั้งเดิม เช่น การทำ SAML federation ขนาดใหญ่, การทำ brokering เพื่อล็อกอินจาก Identity Provider ภายนอกหลายแห่งพร้อมกัน และการส่งออกหรือนำเข้า realm ซึ่งมีเส้นทางการย้ายระบบที่ชัดเจน การมีบริการสนับสนุนเชิงพาณิชย์รองรับเป็นสิ่งที่องค์กรบางแห่งให้ความสำคัญในเชิงเอกสาร อย่างไรก็ตาม ข้อแลกเปลี่ยนคือ Keycloak ไม่มี proxy ในตัว ดังนั้นการปกป้องแอปพลิเคชันที่ไม่รองรับ OIDC (OpenID Connect) จึงจำเป็นต้องรันซอฟต์แวร์อย่าง oauth2-proxy ควบคู่ไปด้วย ในขณะที่ Proxy Provider ที่มาพร้อมกับ Authentik นั้นเป็นส่วนประกอบที่รวมอยู่ในระบบแล้ว ซึ่งเป็นเหตุผลว่าทำไมผู้ที่ทำ self-host แอปพลิเคชันหลากหลายประเภทส่วนใหญ่จึงเลือกใช้ Authentik

การสำรองข้อมูลและการอัปเกรด

ปัจจัยสามประการที่ทำให้การกู้คืนข้อมูลเป็นไปได้ ได้แก่ ฐานข้อมูล PostgreSQL, ไดเรกทอรี ./data และ .env

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

ให้จัดเก็บไฟล์ dump ดังกล่าวและ .env ไว้ด้วยกัน ไฟล์ dump เพียงอย่างเดียวไม่เพียงพอต่อการกู้คืน เนื่องจาก secret key ที่ใช้ปกป้องข้อมูล session และ token นั้นอยู่ใน .env

การอัปเกรดคือการเปลี่ยน tag ของเวอร์ชัน ให้กำหนดค่า AUTHENTIK_TAG ใน .env เป็นเวอร์ชันที่คุณต้องการ จากนั้นรันคำสั่ง docker compose pull ตามด้วย docker compose up -d โปรดอ่านบันทึกประจำรุ่น (release notes) ก่อนดำเนินการ เนื่องจาก Authentik ใช้เวอร์ชันแบบอิงตามวันที่ และบางรุ่นอาจมีการย้ายข้อมูล (migration) ที่กำหนดให้คุณต้องอัปเกรดมาจากเวอร์ชันก่อนหน้าเท่านั้น ให้ทำการ dump ฐานข้อมูลก่อนการ pull เสมอ ไม่ใช่หลังจากนั้น

FAQ

Authentik เปิดให้ self-host ได้ฟรีหรือไม่?

รุ่น open source เปิดให้ใช้งานได้ฟรีและครอบคลุมฟีเจอร์ทั้งหมดที่กล่าวมาข้างต้น ได้แก่ proxy provider, forward auth, OIDC (OpenID Connect), SAML และ flows engine สำหรับรุ่น enterprise จะมีค่าใช้จ่ายเพิ่มเติมเพื่อแลกกับการสนับสนุนทางเทคนิคและฟีเจอร์สำหรับองค์กร แต่ฟีเจอร์ทั้งหมดในคู่มือนี้ไม่จำเป็นต้องใช้ใบอนุญาต (licence) ใดๆ

จำเป็นต้องใช้ Traefik เพื่อใช้งาน Authentik หรือไม่?

ไม่จำเป็น Forward auth สามารถใช้งานร่วมกับ nginx ผ่าน auth_request และ Caddy ผ่าน forward_auth ได้ รูปแบบการทำงานจะเหมือนกันในทุกกรณี คือ reverse proxy จะส่งคำถามไปยัง Authentik สำหรับทุกคำขอ และ path prefix /outpost.goauthentik.io/ บน hostname ที่ต้องการป้องกันจะต้องถูกกำหนดให้ส่งต่อไปยัง Authentik แทนที่จะส่งไปยังแอปพลิเคชันโดยตรง

ทำไมแอปพลิเคชันที่ป้องกันไว้ถึงวนลูปหน้าล็อกอินกับหน้าแจ้งเตือนข้อผิดพลาดไม่หยุด?

สาเหตุเกิดจาก external host ที่ตั้งค่าไว้ใน proxy provider ไม่ตรงกับ URL ที่เบราว์เซอร์ใช้งานอยู่ ซึ่งมักเกิดจากการใช้ http เทียบกับ https ทำให้ session cookie ถูกออกให้สำหรับ origin หนึ่งแต่ถูกอ่านในอีก origin หนึ่ง Authentik จึงมองเห็นคำขอเป็นแบบ anonymous ทุกครั้ง ให้แก้ไขค่า external host ให้ถูกต้อง จากนั้นล้าง cookie ของทั้งสอง hostname ก่อนเริ่มทดสอบใหม่อีกครั้ง

Authentik ต้องการ RAM เท่าไหร่?

ข้อกำหนดขั้นต่ำอย่างเป็นทางการ ณ เดือนกรกฎาคม 2026 คือ CPU 2 คอร์ และ RAM 2 GB ซึ่งครอบคลุมการทำงานของ PostgreSQL, ตัวเซิร์ฟเวอร์ และ worker รวมกัน หากรันบนเครื่องที่มี RAM 2 GB ตัว worker จะเป็น process แรกที่ kernel สั่ง kill เมื่อหน่วยความจำไม่เพียงพอ ส่งผลให้งานเบื้องหลังและระบบส่งอีเมลหยุดทำงานในขณะที่หน้าล็อกอินยังคงใช้งานได้ปกติ แนะนำให้จัดสรร RAM 4 GB หากเซิร์ฟเวอร์เดียวกันนั้นต้องรันแอปพลิเคชันที่คุณต้องการป้องกันด้วย

#authentik #sso #authentication #self-hosting #docker-compose #traefik