Sau khi deploy web app, hệ thống của bạn không nằm gọn ở một chỗ mà nằm ở ba nơi khác nhau: mã nguồn nằm trong kho lưu trữ code (thường là GitHub), ứng dụng đang chạy nằm trên hosting / cloud / VPS, còn dữ liệu nằm trong database và các dịch vụ lưu file riêng. Deploy thực chất là đóng gói mã nguồn rồi đặt nó lên một máy chủ luôn bật, có địa chỉ Internet để người khác truy cập được — chứ không phải "đẩy cả dữ liệu lên mạng".
Hiểu đúng ba lớp này, bạn sẽ trả lời được ngay những câu hỏi khiến chủ doanh nghiệp lo nhất: cập nhật phiên bản mới có mất dữ liệu không, đổi server thì mang theo cái gì, và nếu nhà cung cấp đóng cửa thì bạn còn lại những gì trong tay.
Nguồn: video Seri Vibe Coding: Deploy Web App xong thì App và Dữ liệu nằm ở đâu? Server, Hosting, Database của kênh Nghiện AppSheet. Bài này tôi viết lại bằng chữ, bổ sung góc nhìn triển khai cho doanh nghiệp vừa và nhỏ Việt Nam.
Ba phần của một web app: mã nguồn, ứng dụng đang chạy và dữ liệu
Một web app bình thường luôn tách làm ba phần độc lập. Đây là bảng tôi hay vẽ ra giấy cho khách hàng trong buổi đầu tiên:
| Phần | Là cái gì | Thường nằm ở đâu | Mất phần này thì sao |
|---|---|---|---|
| Mã nguồn (source code) | Các file code do bạn hoặc AI viết ra | Kho code như GitHub, GitLab, hoặc máy tính của bạn | Không dựng lại được app, nhưng dữ liệu vẫn còn |
| Ứng dụng đang chạy | Bản code đã được build, đang phục vụ người dùng | Hosting, cloud (Vercel, Cloudflare, GitHub Pages) hoặc VPS | App sập, nhưng deploy lại từ mã nguồn là xong |
| Dữ liệu | Khách hàng, đơn hàng, tồn kho, ảnh, file | Database (PostgreSQL, Supabase, Firebase, MongoDB, Google Sheet) và kho lưu file | Mất thật, không có cách dựng lại nếu không có backup |
Điểm quan trọng nhất: dữ liệu không nằm trong mã nguồn. Code chỉ chứa "cách hiển thị" và "cách xử lý", còn số liệu thật nằm trong database. Vì thế khi bạn deploy web app phiên bản mới, dữ liệu cũ vẫn nguyên — trừ khi ai đó cố tình chạy lệnh xoá hoặc đổi sang database trống.
Deploy web app là gì, và deploy xong thì app nằm ở đâu?
Deploy là đưa mã nguồn lên một máy chủ luôn bật để app chạy được trên Internet. Trước khi deploy, app chỉ sống trên máy tính của bạn (địa chỉ kiểu localhost), tắt máy là tắt app. Sau khi deploy, app nằm trên máy của nhà cung cấp, chạy 24/7, ai có đường link cũng vào được.
Có bốn nhóm nơi để đặt app, mỗi nhóm có cái được và cái mất:
| Nơi deploy | Hợp với | Ưu điểm | Nhược điểm |
|---|---|---|---|
| Nền tảng cloud (Vercel, Netlify, Cloudflare Pages) | Người mới, app nhỏ, bản demo cho sếp xem | Nối với GitHub là tự deploy, có gói miễn phí, không phải quản trị máy chủ | Gói miễn phí giới hạn băng thông và tài nguyên; phụ thuộc hoàn toàn vào nhà cung cấp |
| GitHub Pages | Trang tĩnh, landing page, tài liệu | Rất đơn giản, gắn thẳng với kho code | Không chạy được backend, không hợp app có đăng nhập và xử lý dữ liệu |
| VPS (máy chủ ảo thuê riêng) | App dùng thật trong công ty, nhiều người truy cập | Toàn quyền cài đặt, chạy cả app lẫn database trên cùng một máy, không bị trói vào nền tảng | Phải tự lo cài đặt, bảo mật, backup, chứng chỉ HTTPS; cần người biết việc |
| Hosting truyền thống | Website giới thiệu, WordPress | Rẻ, quen thuộc với dân văn phòng | Thường không hợp web app hiện đại chạy Node.js |
Frontend và backend không bắt buộc nằm cùng một máy. Rất nhiều hệ thống đặt giao diện trên Vercel, backend và database trên VPS hoặc dịch vụ riêng, rồi nối với nhau qua API. Cách này linh hoạt nhưng bạn phải quản lý nhiều nơi hơn; với doanh nghiệp nhỏ, gom về một chỗ thường dễ sống hơn.
Trải nghiệm của tôi khi chuyển từ nền tảng cloud sang VPS
Thời gian đầu tôi deploy web app lên Vercel vì quá tiện: đẩy code lên là có link dùng ngay, không phải đụng tới dòng lệnh nào. App lúc đó tôi đã thấy nhanh rồi. Nhưng khi chuyển hẳn sang VPS, tốc độ cải thiện rõ hơn hẳn — bấm vào menu là nội dung hiện gần như tức thì, trong khi trước đó vẫn có độ trễ nhẹ. App tôi đang dùng có rất nhiều module, chuyển qua lại giữa công việc, văn bản, hồ sơ đều mượt.
Tôi không nói Vercel dở. Với người mới tinh, Vercel vẫn là chỗ nên bắt đầu vì bạn chỉ cần tập trung vào việc làm app. Nhưng khi app đã dùng thật trong công ty, nhiều người vào cùng lúc, có dữ liệu nhạy cảm, thì VPS cho bạn quyền kiểm soát và đường chạy dài hơn.
Database nằm ở đâu và nên chọn loại nào?
Database là một dịch vụ chạy riêng, nằm ngoài mã nguồn, và app nối tới nó bằng chuỗi kết nối (connection string) cùng khoá truy cập. Chuỗi kết nối này phải để trong biến môi trường trên server, tuyệt đối không viết thẳng vào code rồi đẩy lên GitHub — đây là lỗi tôi gặp nhiều nhất ở người mới làm app bằng AI.
Các lựa chọn phổ biến hiện nay:
- Supabase — nền PostgreSQL, dữ liệu dạng bảng (SQL), có gói miễn phí và gói trả phí theo tháng.
- Firebase — dữ liệu dạng JSON, mạnh về realtime và xác thực người dùng.
- MongoDB — cũng là dạng JSON, linh hoạt khi cấu trúc dữ liệu hay thay đổi.
- PostgreSQL / MySQL tự cài trên VPS — chuyên nghiệp nhất, dữ liệu nằm trên máy bạn thuê.
- Google Sheet — không phải database thật, nhưng với app nhỏ thì cực kỳ dễ tra cứu và đối chiếu.
Quan điểm của tôi, và cũng là kinh nghiệm phải trả giá: nếu bạn làm app quản lý cho doanh nghiệp, hãy ưu tiên dạng SQL (bảng — cột). Lý do rất thực tế: dữ liệu dạng bảng xuất ra Excel, Google Sheet hay đồng bộ qua nền tảng khác đều dễ. Dữ liệu dạng JSON lồng nhau thì mỗi lần muốn kéo về bảng, bạn đều phải viết thêm bước "phân rã" cấu trúc — app càng lớn càng cực. Đằng nào cũng mất công học, tôi chọn học thứ dùng được lâu dài.
Công bằng mà nói, JSON không hề tệ: với tính năng chat, thông báo realtime, hoặc dữ liệu mà mỗi bản ghi một kiểu, Firebase và MongoDB làm tốt hơn SQL. Vấn đề chỉ phát sinh khi bạn dùng chúng cho nghiệp vụ bảng biểu như nhập xuất kho, công nợ, chấm công.
Về chi phí: tôi từng trả phí hằng tháng cho Supabase trong một thời gian khá dài rồi mới cắt, vì sau đó tôi gom database về VPS. Nếu bạn muốn ước lượng trước khi quyết, tôi có viết riêng một bài về cách tự ước tính chi phí làm web app.
Có thể giữ dữ liệu trên Google Sheet khi làm web app không?
Có, và với nhiều doanh nghiệp nhỏ đây là lựa chọn hợp lý trong giai đoạn đầu. Lợi thế lớn nhất của Google Sheet là ai trong công ty cũng mở ra xem được, kế toán lọc được, sếp không phải xin ai cũng tra được số liệu. Có hai cách nối web app với Google Sheet:
- Dùng AppSheet API. Nếu bạn đã có app AppSheet trên chính file Sheet đó, vào phần Settings → Integrations của app để bật API, lấy App ID và Access Key. Đưa hai thông tin này cho AI khi bạn vibe coding, yêu cầu nó viết phần kết nối — đây là cách đơn giản nhất, không phải cài đặt lằng nhằng. Tôi thấy tốc độ dùng thực tế vẫn nhanh bình thường, dù chưa phải là tối ưu. Cách tối ưu hơn là dùng Google Service Account. Trước khi làm, bạn nên xem tài liệu chính thức của AppSheet vì chính sách và giao diện có thể đổi.
- Dùng Google Apps Script. Cách này tôi không đánh giá cao. Tôi đã tự test: bảng chỉ có vài dòng mà thao tác xoá vẫn mất trên hai giây, mở danh sách nhân viên cũng phải chờ hơn một giây mới hiện. Apps Script còn bị ràng buộc bởi hạn mức (quota) của Google — app xuất nhập kho dùng thật rất dễ chạm trần. Bạn nên tự kiểm tra con số hiện hành ở trang quota chính thức của Apps Script trước khi quyết định.
Google Sheet không phải nơi ở vĩnh viễn. Khi số dòng lớn dần, nhiều người ghi cùng lúc, hoặc báo cáo bắt đầu chậm, bạn sẽ phải chuyển. Tôi đã viết chi tiết các dấu hiệu đó trong bài dùng Google Sheet làm database: khi nào ổn, khi nào phải chuyển.
Ảnh, file và tên miền nằm ở đâu?
Ảnh và tài liệu thường không nằm trong database mà nằm ở một kho lưu file riêng (object storage, Google Drive, hoặc thư mục trên VPS). Database chỉ lưu đường dẫn tới file đó. Hiểu điều này rất quan trọng: khi backup, nếu bạn chỉ sao lưu database mà quên kho file, thì sau khi khôi phục bạn sẽ có đủ phiếu nhập kho nhưng mọi ảnh chứng từ đều hỏng link.
Còn tên miền là cái tên dễ nhớ mà khách gõ vào trình duyệt, ví dụ app.congtyabc.vn. DNS là cuốn danh bạ chỉ cho trình duyệt biết tên miền đó ứng với máy chủ nào. Khi bạn đổi server, app không đổi, dữ liệu không đổi — bạn chỉ sửa bản ghi DNS để tên miền trỏ sang địa chỉ máy mới. Vì vậy hãy luôn đứng tên chủ sở hữu tên miền bằng email công ty, đừng để bên làm app đăng ký hộ bằng email cá nhân của họ.
Đổi server hoặc cập nhật phiên bản, dữ liệu có mất không?
Không, nếu bạn tách đúng ba lớp ngay từ đầu. Cập nhật phiên bản mới chỉ thay phần "ứng dụng đang chạy", database vẫn nguyên chỗ cũ. Đổi server thì bạn deploy lại mã nguồn trên máy mới, trỏ về cùng database, rồi đổi DNS.
Rủi ro mất dữ liệu đến từ bốn chỗ khác:
- Dùng chung một database cho cả bản thử nghiệm và bản chạy thật, rồi lỡ tay chạy lệnh dọn dữ liệu.
- Để AI tự "sửa cấu trúc bảng cho gọn" trên database thật mà không có bản sao lưu.
- Không bật backup định kỳ, hoặc có bật nhưng chưa bao giờ thử khôi phục.
- Tài khoản dịch vụ do nhân viên cũ đăng ký, nghỉ việc là mất quyền.
Việc tối thiểu nên làm ngay: xuất một bản sao dữ liệu ra file định kỳ (hằng tuần hoặc hằng ngày tuỳ độ quan trọng), cất ở nơi thứ hai, và một lần thử khôi phục thật để biết bản backup đó dùng được.
Ví dụ: một xưởng may nhỏ nên tổ chức hệ thống thế nào?
Giả sử một xưởng may khoảng 30 công nhân ở Bình Dương muốn có web app báo cáo sản lượng theo chuyền. Cách tổ chức tôi sẽ khuyên:
- Mã nguồn: để trong một kho GitHub riêng (private), tài khoản do chủ xưởng đứng tên, mời bên lập trình vào làm cộng tác viên.
- Ứng dụng: giai đoạn đầu deploy web app lên nền tảng cloud miễn phí để tổ trưởng dùng thử hai tuần, chỉnh cho đúng việc rồi mới tính chuyện thuê VPS.
- Dữ liệu: để trên PostgreSQL (hoặc Supabase), đồng bộ bản tổng hợp cuối ngày về một file Google Sheet cho kế toán đối chiếu lương sản phẩm.
- Ảnh lỗi hàng: lưu ở kho file riêng, database chỉ giữ đường dẫn.
- Tên miền: đăng ký bằng email công ty, trỏ DNS về nơi đang chạy app.
Cách này giúp xưởng chỉ tốn tiền khi thật sự cần, mà vẫn giữ được quyền sở hữu đầy đủ ba lớp.
Tóm tắt và việc bạn nên làm tiếp
- Deploy web app = đưa mã nguồn lên máy chủ luôn bật để chạy trên Internet, không phải "đẩy dữ liệu lên mạng".
- Ba lớp tách biệt: mã nguồn ở kho code — ứng dụng ở hosting/cloud/VPS — dữ liệu ở database và kho file.
- Người mới nên bắt đầu bằng nền tảng cloud; khi app dùng thật và nhiều người truy cập thì cân nhắc VPS.
- Với app quản lý doanh nghiệp, ưu tiên database dạng SQL cho dễ xuất, dễ đồng bộ về sau.
- Chuỗi kết nối và khoá API luôn để trong biến môi trường, không đẩy lên GitHub.
- Backup database và kho file; thử khôi phục một lần để biết nó thật sự dùng được.
Bước tiếp theo bạn tự làm được ngay hôm nay: lấy giấy, vẽ ba ô "mã nguồn — ứng dụng — dữ liệu" cho hệ thống bạn đang có, điền tên dịch vụ và tên tài khoản đang đứng chủ vào từng ô. Ô nào bạn không điền được, đó chính là chỗ rủi ro cần xử lý trước.
Đọc thêm: Quy trình xây web app đúng nhu cầu: từ yêu cầu đến MVP và Vibe coding là gì? Làm app bằng cách trò chuyện với AI và giới hạn cần biết.
Câu hỏi thường gặp
›Deploy web app xong thì dữ liệu người dùng lưu ở đâu?
Dữ liệu lưu trong database chạy riêng, không nằm trong mã nguồn. Database có thể là dịch vụ cloud như Supabase, Firebase, MongoDB, hoặc PostgreSQL bạn tự cài trên VPS; file ảnh và tài liệu thường lưu ở một kho file riêng, database chỉ giữ đường dẫn.
›Cập nhật phiên bản mới cho web app có làm mất dữ liệu cũ không?
Không, vì khi deploy phiên bản mới bạn chỉ thay phần ứng dụng đang chạy, còn database vẫn nằm nguyên chỗ cũ. Dữ liệu chỉ mất khi ai đó chạy lệnh xoá, đổi sang database trống, hoặc sửa cấu trúc bảng mà không có bản sao lưu.
›Nên deploy web app lên Vercel hay thuê VPS?
Người mới nên bắt đầu với các nền tảng cloud như Vercel vì nối GitHub là tự deploy, có gói miễn phí và không phải quản trị máy chủ. Khi app dùng thật trong công ty, nhiều người truy cập cùng lúc hoặc chạm giới hạn gói miễn phí, hãy chuyển sang VPS để có toàn quyền và không bị trói vào một nhà cung cấp.
›Web app có thể dùng Google Sheet làm nơi lưu dữ liệu không?
Có, phù hợp với app nhỏ và giai đoạn đầu vì ai trong công ty cũng mở ra tra cứu được. Bạn có thể nối qua AppSheet API (bật trong phần Settings của app để lấy App ID và Access Key) hoặc Google Service Account. Khi dữ liệu lớn dần và nhiều người ghi cùng lúc thì nên chuyển sang database thật.
›Nên chọn database dạng SQL hay JSON cho app quản lý doanh nghiệp?
Với nghiệp vụ bảng biểu như kho, đơn hàng, công nợ, chấm công thì nên chọn dạng SQL như PostgreSQL hoặc Supabase, vì xuất file và đồng bộ sang Excel, Google Sheet đều dễ. Dạng JSON như Firebase, MongoDB hợp hơn với realtime, chat hoặc dữ liệu mà mỗi bản ghi một cấu trúc khác nhau.
Tác giả
Chuyên gia chuyển đổi số · Đại diện 5F Edu
Hơn 8 năm triển khai và tư vấn chuyển đổi số cho doanh nghiệp vừa và nhỏ: chuẩn hoá quy trình, xây phần mềm quản lý bằng AppSheet và web app, tự động hoá bằng N8N. Người làm kênh YouTube Nghiện AppSheet.
