VPS cho người mới: Vì sao indie dev cần một VPS? (Bản sâu 2026)

“Laptop của mình là M3 Pro 16GB RAM, sao mình vẫn cần một con server có 4 core 8GB vậy?”

Trên subreddit r/indiehackers, đây là một trong những câu hỏi mà các newbie hỏi nhiều nhất. Giờ đây khi Serverless (như Vercel) và PaaS (như Supabase) đang thịnh hành ngang ngửa, thì VPS (Virtual Private Server) nghe xưa cũ và “cổ lỗ” làm sao.

Nhưng sự thật là: những indie dev thực sự chạy được mô hình kinh doanh và có lợi nhuận bền vững, chắc chắn trong tay đều nắm sẵn vài con VPS.

Bài viết này sẽ đi từ 7 nỗi đau cốt lõi của indie dev, phân tích sâu xem vì sao VPS chính là con đường tất yếu để bạn bước lên tầm chuyên nghiệp, thoát khỏi cảnh “đồ chơi code”.

---

1. Thoát khỏi “hội chứng lo âu ở máy local”: giải quyết “lỗ đen” dung lượng của node_modules và Docker

Tài sản đắt giá nhất của indie dev là chiếc laptop, nhưng thứ rẻ nhất lại chính là ổ cứng của nó. Đợt code bằng AI này đại đa số toàn NextJS, kéo theo thảm họa node_modules. Thực ra còn có cc cũng rất thích kéo bb. Nếu để ý quá trình chạy của cc, bạn sẽ thấy nó cứ viết linh tinh vào thư mục /tmp hoài.

• Nỗi đau: Vắt kiệt ổ cứng lẫn hiệu năng

  • node_modules “bùng nổ”: Chạy song song 10 dự án, gói node_modules một mình đã nuốt gọn hơn 50GB SSD.
  • Docker image chất đống: Chạy container ngay trên máy local khiến hệ thống ì ạch, quạt tản nhiệt gào lên.
  • Ngốn tài nguyên tính toán: Chạy trực tiếp các middleware như PostgreSQL hay Redis trên máy sẽ làm IDE lag rõ rệt.

• Giải pháp: Dùng VPS làm “trung tâm tính toán hạng nặng”
  Bạn chỉ cần giữ lại một bộ VS Code + Cursor siêu nhẹ trên máy, rồi dùng Remote SSH kết nối vào VPS. Toàn bộ dependencies và môi trường nặng nề đều chạy trên mây, laptop chỉ việc hiển thị UI thôi.

2. Nói không với “SaaS chèn ép hóa đơn”: Nhìn chi phí từ góc độ logic kinh doanh

Làm indie dev, sợ nhất không phải là không có user, mà là user chưa kịp trả tiền thì bill SaaS đã nổ tung rồi. Vài năm nay làm AI coding, chắc chắn ai cũng đụng đến mấy tool như Supabase, Clerk, thực ra kể cả Vercel cũng vậy. Dùng thử một hồi thấy lúc đầu sướng lắm, nhưng sướng mãi rồi thì hóa ra bill thì nổ luôn.

Vercel có một cái bẫy khá thú vị, đó là component Image. Lúc build nó sẽ gợi ý bạn nên dùng component <Image, nghe có vẻ tâm lý lắm đúng không? Nhưng cái component này mặc định sẽ chạy qua service tối ưu hình ảnh của Vercel — cứ tối ưu mỗi tấm ảnh là tính tiền một lần. Với những site có traffic lớn, thì riêng tiền tối ưu ảnh thôi đã có thể vượt qua cả tiền hosting rồi.

Gói Hobby miễn phí của Vercel rất hấp dẫn — deploy, CDN, SSL đều bao trọn gói. Nhưng vừa lúc project của bạn bắt đầu có traffic là ác mộng bắt đầu rồi.

Bảng giá khi vượt giới hạn:

Tài nguyên	Gói Pro bao gồm	Phí khi vượt giới hạn
Băng thông	1 TB/tháng	$0.15/GB (tức $150/TB)
Edge Requests	10 triệu/tháng	$2/triệu
Thời gian thực thi Serverless	40 giờ/tháng	$5/giờ
Tối ưu hình ảnh	5000 tấm/tháng	$5/1000 tấm

• Nỗi đau: Chi phí mở rộng bị “bắt cóc”

  • Cái bẫy PaaS: Gói miễn phí của Firebase nghe rất hấp dẫn, nhưng hễ dính tới backup phức tạp hay lưu lượng cao là giá tăng theo cấp số nhân.
  • Mất phí xác thực: mấy ông như Clerk tính tiền theo người dùng hoạt động hàng tháng (MAU), với mấy app có tần suất dùng cao mà giá trị đơn hàng thấp thì đúng là ác mộng.

