Đến nội dung chính
Phạm Nam

Tìm kiếm

Nhập từ khoá để tìm trong các bài viết.

Quay lại

Tự host Postiz: lên lịch đăng bài đa nền tảng bằng Docker

Tự host Postiz bằng Docker Compose để lên lịch đăng bài Instagram, TikTok, Facebook, Threads, X từ một lịch duy nhất: cài đặt, HTTPS, kết nối kênh và vận hành.

10 phút đọc—

Quản lý một tài khoản mạng xã hội đã tốn thời gian. Quản lý năm, mười tài khoản trên nhiều nền tảng thì lịch đăng bài nhanh chóng biến thành một bảng tính rời rạc: bài nào đăng ở đâu, đăng lúc nào, ai duyệt, bài nào lỗi. SaaS như Buffer hay Hootsuite giải quyết đúng bài toán này, nhưng phí thuê bao cộng dồn theo số tài khoản và số thành viên, còn dữ liệu thì nằm trên hệ thống của nhà cung cấp.

Postiz là một lựa chọn khác: nền tảng quản lý mạng xã hội mã nguồn mở (AGPL-3.0), có bản tự host chạy bằng Docker Compose. Bài này hướng dẫn tự host Postiz, giải thích kiến trúc đủ sâu để bạn vận hành được, và nói thẳng những điểm bản tự host không giải quyết thay bạn: phê duyệt ứng dụng của từng nền tảng, vòng đời token OAuth, và trách nhiệm backup.

Lưu ý trung thực: các lệnh cài đặt trong bài được đối chiếu với tài liệu và repo chính thức của dự án, nhưng mình chưa chạy thử bộ cài này trên VPS thật.

Vì sao tự host Postiz thay vì trả phí SaaS

Một team nhỏ làm nội dung thường phải đăng cùng một chiến dịch lên Facebook, Instagram, TikTok, Threads, X, LinkedIn, YouTube. Làm thủ công từng nền tảng nghĩa là đăng nhập nhiều lần, định dạng lại nội dung cho từng nơi, và không có một nơi duy nhất để nhìn toàn bộ lịch tuần. Postiz gom việc đó về một lịch: soạn một lần, xếp lịch cho từng kênh, theo dõi trạng thái và số liệu ở cùng một chỗ.

Giá SaaS lên lịch thường tính theo số kênh kết nối và số người dùng. Team càng lớn, hóa đơn càng phình, dù nhu cầu thực tế chỉ là một lịch đăng chung và vài người cùng soạn bài. Bản tự host đảo ngược phép tính đó: không giới hạn gói, không tính theo ghế ngồi, đổi lại bạn tự gánh chi phí VPS và công vận hành. Theo mình, phép đổi này chỉ có lợi khi bạn đã có sẵn hạ tầng Docker và người trông hệ thống. Nếu chỉ đăng vài bài mỗi tuần, tiền công bảo trì một stack nhiều service sẽ đắt hơn tiền thuê bao.

Bài này viết cho sysadmin, DevOps/SRE, người chơi homelab và team nhỏ tại Việt Nam đang quản lý nhiều tài khoản mạng xã hội. Bạn cần biết Docker Compose ở mức cơ bản và đã từng cấu hình reverse proxy. Nếu chưa quen Docker, hãy bắt đầu từ bài về Dockge hoặc Coolify trước.

Postiz là gì

Postiz (repo gitroomhq/postiz-app) là nền tảng quản lý mạng xã hội: lên lịch, tự động hóa và phân tích nội dung, có hai bản là Postiz Cloud và bản mã nguồn mở tự host. Bản tự host không bị giới hạn gói như bản Cloud, theo tài liệu chính thức của dự án. Tại thời điểm đối chiếu (29/10/2026), repo có khoảng 40.000 sao, bản phát hành mới nhất là v2.25.3 (24/10/2026), commit gần nhất ngày 28/10/2026 — dự án đang được duy trì tích cực, nhưng con số sao sẽ thay đổi nên bạn tự kiểm tra lại.

Các kênh hỗ trợ

