Từ Heroku sang Coolify/Dokploy: Migrate App Không Downtime

Từ Heroku sang Coolify hay Dokploy: lộ trình migrate app không downtime

Heroku từng là lựa chọn “deploy trong 5 phút”: push code → build → chạy. Nhưng khi app lớn dần, chi phí dyno, database, worker, add-on, bandwidth… bắt đầu phình. Nhiều team muốn chuyển sang VPS/self-host để giảm chi phí, kiểm soát hạ tầng, chạy Docker linh hoạt, nhưng vẫn sợ nhất một thứ: downtime.

Tin tốt: migrate từ Heroku sang Coolify hoặc Dokploy có thể gần như không downtime nếu đi theo lộ trình đúng: dựng môi trường song song, đồng bộ dữ liệu, kiểm thử production-like, chuyển DNS/cutover có kiểm soát, có rollback.

Bài này tập trung vào cách làm thực tế cho app web phổ biến: Node.js, Rails, Django, Laravel, Go… có DB, Redis, background worker, file upload, cron/job.

Coolify và Dokploy: nên chọn gì?

Cả hai đều là nền tảng self-host PaaS, chạy trên VPS, hỗ trợ Docker, Git deploy, env vars, database, reverse proxy, SSL.

Coolify phù hợp khi

– Muốn UI đầy đủ, nhiều template. – Cần quản lý app, DB, service, volume, domain, SSL trong một nơi. – Muốn trải nghiệm gần Heroku hơn. – Team nhỏ, cần deploy nhanh, ít thao tác thủ công.

Dokploy phù hợp khi

– Thích hướng Docker/Traefik rõ ràng. – Muốn setup gọn, nhẹ. – Quen Docker Compose. – Cần kiểm soát reverse proxy, network, service tường minh.

Điểm chung cần hiểu

Heroku giấu nhiều thứ: router, buildpack, dyno lifecycle, release phase, logs, env, add-on. Khi sang Coolify/Dokploy, bạn cần tự kiểm soát:

– Dockerfile/build image – process web/worker/scheduler – DB migration – persistent storage – backup – monitoring – SSL/domain – scaling

Không khó, nhưng cần checklist.

Nguyên tắc migrate không downtime

Không downtime nghĩa là người dùng không thấy lỗi, request không bị mất, dữ liệu không lệch. Muốn vậy, tránh “tắt Heroku rồi mới dựng server mới”.

Chiến lược đúng:

1. Dựng hạ tầng mới song song 2. Deploy app mới với cùng version code 3. Kết nối dữ liệu theo kế hoạch 4. Test bằng domain phụ 5. Đồng bộ DB/file 6. Chuyển traffic từng bước 7. Giữ Heroku làm rollback 8. Chỉ tắt Heroku khi ổn định

Mục tiêu: lúc cutover, app mới đã chạy sẵn, DB đã sẵn sàng, DNS đổi nhanh, rollback rõ.

Bước 1: Audit app trên Heroku

Trước khi migrate, liệt kê toàn bộ phụ thuộc.

Kiểm kê process

Chạy:

heroku ps

Ghi lại:

– web dyno – worker dyno – release phase – cron/scheduler – queue consumer – one-off task

Nếu app có Procfile, chuyển từng process sang Coolify/Dokploy.

Ví dụ:

web: npm start
worker: npm run worker
release: npm run migrate

Sang Docker/self-host, cần tách rõ:

– web service – worker service – migration command – scheduler/cron

Kiểm kê env vars

heroku config

Phân loại:

– app secret: SECRET_KEY, JWT_SECRET – DB URL: DATABASE_URL – Redis: REDIS_URL – storage: S3/R2/Spaces – mail: SMTP/API key – third-party keys – callback URL, webhook URL

Không copy mù. Env nào phụ thuộc domain cần đổi sau cutover.

Kiểm kê add-on

heroku addons

Các add-on thường gặp:

– Postgres – Redis – Papertrail/Logtail – SendGrid/Mailgun – Scheduler – Sentry – S3-like storage

Mỗi add-on cần phương án thay thế hoặc giữ nguyên nếu dùng external service.

Bước 2: Docker hóa app

Coolify/Dokploy chạy tốt nhất với Docker. Nếu app đã có Dockerfile → lợi thế lớn. Nếu chưa, tạo Dockerfile production.

Ví dụ Node.js:

FROM node:20-alpine

WORKDIR /app

COPY package*.json ./
RUN npm ci --omit=dev

COPY . .

RUN npm run build

ENV NODE_ENV=production
EXPOSE 3000