• Giải pháp: Tự host toàn stack (Self-hosting)
  Trên một con VPS 5$/tháng, bạn có thể vắt kiệt hiệu suất bằng Docker để chạy cùng lúc: database (PostgreSQL), hệ thống xác thực (PocketBase) và hệ thống thống kê (Umami).

💡 Nói cho công bằng: tự host thì đúng là cần chút kỹ năng vận hành (ops). Nhưng dạo này khá nhiều dev nước ngoài chia sẻ kinh nghiệm tự duy trì PostgreSQL — thực ra đơn giản hơn mình tưởng nhiều, nhất là từ khi có Docker và mấy script backup tự động. Mình sẽ hướng dẫn chi tiết cách làm ở phần sau.

3. CI/CD “thật xịn”: Xây dựng pipeline tự động hóa cho “Bộ phận IT 1 người”

Lợi thế cạnh tranh lớn nhất của indie developer chính là tốc độ lặp lại. Deploy lên các nền tảng serverless như Vercel, Cloudflare, Netlify trong giai đoạn đầu để validate nhu cầu thị trường thì tuyệt vời, nhưng vấn đề của mấy nền tảng này là phần runtime Node.js của chúng không hoàn chỉnh, nên mấy cái task chạy dài hơi là bó tay. Ngày xưa mỗi lần build local là máy kêu o o, giờ thì nhờ GitHub Actions lo hết cho rồi, xong việc là ra Docker image, thế là cất cánh bay luôn.

• Giới hạn thời gian thực thi: Hàm Serverless thường có timeout từ 10-60 giây, mặc định thường là 10s

• Không có process liên tục: WebSocket, long-polling, hay background task dùng cực kỳ gượng ép

• Độ trễ cold start: Request đầu tiên có thể phải chờ vài giây

• Nỗi đau: Vừa deploy thủ công vừa dễ sinh bug
  Nếu bạn vẫn đang cặm cụi chạy thủ công từng câu lệnh git pull, bạn không chỉ đang lãng phí thời gian sống mà còn tăng nguy cơ “tạo drama” cho production nữa kìa.

• Giải pháp: Tự động hóa nhẹ nhàng ngay trên VPS
  Dùng VPS để chạy GitHub Actions Runner:

  1. Git Push kích hoạt pipeline.
  2. VPS tự động kéo code về và build Docker image.
  3. Docker Compose tự động restart container, update mượt mà mà không gián đoạn một giây nào.

Mình cũng không rõ có phải vì vậy không, chứ dạo này cloudflare cũng chẳng mặn mà với pages nữa, lại quay về worker, xài cứ thấy gượng gạo khó chịu, bạn thấy sao về vụ này?

4. Xử lý “rào cản mạng”: Từ crawl âm thầm đến truy cập xuyên biên giới

Nhiều dự án chạy trên máy local cứ báo lỗi sùm sùm, hóa ra không phải do code dở, mà do môi trường mạng. Mấy cái npm package mình hay xài để dev, hoặc mấy tài nguyên khác, cứ vướng cái rào mạng là phát bực mình, mệt mỏi, muốn văng tục, chán ngấy luôn.

• Nỗi đau: IP hay đổi và mạng bị chặn

  • Cần IP cố định: Khi làm việc với API của Stripe, PayPal hay ngân hàng, thường phải whitelist một IP public cố định. IP động của mạng nhà thì mù đường, xài không được luôn.
  • Mạng chập chờn: Lúc code kéo mấy cái package npm, image Docker hay tài nguyên trên GitHub mà mạng cù nhầy thì phát bực mình thật sự.
  • Bị chặn anti-bot: Nếu bạn đang làm project dạo data, IP mạng nhà rất dễ bị hệ thống anti-bot quét và khóa ngang.

• Giải pháp: Dùng VPS làm trạm trung chuyển mạng

  • Định danh cố định: Cấp cho hệ thống một IP public cố định lâu dài, đảm bảo Stripe Webhook hay OAuth callback chạy đều đặn không bị gián đoạn.
  • Trung tâm reverse proxy: Chỉ cần một con VPS kết hợp với Nginx hoặc Caddy, bạn có thể quản lý hơn 10 domain và forward về các port local khác nhau.
  • Tăng tốc môi trường dev: Chạy npm install hay docker pull thẳng trên VPS, tốc độ download bay hơi, không còn bị mạng nhà làm phiền nữa.

Mình có “thù” với nginx proxy manager rồi, bực mấy lần rồi. Chạy Docker của nó tốn tận chục Gb dung lượng, đúng là không hiểu nổi, trong khi Caddy thì gọn nhẹ hơn hẳn.

5. Giữ gìn “thu nhập thụ động”: Giám sát và Khôi phục sự cố 24/7

Cảm giác đau lòng nhất của dev độc lập là sáng ngủ dậy, phát hiện server sập cả đêm mà mình không hề hay biết. (Hy vọng đây chỉ là lo lắng thừa thôi, chứ nếu là project đã thực sự ra tiền thì mình chăm sóc nó lắm!)