Danh sách kênh theo tài liệu của dự án gồm Instagram, YouTube, Dribbble, LinkedIn, Reddit, TikTok, Facebook, Pinterest, Threads, X, Slack, Discord, Mastodon và Bluesky. Danh sách dài không đồng nghĩa mọi kênh đều dễ kết nối như nhau: phần lớn nền tảng yêu cầu bạn tự tạo developer app và cấu hình API key, chỉ có 8 nền tảng không cần cấu hình thêm. Đây chính là phần tốn thời gian nhất của cả dự án.

Postiz AI agent scheduling

Postiz nhấn mạnh tích hợp AI agent: lên lịch qua ChatGPT, Claude, Claude Code, Codex, Cursor, OpenClaw, MCP server, cùng tự động hóa qua N8N, Make và Zapier. Nói thẳng: đây là thông tin do phía dự án công bố, phần này mình chưa chạy thử nên không đánh giá được độ ổn định thực tế. Cách dùng an toàn là để AI soạn và xếp lịch nháp, con người duyệt trước khi đăng.

Kiến trúc Postiz: không chỉ là một web app lên lịch

Postiz không phải một container đơn lẻ. Stack gồm Next.js ở frontend, NestJS ở backend, Prisma làm ORM trên PostgreSQL (14 trở lên) làm nơi lưu dữ liệu chính, Redis (6 trở lên) cho hàng đợi và cache, Temporal làm engine chạy workflow theo lịch, và Resend cho email thông báo. Media lưu trên local filesystem hoặc Cloudflare R2.

Luồng chạy như sau: người dùng soạn bài và đặt lịch trong giao diện, NestJS lưu bài đăng và job vào PostgreSQL, Temporal giữ workflow chờ đến đúng giờ hẹn kèm cơ chế retry, đến giờ thì worker gọi API từng nền tảng bằng OAuth/API credential đã lưu, sau đó trạng thái và số liệu được ghi trở lại. Nhờ đó, khi một bài không đăng được, bạn biết cần kiểm tra ở đâu: credential của kênh đó, log của worker, hay trạng thái workflow trong Temporal.

Từ phiên bản 2.12.0, Temporal là thành phần bắt buộc và đã được đóng gói sẵn trong file Compose chính thức. Khác với cron đơn giản, một bài đăng bị lỡ hoặc lỗi không biến mất như một cron tick trượt, mà tồn tại dưới dạng workflow bền vững có thể retry và kiểm tra lại được. Cái giá phải trả là nâng cấp phải đi theo bộ: PostgreSQL, Temporal và app phải nâng cấp như một tập đã kiểm chứng tương thích. Nâng cấp lẻ một image có thể khiến hàng đợi dừng trong khi giao diện web vẫn hiển thị bình thường — một lỗi im lặng rất khó phát hiện nếu không giám sát Temporal.

Giới hạn cần nói thẳng: Postiz phụ thuộc hoàn toàn vào API và chính sách OAuth của từng nền tảng. Nền tảng đổi chính sách, thu hồi token, hoặc yêu cầu xét duyệt app thì kênh đó dừng đăng cho đến khi bạn xử lý xong, và đó không phải lỗi của Postiz. Mình cũng không có benchmark hiệu năng nào đã kiểm chứng, nên bài này chỉ dùng con số tài nguyên chính thức.

Hướng dẫn tự host Postiz bằng Docker Compose

Điều kiện tiên quyết

Bạn cần một VPS đã cài Docker và Docker Compose, có tên miền trỏ về VPS nếu muốn chạy production, và repo cài đặt chính thức gitroomhq/postiz-docker-compose.

Yêu cầu tài nguyên và phiên bản

Tài liệu chính thức đưa ra hai mức cho team nhỏ tối đa khoảng 20 người dùng: mức sàn 2 vCPU / 2 GB RAM / 20 GB disk, và mức khuyến nghị 4 vCPU / 8 GB RAM / 50 GB kèm volume upload bền vững. Phiên bản đối chiếu trong bài là v2.25.3 (24/10/2026). Mức sàn là mức chạy nhẹ cho một người dùng đơn lẻ, gần như không có dư địa — team nhiều người và upload nhiều media nên tính theo mức khuyến nghị ngay từ đầu.