CMD ["npm", "start"]

Điểm cần kiểm tra:

– App listen 0.0.0.0, không chỉ localhost – Port dùng env PORT – Build không phụ thuộc file local – Không ghi file runtime vào container trừ khi có volume – Log ra stdout/stderr

Heroku tự inject PORT. Coolify/Dokploy cũng có thể map port, nhưng app nên đọc:

const port = process.env.PORT || 3000

Bước 3: Dựng VPS mới

Chọn VPS theo tải thực tế, không theo cảm tính.

Gợi ý cấu hình ban đầu

– App nhỏ: 2 vCPU, 4GB RAM – App vừa: 4 vCPU, 8GB RAM – DB cùng máy → cần thêm RAM/SSD – Production nghiêm túc → DB tách riêng

Cài:

– Ubuntu LTS – Docker – Coolify hoặc Dokploy – Firewall – SSH key-only – Backup volume

Bảo mật tối thiểu:

– Tắt password SSH – Mở port cần thiết: 80, 443, SSH – Cập nhật hệ thống – Không public DB nếu không cần – Backup tự động trước cutover

Bước 4: Deploy app lên Coolify/Dokploy bằng domain phụ

Trước khi động vào domain chính, dùng domain phụ:

staging-new.example.com

Hoặc:

new.example.com

Deploy cùng code version đang chạy trên Heroku. Set env vars tương đương. Trỏ domain phụ vào VPS, bật SSL.

Kiểm thử:

– health check – login/logout – signup – payment callback – upload file – gửi mail – queue job – cron job – admin dashboard – API mobile app – webhook từ bên thứ ba

Quan trọng: test app mới với dữ liệu giống production. Nếu chỉ test bằng DB rỗng → dễ bỏ sót lỗi migration.

Bước 5: Chiến lược migrate database

DB là phần nhạy nhất. Có 3 hướng phổ biến.

Cách 1: Dump/restore nhanh

Phù hợp app nhỏ, DB vài GB, chấp nhận maintenance window rất ngắn.

Postgres Heroku:

heroku pg:backups:capture
heroku pg:backups:download

Restore vào DB mới:

pg_restore --verbose --clean --no-acl --no-owner -h NEW_HOST -U NEW_USER -d NEW_DB latest.dump

Nhược điểm: trong lúc dump/restore, dữ liệu mới trên Heroku vẫn phát sinh. Muốn không lệch, cần đóng write hoặc làm cutover rất nhanh.

Cách 2: Replication

Phù hợp DB lớn, yêu cầu downtime gần 0. Tạo replica từ Heroku Postgres sang DB mới nếu plan hỗ trợ. Hoặc dùng logical replication.

Luồng:

– DB mới nhận dữ liệu từ DB cũ – App mới test read – Trước cutover: tạm dừng write ngắn – Chờ replication lag = 0 – Promote DB mới – Chuyển app sang DB mới – Mở traffic

Phức tạp hơn, nhưng an toàn hơn cho app lớn.

Cách 3: Tạm dùng DB Heroku sau khi chuyển app

Cách thực dụng cho nhiều team:

– App chạy trên Coolify/Dokploy – DB vẫn là Heroku Postgres – Chuyển traffic trước – Migrate DB sau

Ưu điểm: giảm rủi ro. Bạn tách migration thành 2 phần: compute trước, database sau. Nhược điểm: latency có thể tăng, vẫn còn chi phí Heroku DB.

Bước 6: File upload và storage

Heroku filesystem ephemeral. App đúng chuẩn thường đã dùng S3, Cloudinary, R2, DigitalOcean Spaces. Nếu vậy, chỉ cần copy env vars.

Nếu app từng ghi file local trên Heroku, khả năng cao đã có lỗi tiềm ẩn. Sang VPS, bạn cần:

– dùng object storage: S3/R2/Spaces – hoặc mount volume persistent – backup volume định kỳ

Khuyến nghị: file user upload nên nằm ngoài server app. Dùng object storage → rollback/cutover dễ hơn.

Bước 7: Worker, cron, migration

Đừng chỉ deploy web process.

Worker

Nếu Heroku có worker dyno, tạo service riêng:

npm run worker

Hoặc:

bundle exec sidekiq

Hoặc:

python manage.py rqworker

Worker cần cùng env vars, cùng DB/Redis, nhưng không expose HTTP.

Cron/scheduler

Heroku Scheduler cần thay bằng:

– built-in scheduled task trong Coolify/Dokploy nếu có – container cron riêng – GitHub Actions – external cron: cron-job.org, EasyCron – VPS systemd timer