Nỗi đau: Thiếu “lính gác”

• Máy tính cá nhân hay ngủ standby, không thể giám sát liên tục được
• Các tool giám sát miễn phí tần suất kiểm tra quá thấp (ví dụ 5 phút/lần), đến khi phát hiện ra lỗi thì user đã bỏ đi hết rồi
• Nhiều lỗi mang tính “thỉnh thoảng mới xảy ra”, đợi mình vào kiểm tra thủ công thì mọi thứ lại đàng hoàng

Giải pháp: Tự dựng trạm giám sát

Deploy Uptime Kuma (hoặc các tool tương tự) lên VPS, cứ 30-60 giây là kiểm tra tình trạng truy cập toàn cầu một lần. Chỉ cần service có sập là báo ngay qua Telegram, Discord hoặc email.

Gợi ý danh sách giám sát:

Hạng mục giám sát	Tần suất kiểm tra	Cách báo cáo
HTTP status code	60 giây	Thông báo tức thì qua Telegram
SSL certificate hết hạn	Mỗi ngày	Cảnh báo trước 14 ngày
Tài nguyên server	5 phút	Báo động khi CPU/RAM vượt 80%
Kết nối database	60 giây	Thông báo ngay khi kết nối thất bại

Mẹo nâng cao:

• Dùng Uptime Kuma để theo dõi uptime
• Dùng Bezel hoặc Netdata để monitor tài nguyên server. Bezel xài khá ấm, còn Netdata thì hơi nặng một chút.
• Kết hợp cả hai lại là bạn sẽ có một vòng lặp giám sát khép kín luôn.

6. Data Sovereignty: “Tuyến phòng thủ cuối cùng” của indie dev

• Nỗi đau: Rủi ro phụ thuộc nền tảng

  Nếu ném hết data lên Firebase mà một ngày đẹp trời tài khoản bị ban vì lý do tuân thủ chính sách, thì bao nhiêu công sức bỗng chốc đổ sông đổ biển.

• Giải pháp: Lưu trữ tại chỗ trên VPS + Backup chéo nơi khác

  • Cách ly dữ liệu: File database hoàn toàn do bạn làm chủ.
  • Backup tự động: Viết một cái Cron job đơn giản, mỗi ngày tự động mã hóa data rồi đồng bộ lên S3 hoặc ổ cứng ở nhà.

7. Phân bổ tài nguyên cho Indie Dev: Chiến lược “1 + N”

Dành cho các kịch bản phát triển điển hình năm 2026, mình đề nghị các bạn triển khai theo mô hình sau:

Loại	Cấu hình đề xuất	Vai trò chính
1 máy chủ chính	2 vCPU 4GB hoặc 4 vCPU 8GB	Chạy Nginx, database chính, sản phẩm cốt lõi.
N máy哨兵	1 vCPU 1GB hoặc thấp hơn	Chạy Uptime Kuma để monitor, crawler nhỏ, môi trường test.

Tại sao lại phải tách ra?

• Dịch vụ monitor không nên chạy chung trên cùng một máy với dịch vụ đang được monitor — nếu không, khi máy sập, bạn cũng chẳng nhận được cảnh báo nào luôn.
• Tách biệt môi trường test và production, tránh lỡ tay thao tác nhầm.
• Nhiều máy nhỏ sẽ linh hoạt và chịu tải tốt hơn so với chỉ một cỗ máy lớn.

Trên Reddit, Hetzner luôn được nhắc đi nhắc lại là “vua về giá cả”: với cùng mức giá, cấu hình bạn nhận được thường gấp 2-3 lần so với các cloud provider bên Mỹ. Điểm trừ là datacenter chủ yếu nằm ở châu Âu, nên độ trễ khi truy cập từ châu Á sẽ khá cao.

Nói sao nhỉ, database vẫn rất quan trọng đấy. Nếu thời gian có hạn thì cứ dùng mấy đứa như Neon hay Supabase cho khỏe.

Tổng kết: Tấm vé bước từ “cho vui” lên “chuyên nghiệp”

Từ khoảnh khắc sở hữu một chiếc VPS, bạn không chỉ đơn thuần là “người viết code” nữa, mà đã trở thành “người làm chủ hệ thống”. Nó mang đến cho bạn:

• Tính xác định: Không còn bị ảnh hưởng bởi sự thay đổi của môi trường local.
• Tính liên tục: Sản phẩm tự vận hành 24/7 bất kể ngày đêm.
• Tính thương mại: Nâng cấp và mở rộng hệ thống với chi phí biên thấp nhất.

Giống như câu mà mấy anh em indie dev hay truyền tai nhau: “Địa chỉ IP server đầu tiên chính là tấm danh thiếp đầu tiên của sản phẩm.” (Tự bịa đấy 😉)