SSD Nodes Learn Hosting plans →
คู่มือ Matt Connorโดย Matt Connor

วิธีติดตั้ง Authentik ด้วย Docker Compose สำหรับระบบ SSO

เรียนรู้วิธีติดตั้ง Authentik บน Docker Compose เพื่อทำระบบ SSO สำหรับแอปพลิเคชันของคุณ ครอบคลุมการตั้งค่า env การใช้ akadmin bootstrap และการทำ forward auth ผ่าน Traefik อย่างละเอียด

การลงชื่อเข้าใช้เพียงครั้งเดียวสำหรับทุกแอปที่คุณโฮสต์

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

Authentik ประกอบด้วยบริการ 3 รายการในไฟล์ Compose ดังกล่าว ได้แก่ ฐานข้อมูล PostgreSQL, กระบวนการ server และกระบวนการ worker คอนเทนเนอร์ของเซิร์ฟเวอร์ยังรัน embedded outpost ซึ่งเป็นคอมโพเนนต์ที่ทำหน้าที่ตอบคำถามว่า "คำขอนี้มีการลงชื่อเข้าใช้แล้วหรือไม่" สำหรับทุกแอปที่ได้รับการป้องกัน เวอร์ชัน 2026.8.3 คือรุ่นล่าสุด ณ เดือนตุลาคม 2026 โดยถูกเผยแพร่เมื่อวันที่ 17 กันยายน 2026 ในฐานะแพตช์ล่าสุดของซีรีส์ 2026.8 ซึ่งเริ่มต้นด้วย 2026.8.0 เมื่อวันที่ 18 สิงหาคม และไฟล์ Compose อย่างเป็นทางการได้ใช้เวอร์ชันนี้เป็นแท็กอิมเมจเริ่มต้นแล้ว โครงการนี้กำหนดให้โฮสต์ต้องมี 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 โดยอ้างอิงจาก 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 token ทุกตัวที่คุณเคยออกให้กลายเป็นโมฆะ ให้คงสิทธิ์ของ .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 แล้วหยุดทำงาน ข้อความดังกล่าวเป็นปัญหาเรื่องพาธ ไม่ใช่ปัญหาเรื่องการตั้งค่า

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

การตั้งค่าส่วนที่เหลือทั้งหมดจะอยู่ในไฟล์ .env เดียวกัน Authentik จะแปลงเครื่องหมายขีดล่างคู่ (double underscore) ให้เป็นคีย์การตั้งค่าแบบซ้อนกัน ดังนั้น 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 ใช้เปิดการแสดงรายละเอียดที่คุณต้องการในขณะที่ขั้นตอนการล็อกอินทำงานผิดปกติ ควรเปลี่ยนกลับเป็น info หลังจากแก้ไขเสร็จสิ้น
  • AUTHENTIK_ERROR_REPORTING__ENABLED มีค่าเริ่มต้นเป็น false ให้ตั้งค่าเป็น true ก็ต่อเมื่อคุณยินยอมที่จะส่งรายงานข้อผิดพลาดไปยังผู้พัฒนาต้นทางเท่านั้น

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

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

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

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

การใช้งาน 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

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

ในหน้าเว็บอินเทอร์เฟซ ให้เปิด Applications แล้วไปที่ Providers จากนั้นสร้าง Proxy Provider เลือกโหมด forward auth single application และตั้งค่า external host เป็น https://app.example.com สร้าง Application ที่ชี้ไปยัง provider นั้น จากนั้นเปิด Outposts แก้ไข authentik Embedded Outpost และย้ายแอปพลิเคชันใหม่เข้าไปในรายการ selected applications ของ outpost นั้น ตัว 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-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 คือรายการ header ที่ Traefik จะคัดลอกจากคำตอบของ Authentik ไปยังคำขอที่ส่งไปยังแอปพลิเคชันต้นทาง หากละเว้นส่วนนี้ แอปพลิเคชันจะยังคงถูกปกป้องอยู่ แต่จะไม่ทราบว่าผู้ใช้คือใคร ดังนั้นแอปพลิเคชันใดก็ตามที่อ่านค่า X-authentik-username เพื่อลงชื่อเข้าใช้อัตโนมัติจะยังคงอยู่ในสถานะไม่ได้ลงชื่อเข้าใช้ ช่องว่างนี้จะเห็นได้ชัดเจนที่สุดเมื่ออยู่หน้าแอปพลิเคชันที่มีระบบลงชื่อเข้าใช้ของตนเอง เช่น a self-hosted openGym workout tracker และระบบ passkey login ของมัน ซึ่ง header เหล่านี้คือสิ่งที่ตัดสินว่าคุณจะต้องกรอกข้อมูลเพียงครั้งเดียวหรือสองครั้งสำหรับหน้าเดิม

ตัวแอปพลิเคชันที่ถูกปกป้องจำเป็นต้องมี 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:// ในแถบที่อยู่ของเบราว์เซอร์ ทำให้ session cookie ถูกตั้งค่าสำหรับ 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 จึงเป็นตัวเลือกที่แข็งแกร่งกว่าสำหรับงานด้าน Identity ระดับองค์กรแบบดั้งเดิม เช่น การทำ 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

ให้จัดเก็บไฟล์ดัมพ์นั้นและ .env ไว้ด้วยกัน ไฟล์ดัมพ์เพียงอย่างเดียวไม่เพียงพอ เนื่องจากคีย์ลับที่ใช้ปกป้องข้อมูลเซสชันและโทเค็นนั้นอยู่ใน .env

การอัปเกรดคือการเปลี่ยนแท็ก (tag) ให้ตั้งค่า AUTHENTIK_TAG ใน .env เป็นรุ่นที่คุณต้องการ จากนั้นรัน docker compose pull ตามด้วย docker compose up -d หากคุณไม่เคยตั้งค่า AUTHENTIK_TAG เวอร์ชันจะถูกกำหนดจากค่าเริ่มต้นที่เขียนไว้ใน compose.yml โดยตรง ดังนั้นการดาวน์โหลดไฟล์เวอร์ชันใหม่มาแทนที่จึงถือเป็นการอัปเกรด ซึ่งเป็นวิธีที่เอกสารการอัปเกรดอย่างเป็นทางการระบุไว้ โปรดอ่านบันทึกประจำรุ่น (release notes) ก่อนเสมอ Authentik ใช้เวอร์ชันแบบอิงตามวันที่ และ ณ เดือนตุลาคม 2026 เอกสารระบุว่าการอัปเกรดต้องทำตามลำดับรุ่นหลัก (major release): ให้ย้ายไปยังแพตช์ล่าสุดของซีรีส์ที่คุณใช้งานอยู่ จากนั้นจึงขยับไปยังซีรีส์ถัดไปทีละลำดับโดยห้ามข้ามรุ่น Authentik ไม่รองรับการดาวน์เกรด ดังนั้นให้ทำไฟล์ดัมพ์ฐานข้อมูลก่อนการสั่ง 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 ให้ถูกต้อง จากนั้นล้างคุกกี้ของทั้งสอง hostname ก่อนทำการทดสอบใหม่อีกครั้ง

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

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