DB migration

Không chạy migration tự động ở nhiều replica cùng lúc. Dễ race condition.

Cách an toàn:

1. Deploy image mới. 2. Chạy migration một lần. 3. Restart web/worker. 4. Health check. 5. Cutover.

Với migration phá vỡ tương thích, dùng pattern expand/contract:

– deploy schema tương thích cũ+mới – deploy code mới – cleanup schema sau

Bước 8: Chuẩn bị DNS cutover

Trước ngày migrate, giảm TTL DNS domain chính xuống thấp:

TTL = 60s hoặc 300s

Làm trước 24h để resolver cập nhật.

Domain hiện tại:

app.example.com -> Heroku

Sau cutover:

app.example.com -> VPS IP

Nếu dùng Cloudflare, có thể chuyển nhanh qua proxy. Nếu dùng DNS thường, TTL thấp giúp giảm thời gian traffic đi nhầm.

Bước 9: Cutover không downtime

Kịch bản an toàn:

Trước cutover

– App mới healthy trên domain phụ – SSL OK – Env production OK – Worker chạy OK – Logs theo dõi được – Backup DB mới nhất – Heroku vẫn chạy – Rollback DNS chuẩn bị sẵn

Trong cutover

1. Tạm dừng tác vụ ghi dữ liệu nặng nếu cần. 2. Chạy final DB sync hoặc đảm bảo app mới dùng cùng DB. 3. Chạy migration nếu cần. 4. Chuyển DNS domain chính sang VPS. 5. Theo dõi logs, error rate, response time. 6. Kiểm tra luồng chính bằng tài khoản thật. 7. Giữ Heroku chạy ít nhất 24–72h.

Nếu dùng Cloudflare, có thể route traffic linh hoạt hơn. Nếu không, chấp nhận một số client vẫn tới Heroku trong thời gian TTL. Vì vậy, app cũ và app mới nên dùng cùng DB trong giai đoạn chuyển tiếp, hoặc DB replication phải được xử lý cẩn thận.

Bước 10: Rollback plan

Không có rollback plan = chưa sẵn sàng migrate.

Rollback tối thiểu:

– DNS trỏ lại Heroku – Heroku app chưa tắt – DB cũ còn nguyên – Env cũ không đổi – Release cũ còn deploy được – Backup trước migration

Nếu migration DB không backward-compatible, rollback sẽ khó. Vì vậy, trước cutover nên ưu tiên migration tương thích hai chiều hoặc tách schema change thành nhiều bước.

Dấu hiệu cần rollback:

– 5xx tăng mạnh – login lỗi hàng loạt – payment/webhook fail – worker backlog tăng nhanh – CPU/RAM/DB connection cạn – latency vượt ngưỡng

Rollback sớm tốt hơn cố sửa trong production khi người dùng đang lỗi.

Sau migrate: tối ưu vận hành

Khi app đã ổn, đừng tắt Heroku ngay. Theo dõi ít nhất vài ngày.

Checklist hậu migrate:

– bật backup DB tự động – test restore backup – cấu hình log retention – thêm monitoring: Uptime Kuma, Grafana, Sentry – cảnh báo disk usage – cảnh báo memory/CPU – rotate secret nếu cần – xóa env thừa – cập nhật webhook URL – kiểm tra SPF/DKIM mail – ghi lại runbook deploy/rollback

Self-host rẻ hơn, nhưng trách nhiệm nhiều hơn. Heroku bán sự yên tâm; Coolify/Dokploy cho bạn quyền kiểm soát. Đổi quyền kiểm soát lấy trách nhiệm vận hành.

Kết luận thực tế

Migrate từ Heroku sang Coolify hoặc Dokploy không nên là “một đêm định mệnh”. Hãy xem đó là chuỗi bước giảm rủi ro: audit → Docker hóa → deploy song song → test domain phụ → xử lý DB/file/worker → giảm TTL → cutover → monitor → rollback nếu cần.

Lộ trình ít rủi ro nhất cho đa số team: chạy app mới trên Coolify/Dokploy nhưng tạm dùng DB/storage cũ, sau đó migrate DB riêng khi hệ thống đã ổn. Cách này không “sạch” nhất, nhưng thực dụng, dễ rollback, ít downtime.

Không downtime không đến từ công cụ. Nó đến từ thiết kế migrate đúng: song song, quan sát được, rollback được, dữ liệu không lệch. Coolify hay Dokploy chỉ là nền tảng; checklist mới là thứ giữ production an toàn.