--- title: "Odoo Online, Odoo.sh, On-premise: chọn hosting là chọn phạm vi" url: "https://bahub.vn/khoa-hoc/erp-cho-ba/odoo-online-odoo-sh-on-premise" author: "Võ Văn Trí" published: "2026-09-10" updated: "2026-11-02" source: "bahub.vn" license: "Được dùng lại, trích dẫn và đưa cho AI đọc, với điều kiện ghi rõ nguồn bahub.vn kèm link bài gốc." --- # Odoo Online, Odoo.sh, On-premise: chọn hosting là chọn phạm vi > Odoo Online không chạy được module tùy chỉnh. Database chạy bản trung gian phải chờ lên bản chính mới chuyển ra ngoài được. Ba lựa chọn và những đường một chiều giữa chúng. - Nguồn: https://bahub.vn/khoa-hoc/erp-cho-ba/odoo-online-odoo-sh-on-premise - Tác giả: Võ Văn Trí - Khoá học: ERP cho Business Analyst (mục lục: https://bahub.vn/khoa-hoc/erp-cho-ba.md) - Chương: Nền tảng Odoo Tài liệu giải pháp đã chốt, khách đã ký, trong đó có ba hạng mục phải lập trình. Tới lúc đội kỹ thuật vào dựng hệ thống thì phát hiện ra nền tảng mà khách đang dùng không chạy được module tùy chỉnh. Từ đó có hai đường, và cả hai đều tốn. Một là thuyết phục khách chuyển sang nền tảng khác, kéo theo cả một quy trình chuyển đổi có điều kiện. Hai là bỏ ba hạng mục kia ra khỏi phạm vi, kéo theo một cuộc trao đổi mà bạn ở thế yếu vì chính bạn đã hứa. > Chuyện này xảy ra được vì lựa chọn hạ tầng thường bị coi là quyết định kỹ thuật và bị đẩy sang cho đội hạ tầng, trong khi thực chất nó là một quyết định về phạm vi. ## Vì sao đây không phải quyết định kỹ thuật Ba lựa chọn hạ tầng của Odoo không chỉ khác nhau ở chỗ máy chủ đặt đâu và ai quản lý, mà khác nhau ở chỗ mỗi lựa chọn cho phép bạn làm gì với hệ thống. Nói cách khác, **chọn hạ tầng là chốt trước một cái trần cho phần tùy biến của dự án**. Chốt trần trước khi biết dự án cần tùy biến những gì thì bạn đang đặt cược, và cái giá của việc đặt cược sai không nằm ở hóa đơn hạ tầng mà nằm ở phạm vi phải đàm phán lại. Do đó **câu hỏi về hạ tầng phải được đặt trong buổi kick-off chứ không phải trong tuần dựng hệ thống**, và người đặt câu hỏi đó nên là người nắm phạm vi. Toàn bộ phần ràng buộc trong bài này tôi mô tả theo tài liệu chính thức của Odoo 19, và đây là loại chính sách bạn phải đọc lại trên đúng thời điểm tư vấn chứ không nên tin theo trí nhớ. ## Odoo Online **Lựa chọn thứ nhất là database riêng do chính Odoo lưu trữ và vận hành**, truy cập bằng trình duyệt và không phải cài gì trên máy. Đây là lựa chọn nhẹ nhất về vận hành: không phải lo máy chủ hay cập nhật, sao lưu chạy hằng ngày theo cam kết dịch vụ của Odoo, và bạn tạo được bản sao database để thử nghiệm. Bản sao đó mặc định bật chế độ thử nghiệm, tức các tác vụ ra bên ngoài như gửi email hay thanh toán đều bị tắt, nhưng **nó hết hạn sau mười lăm ngày và mỗi database chỉ tạo được tối đa năm bản sao**. Đổi lại là giới hạn quyết định nhất trong cả bài, và tài liệu chính thức nói rất thẳng: **Odoo Online không tương thích với module tùy chỉnh, và cũng không tương thích với module lấy từ Odoo Apps Store**. Thứ được phép là những tùy biến không cần code, tức cấu hình cộng với Studio. > Hệ quả của câu đó rất lớn: trần tùy biến của dự án dừng ở cấu hình và Studio, còn mọi thứ cần một dòng mã riêng, kể cả thứ tưởng là mua sẵn từ kho ứng dụng, đều nằm ngoài tầm. ![Odoo Online chỉ nhận cấu hình và Studio, module tự viết không chạy được](https://bahub.vn/uploads/2026/11/1793630776267-0rfdk1-odoo-online-odoo-sh-on-premise-1.webp "Odoo Online chỉ nhận cấu hình và Studio, module tự viết không chạy được") Ngoài ra Odoo Online còn có một nhịp nâng cấp bắt buộc. **Database ở phiên bản chính phải nâng cấp hai năm một lần**, còn database ở phiên bản trung gian thì phải lên bản kế tiếp chỉ vài tuần sau khi bản đó ra; nếu bạn không làm trước hạn thì hệ thống tự nâng cấp. Với một doanh nghiệp nhỏ chỉ cần nghiệp vụ chuẩn thì đây là lựa chọn hợp lý và tiết kiệm được nhiều công vận hành. **Với một dự án có bất kỳ hạng mục lập trình nào thì đây là lựa chọn sai**, và phải nói ra ngay từ đầu. ## Odoo.sh **Lựa chọn thứ hai là nền tảng cloud chính thức của Odoo** để lưu trữ và quản lý các ứng dụng Odoo, và điểm khác biệt của nó là bộ công cụ dành cho người phát triển. Trên Odoo 19, tài liệu mô tả nó có web shell, quản lý phụ thuộc giữa các module, tích hợp liên tục và truy cập qua SSH. Quan trọng hơn với BA là mã nguồn của dự án nằm trong một kho GitHub gắn với project, và mọi module tùy chỉnh hay module cộng đồng chỉ cần đưa vào một nhánh của kho đó là nền tảng tự nhận ra; nói cách khác, đây là lựa chọn cloud của chính Odoo mà chạy được code riêng. Tài liệu còn mô tả riêng ba loại nhánh, và phần này đáng đọc kỹ vì nó giải quyết đúng bài toán môi trường mà dự án nào cũng gặp. * **Nhánh production** chỉ có duy nhất một. * **Nhánh staging** là bản nhân bản của dữ liệu thật nhưng đã được trung hòa, tức các tác vụ định kỳ bị tắt, email gửi ra bị chặn lại ở một hộp thư bắt riêng, dịch vụ IAP bị vô hiệu, còn cổng thanh toán và kết nối vận chuyển chuyển sang chế độ thử. Nhờ vậy bạn thử trên dữ liệu thật mà không sợ hệ thống tự gửi thư cho khách hàng của khách, và database của nhánh này tự xóa sau một tháng. * **Nhánh development** thì dựng database mới với dữ liệu mẫu để chạy kiểm thử tự động, và nó là môi trường tạm, chỉ sống khoảng ba ngày. ![Ba loại nhánh: production duy nhất, staging đã trung hòa, development chỉ sống vài ngày](https://bahub.vn/uploads/2026/11/1793630776768-kxesqq-odoo-online-odoo-sh-on-premise-2.webp "Ba loại nhánh: production duy nhất, staging đã trung hòa, development chỉ sống vài ngày") Về nâng cấp, Odoo.sh cho bạn **ba năm hỗ trợ chuẩn của phiên bản cộng thêm hai năm nữa** để hoàn tất việc lên bản mới. Theo cách tôi nhìn thì đây là lựa chọn hợp với phần lớn dự án triển khai có tùy biến, bởi nó giữ được phần tiện của cloud mà không mất phần tự do của việc tự host. Cần lưu ý rằng Odoo.sh đòi một thuê bao Enterprise có bao gồm nền tảng này, còn giới hạn tài nguyên và số môi trường staging thì đi theo gói, nên bạn phải lấy trực tiếp trước khi tư vấn cho khách. ## Tự host **Lựa chọn thứ ba là doanh nghiệp tự chuẩn bị máy chủ rồi cài Odoo lên**, và trong thực tế thì đây là lựa chọn của những khách hàng quan tâm tới hiệu năng hoặc có ràng buộc về nơi lưu trữ dữ liệu. Tài liệu chính thức của Odoo 19 mô tả ba cách cài, và mỗi cách có mục đích khác nhau chứ không phải ba cách làm cùng một việc. * **Cách thứ nhất là dùng gói cài đặt đóng sẵn**, phù hợp để thử nghiệm và để phát triển module; tài liệu nói rõ là dùng cho vận hành lâu dài cũng được nhưng phải kèm thêm công triển khai và bảo trì. * **Cách thứ hai là cài từ mã nguồn**, cho độ linh hoạt cao nhất, chẳng hạn chạy được nhiều phiên bản Odoo trên cùng một máy, và dùng được làm nền cho việc triển khai thật. * **Cách thứ ba là dùng ảnh Docker chính thức**, cho cả phát triển lẫn triển khai. Đặc biệt, **tự host là lựa chọn duy nhất nếu khách chọn bản Community**, bởi cả Odoo Online lẫn Odoo.sh đều gắn với thuê bao Enterprise. Còn nếu sau này khách muốn chuyển lên Enterprise thì cách cài đặt có ảnh hưởng: tài liệu mô tả thủ tục chuyển cho cả bản cài từ gói lẫn bản cài từ mã nguồn, nhưng trang giới thiệu hai phiên bản lại ghi bản cài từ mã nguồn là ngoại lệ. Đây là chi tiết đội kỹ thuật thường quyết một mình vào tuần đầu dự án, nên bạn nên hỏi ngay và dựng thử trên đúng phiên bản trước khi hứa với khách. Về nâng cấp thì tự host là lựa chọn duy nhất cho phép đứng yên ở một phiên bản bao lâu tùy ý, dù tài liệu không khuyến khích, và [vòng đời phiên bản cùng bài toán upgrade](https://bahub.vn/khoa-hoc/erp-cho-ba/vong-doi-version-odoo-va-bai-toan-upgrade) là chủ đề của một bài riêng. ## Những đường một chiều Phần đáng giá nhất của bài nằm ở đây, bởi đây là chỗ mà một quyết định tưởng là đảo được hóa ra không đảo được. Chiều từ tự host sang Odoo Online thì có điều kiện, và thứ tự các bước cũng quan trọng chứ không chỉ nội dung từng bước. 1. Đầu tiên bạn nhân bản database ra một bản riêng 2. Tiếp theo gỡ toàn bộ module ngoài chuẩn trên chính bản nhân bản đó chứ không phải trên hệ thống khách đang dùng 3. Sau đó mới lấy bản dump có kèm filestore từ bản nhân bản. **Điều kiện đi kèm là phiên bản hệ thống đang chạy phải còn trong thời gian được hỗ trợ.** Ngoài ra đây không phải thao tác tự làm được mà phải mở ticket hỗ trợ, kèm theo một loạt thông tin gồm: * số thuê bao * địa chỉ mong muốn * bản dump có kèm filestore * khu vực lưu trữ * tên database * phiên bản * email quản trị * thời điểm dự kiến chạy thật * và cả việc bạn có muốn được triển khai thử một lần trước hay không. Mục cuối cùng nghe như tùy chọn nhưng tài liệu khuyến nghị khá mạnh, nhất là với database từng cài ứng dụng của bên thứ ba. Chiều từ Odoo.sh sang Odoo Online cũng theo đúng tinh thần đó, tức gỡ module ngoài chuẩn trên nhánh staging trước rồi mới tới production. Chiều ngược lại, tức từ Odoo Online ra hai lựa chọn kia, có một cái bẫy ít người biết. Ngoài các phiên bản chính thì Odoo còn phát hành các bản trung gian chỉ chạy trên Odoo Online, và **database đang chạy một bản trung gian thì không được hỗ trợ trên Odoo.sh hay tự host**. Muốn chuyển thì phải nâng lên phiên bản chính kế tiếp trước, và nếu phiên bản chính đó chưa được phát hành thì bạn phải chờ. > Nghĩa là thời điểm muốn chuyển chưa chắc là thời điểm chuyển được, và với một dự án đang chạy thì vài tháng chờ là chuyện lớn. ![Đang ở bản trung gian thì phải chờ bản chính kế tiếp ra mới chuyển ra ngoài được](https://bahub.vn/uploads/2026/11/1793630777277-4n9u8v-odoo-online-odoo-sh-on-premise-3.webp "Đang ở bản trung gian thì phải chờ bản chính kế tiếp ra mới chuyển ra ngoài được") ## Ba câu hỏi chốt lựa chọn Gộp lại thì việc chọn hạ tầng rút gọn về ba câu, và cả ba đều nên được hỏi trong buổi kick-off. **Câu thứ nhất là dự án này có bất kỳ hạng mục nào cần mã riêng không**, kể cả module mua sẵn từ kho ứng dụng. Nếu câu trả lời là có, dù chỉ một hạng mục, thì Odoo Online bị loại ngay. **Câu thứ hai là ai sẽ vận hành hệ thống này sau khi dự án kết thúc.** Nếu doanh nghiệp không có đội kỹ thuật và cũng không định thuê ai dài hạn thì tự host là lựa chọn tạo ra một khoản nợ vận hành mà không ai đang tính tới. **Câu thứ ba là dữ liệu có ràng buộc nào về nơi lưu trữ không.** Với một số ngành và một số loại dữ liệu thì đây không phải chuyện sở thích mà là chuyện tuân thủ, và nó có thể loại thẳng hai lựa chọn cloud. Trả lời xong ba câu đó thì thường chỉ còn một lựa chọn hợp lý, và bạn có căn cứ để giải thích vì sao. ## Những gì bài này không trả lời Có ba nhóm thông tin tôi cố tình không đưa vào bài, và tôi nghĩ nên nói thẳng thay vì viết chung chung cho đủ. * **Nhóm thứ nhất là mọi con số giá.** * **Nhóm thứ hai là giới hạn tài nguyên của Odoo.sh**, gồm số đơn vị xử lý, bộ nhớ, dung lượng và số môi trường staging theo từng gói, những thứ đi theo chính sách thương mại nên thay đổi theo thời điểm. * **Nhóm thứ ba là cấu hình máy chủ tối thiểu khi tự host**, thứ phụ thuộc vào số người dùng và khối lượng dữ liệu tới mức một con số chung sẽ gây hiểu nhầm nhiều hơn là giúp ích. Với cả ba nhóm, cách đúng là hỏi trực tiếp trước khi tư vấn, và ghi lại ngày bạn hỏi. Khi đã chốt bản nào và host ở đâu thì công việc chuyển vào bên trong hệ thống, và thứ đầu tiên bạn phải quyết ở đó là [dữ liệu sẽ được lưu dưới dạng nào](https://bahub.vn/khoa-hoc/erp-cho-ba/kieu-field-odoo-goc-nhin-ba). --- Nguồn: https://bahub.vn/khoa-hoc/erp-cho-ba/odoo-online-odoo-sh-on-premise — Được dùng lại, trích dẫn và đưa cho AI đọc, với điều kiện ghi rõ nguồn bahub.vn kèm link bài gốc.