Cài đặt

Các lệnh dưới đây lấy nguyên văn từ README của repo Compose chính thức:

git clone https://github.com/gitroomhq/postiz-docker-compose
cd postiz-docker-compose
docker compose up

Sau đó mở https://localhost:4007 theo hướng dẫn của repo. Lưu ý: đây là điểm vào cho máy local, không phải cách chạy production.

Truy cập lần đầu và tài khoản owner: khoá ngay trước khi mở public

Đây là bước quan trọng nhất về mặt bảo mật của toàn bộ bài. Tài khoản đầu tiên đăng ký trên bản tự host sẽ trở thành chủ organisation, và không có bước tạo admin riêng. Nếu bạn mở instance ra internet trước khi tự đăng ký tài khoản đầu tiên, bất kỳ ai truy cập được cũng có thể chiếm quyền owner. Thứ tự đúng: khởi động stack, đăng ký owner ngay, sau đó mới đưa instance ra sau reverse proxy và HTTPS.

Kết nối kênh

Có tài khoản owner rồi, bạn kết nối từng kênh trong giao diện. Với các nền tảng yêu cầu developer app, bạn cần tự tạo app trên cổng developer của nền tảng đó, hoàn tất OAuth và lưu credential. Thời gian chờ xét duyệt app của Meta, TikTok hay X là thứ quyết định bạn bao lâu mới đăng được bài đầu tiên, chứ không phải lệnh docker compose up chạy trong vài phút. Theo mình, hãy bắt đầu từ những nền tảng không cần cấu hình thêm, song song làm hồ sơ developer app cho các kênh lớn.

Chạy production đúng cách: HTTPS qua reverse proxy

Postiz đặt secure cookie, nên tài liệu yêu cầu chạy production sau reverse proxy với HTTPS. Chạy qua HTTP trần sẽ khiến phiên đăng nhập lỗi và phơi credential. Cách làm chuẩn: đặt Postiz sau Nginx, Caddy hoặc Traefik với chứng chỉ TLS, chỉ mở cổng 443 ra ngoài, giữ các cổng nội bộ không public.

Kiểm chứng sau cài đặt

Sau khi docker compose up, kiểm tra:

docker compose ps
docker compose logs -f

Kết quả mong đợi: các container ở trạng thái chạy, không container nào restart liên tục, log không báo lỗi kết nối PostgreSQL, Redis hay Temporal. Sau đó đăng nhập bằng tài khoản owner, tạo một bài thử, đặt lịch sau vài phút, và kiểm tra bài có đăng lên kênh thử nghiệm hay không. Đừng kiểm tra bằng kênh chính thức ngay lần đầu.

Lỗi thường gặp và cách xử lý

  • Container không lên hoặc restart liên tục: đọc log của container lỗi trước, đừng khởi động lại cả stack. Thiếu RAM trên VPS nhỏ là nguyên nhân thường gặp.
  • Lỗi kết nối PostgreSQL, Redis hoặc Temporal, hoặc không đăng nhập được sau khi gắn domain: kiểm tra docker compose ps và log của service lỗi; với lỗi đăng nhập, kiểm tra HTTPS và reverse proxy trước tiên, vì secure cookie không hoạt động đúng khi thiếu HTTPS.
  • Bài đăng lỗi ở một kênh nhưng các kênh khác vẫn chạy: đó là vấn đề credential của kênh đó — token hết hạn hoặc app bị thu hồi quyền.
  • Hàng đợi dừng nhưng giao diện vẫn bình thường: nghi ngờ Temporal trước tiên, kiểm tra trạng thái workflow và log của worker.

Đánh giá kỹ thuật Postiz self-hosted

Ưu điểm

Mã nguồn mở AGPL-3.0, một lịch cho nhiều kênh, không giới hạn gói khi tự host, dữ liệu nằm trên VPS của bạn, và cộng đồng lớn với nhịp phát hành đều.

Nhược điểm

Bạn tự gánh toàn bộ vận hành: stack nhiều service, OAuth từng nền tảng, HTTPS và reverse proxy, backup và nâng cấp. Đó chính là phần việc bạn đã đổi lấy việc không trả phí thuê bao. Tính năng AI agent và automation hiện mới dừng ở mức thông tin do dự án công bố, chưa được mình kiểm chứng độc lập.

Bảo mật

Ba việc không được bỏ qua: đăng ký tài khoản owner trước khi mở public, bắt buộc HTTPS qua reverse proxy, và bảo vệ API key/token của từng kênh như credential thật. Phân quyền team cũng cần nghiêm túc: không phải ai soạn bài cũng nên có quyền sửa kết nối kênh hay xem credential.

Hiệu năng, mở rộng và vận hành dài hạn

Ngoài con số sàn và khuyến nghị chính thức, không có benchmark đáng tin để trích dẫn. Khi tăng người dùng và media, thứ phình lên trước là PostgreSQL và volume upload, sau đó là tải của Temporal worker — hãy giám sát ba service này ngay từ đầu.

Trước mỗi lần nâng cấp, chốt tag image đang chạy tốt (đừng trông cậy vào :latest), snapshot PostgreSQL, trạng thái Temporal, dữ liệu Redis và volume upload. Giữ lại file Compose và tag cũ để khôi phục trong một bước nếu bản mới lỗi.

So sánh Postiz với Buffer, Hootsuite và lựa chọn thay thế

Buffer và Hootsuite thắng ở chỗ không cần vận hành: đăng ký là dùng, kết nối kênh có sẵn quy trình hỗ trợ, có SLA của nhà cung cấp. Postiz thắng ở chi phí dài hạn cho team nhiều kênh, quyền kiểm soát dữ liệu, và không bị giới hạn gói. Theo mình, thay thế SaaS bằng Postiz chỉ hợp lý khi team bạn đã có người vận hành Docker và đăng bài đủ thường xuyên để công bảo trì xứng đáng.

Bản Cloud không có free tier theo tài liệu chính thức; tổ chức mới thường được mời dùng thử 7 ngày — thông tin từ tài liệu, mình chưa tự đăng ký để kiểm chứng. So sánh gọn: Cloud đổi tiền lấy việc không phải vận hành, tự host đổi công vận hành lấy không giới hạn gói và dữ liệu ở máy mình.

Use case thực tế

Team nhỏ làm nội dung: một lịch chung cho cả team, phân quyền soạn bài và phê duyệt, tránh đăng trùng hoặc sót.

Homelab và cá nhân quản lý nhiều tài khoản: gom tài khoản cá nhân, cộng đồng và dự án phụ về một nơi, tiết kiệm phí SaaS hàng tháng, dữ liệu nằm trên VPS của mình.

Workflow AI có người duyệt: AI agent soạn và xếp lịch nháp qua MCP hoặc API, con người duyệt trước khi đăng — tận dụng tốc độ của AI mà không giao quyền đăng công khai cho agent chưa kiểm chứng.

DevOps và IT admin: triển khai Postiz như một stack Compose trong hạ tầng sẵn có, ví dụ quản lý bằng Dockge hoặc triển khai qua Coolify. Nếu team bạn còn dùng AI gateway tự host, bài về New API nằm cùng mạch hạ tầng này.

Kết luận

Tự host Postiz hợp lý khi bạn đã có VPS và người vận hành Docker, quản lý đủ nhiều kênh để phí SaaS trở thành gánh nặng, và cần dữ liệu nội dung nằm trong tay mình. Không nên tự host khi nhu cầu chỉ là vài bài mỗi tuần, khi team ngại làm việc với developer app và OAuth, hoặc khi không ai nhận trách nhiệm backup.

Bước tiếp theo trong một buổi triển khai: chuẩn bị VPS đạt mức khuyến nghị, clone repo Compose chính thức, đăng ký owner ngay sau lần khởi động đầu tiên, gắn HTTPS qua reverse proxy trước khi mở public, kết nối kênh thử nghiệm và đăng bài test, rồi mới làm hồ sơ developer app cho các kênh lớn.

Tham khảo


Bài viết liên quan

Bình luận

Bình luận được duyệt trước khi hiển thị.

Đang tải bình luận…

Để lại bình luận