Which Odoo install route fits your team
If you are an infrastructure or IT lead hosting Odoo inside your own network, the packaged installer is the right starting point for most on-premise production servers running a supported Linux distribution. The official deb package currently supports Ubuntu Noble (24.04 LTS), the rpm package supports Fedora 42, and updates arrive through the usual apt-get upgrade workflow, which keeps routine maintenance inside tooling your team already uses. Source installs and the official Docker image suit teams with specific needs, and both take on more of the setup and upkeep. Packaged installers cover Community and Enterprise, but downloading Enterprise packages requires logging in as a paying on-premise customer or partner, so confirm your account access before you plan the build.
Developers who write custom modules or run several Odoo versions side by side will usually prefer a source install. Odoo's documentation says running from source is more convenient for module developers and gives greater control over the setup. The cost is that your team owns the Python and PostgreSQL environment: Odoo 19 requires Python 3.10 or later and PostgreSQL 13 or above, and the AI features need pgvector on PostgreSQL 15 or later. Platform engineers who already run container pipelines and want images that are versioned and reproducible will find the official Docker image a better fit. That image expects a separately running PostgreSQL server, stores the filestore under /var/lib/odoo and custom addons under /mnt/extra-addons, and has no official Enterprise image, so Enterprise modules must be mounted as custom addons. Confirm with Odoo how that arrangement is licensed before you rely on it.
Windows packaging is for testing or running a single-user local instance only. Odoo's packaged installers documentation discourages production deployment on Windows because of its limitations and risks, so do not host shared business data there. Small IT teams with a single Linux server and no container platform should generally stay on the packaged installer, while teams that need source-level control or container-native operations should plan for the extra patching and database work their chosen route brings. Whichever route you pick, check the Enterprise access terms and the wkhtmltopdf requirement for PDF reports before go-live, because they differ by route.
How the three routes compare on platforms, editions and prerequisites
This table sets the packaged installers, source install and official Docker image side by side on platforms, editions, Enterprise access and runtime prerequisites. Read each row against the exact Odoo version you plan to deploy, because the supported platforms and minimum versions change between releases.
| Factor | Packaged installers | Source install | Official Docker image |
|---|---|---|---|
| Supported platforms | Debian-based and RPM-based Linux distributions and Windows. The deb package currently supports Ubuntu Noble (24.04 LTS) and the rpm package supports Fedora 42 (Odoo 19 docs). Confirm the current list for your version. | Runs from the Odoo source code on the operating system you prepare. Confirm your distribution's Python and PostgreSQL packages meet the minimums for your version. | Runs on a container host. Confirm the image tag and base operating system against the official image documentation for your version. |
| Community availability | Available for Community edition | Available for Community edition from the Odoo GitHub repository (LGPL-3.0) | Available for Community edition |
| Enterprise availability | Available for Enterprise edition | Enterprise source code is not publicly available; access requires a subscription or partner access | No official Enterprise image. Enterprise modules can be mounted as custom addons |
| How Enterprise access is obtained | Download requires logging in as a paying on-premise customer or partner. Activate the database with the subscription code | Source code access through a subscription or partner access | Obtain the Enterprise module code through your subscription, then mount it into the custom addons path. Confirm licensing terms with Odoo |
| PostgreSQL ownership | Installed alongside Odoo by the package, so the server is typically managed on the same host. Confirm your backup and sizing plan | You install and manage PostgreSQL yourself, separately from the Odoo code | Requires a separately running PostgreSQL server, so the database is outside the container. Confirm where it runs and who backs it up |
| Python requirement | Handled by the package for the supported distribution. Confirm the Python version it ships for your release | Python 3.10 or later for Odoo 19 | Set by the image for the chosen version. Confirm the Python version in the image tag |
| PostgreSQL requirement | PostgreSQL 13 or later for Odoo 19. Confirm the version your package installs | PostgreSQL 13 or above for Odoo 19 | Connects to an external PostgreSQL server. Confirm it meets the version required for your release |
| AI features need pgvector on PostgreSQL 15 or later | Install pgvector on PostgreSQL 15 or later if you use AI features. Confirm package availability on your distribution | Install pgvector on PostgreSQL 15 or later if you use AI features | Provide pgvector on the external PostgreSQL 15 or later server if you use AI features. Confirm with your database team |
| Main developer use | Production-oriented installs on supported Linux. Windows is for testing or single-user local instances only, and production use is discouraged | Module development and running several Odoo versions side by side, with greater control over the setup | Repeatable container deployments, with filestore under /var/lib/odoo and custom addons under /mnt/extra-addons |
What each route puts on your server
The three Odoo install routes differ mainly in who owns the pieces around the Odoo process. Each route leaves a different set of components for your team to install, patch, back up and keep compatible, and the PDF report dependency applies to all of them.
Packaged installer for Debian and RPM
The official packages cover Debian-based and RPM-based Linux for both Community and Enterprise. The deb package currently supports Ubuntu Noble (24.04 LTS) and the rpm package supports Fedora 42, so check your distribution against those names before you plan. Updates arrive through the usual apt-get upgrade command. Enterprise packages require a paying on-premise customer or partner login, so confirm access before you commit to this route.
Source install on your own servers
A source install means you check out the Odoo code, build a Python environment and point Odoo at a PostgreSQL server you run yourself. Odoo 19 requires Python 3.10 or later and PostgreSQL 13 or above, and the AI features need pgvector on PostgreSQL 15 or later. You own the interpreter, the virtual environment, the service unit and the filestore backup. This route suits developers who need several Odoo versions side by side.
Official Docker image with external PostgreSQL
The official image runs the Odoo process only. You must run a separate PostgreSQL server and connect it, so the database lifecycle, its backups and its version sit outside the container. The filestore lives under /var/lib/odoo and custom addons mount at /mnt/extra-addons. Both paths need persistent volumes, or attachments and modules are lost when the container is replaced. There is no official Enterprise image, so Enterprise modules are mounted as custom addons.
Manual wkhtmltopdf for PDF reports
Odoo does not install wkhtmltopdf through pip, so the operator installs it by hand on every route. PDF reports need version 0.12.6 to render headers and footers correctly. Check this on each new host and after each rebuild, because a missing or mismatched binary produces reports that look wrong rather than failing outright. In Docker, bake the binary into your image rather than installing it at container start.
Who patches, upgrades and backs up each install
This table sets out who performs each recurring task on the packaged installer, source install and official Docker image routes, and which skills each task needs. Read each row as the operating burden you would take on; the main takeaway is that the packaged route automates the most while source and Docker shift more of the work to your team.
| Operating task | Packaged installer (Debian or RPM) | Source install | Official Docker image |
|---|---|---|---|
| Upgrade command | Kept current with the usual apt-get upgrade command, per Odoo's packaged installer documentation for Odoo 19 | Operator pulls the new code and reinstalls dependencies manually | Operator replaces the image tag and redeploys the container |
| Code and dependency updates | Packaged by Odoo; operator confirms the package and its dependencies update cleanly | Operator pulls code and manages Python and PostgreSQL dependencies | Image rebuilt by the image maintainer; operator manages custom addons mounted under /mnt/extra-addons |
| Database and filestore backups | Operator schedules PostgreSQL dumps and filestore copies; no built-in backup routine is assumed | Operator schedules PostgreSQL dumps and filestore copies | PostgreSQL runs as a separate service, so operator backs up that server and the volume holding /var/lib/odoo |
| Monitoring | Operator monitors the host, the Odoo service and PostgreSQL | Operator monitors the host, the Odoo process and PostgreSQL | Operator monitors containers, the PostgreSQL server and volume capacity |
| Major version upgrades | Odoo's upgrade service requires an Enterprise subscription for on-premise use; Community has no access | Community has no access to the upgrade service; team plans and tests the migration | Community has no access to the upgrade service; team plans and tests the migration |
| Security updates | Provided only during standard support, which covers three years after a major release | Provided only during standard support, which covers three years after a major release | Provided only during standard support, which covers three years after a major release |
| Skills each task needs | Linux administration, apt packaging, PostgreSQL backup and restore | Linux, Python, PostgreSQL, Git and service management | Docker, container volumes, PostgreSQL operations and image tag management |
Why the Windows package is not for production, and how Enterprise fits each route
Odoo offers Windows packaging, but its own packaged installers documentation positions it for testing or for running a single-user local instance, and it discourages production deployment because of a number of limitations and risks. Treat that as a hard boundary for a shared business database. Before you decide, ask Odoo for the current list of Windows limitations for the version you plan to run, and confirm how each one affects your user count, backup routine and PDF reporting. If you need a Windows-hosted workload, the practical production path is a Linux server, either from the Debian-based or RPM-based packages or from a source install, with the Windows machine used only as a client.
Enterprise access works differently on each route. Downloading Enterprise packages requires logging in as a paying on-premise customer or partner, and the Enterprise source code is not publicly available, so a source install of Enterprise also depends on that access. There is no official Odoo Enterprise Docker image, but Enterprise modules can be mounted as custom addons into the official image, which places the licensing and update burden on your team. On any route, activate the Enterprise database with the subscription code, and make sure the subscription matches your user count, since Enterprise licensing requires a valid subscription for that number of users. Confirm the exact steps for your edition with Odoo's on-premise documentation before you commit to a route.
How to prepare the server before the first install
This sequence confirms the Odoo version, platform and database requirements before any package, source tree or container is touched, so the first install starts from a known-good host. It ends with a tested backup and a documented record of who owns each step.
Confirm the Odoo version and support window
Choose the major version and check its support window before installing anything. Odoo 20 was released in September 2026 with standard support planned until September 2029, while Odoo 19 and Odoo 18 remain under standard support. The operator records the chosen version and its end-of-standard-support date, and an implementation partner would confirm the same dates against the current support documentation in the written scope. Done when the version and date sit in the project record.
Pick a supported Linux distribution and install route
Match the host to the install route. The packaged deb installer currently supports Ubuntu Noble (24.04 LTS), the rpm package supports Fedora 42, and Windows packaging is meant for testing or single-user local use, not production. Source installs and the official Docker image are not limited to those packages, so the operator confirms the distribution fits the chosen route. Done when the OS version is written down and matches a supported package or a documented source or container host.
Confirm Python and PostgreSQL versions
Check that the host can run Odoo 19, which requires Python 3.10 or later and PostgreSQL 13 or later. The operator runs the version commands on the host, for example
python3 --versionandpsql --version, and compares the output with those minimums. If the distribution ships older versions, the operator or partner decides whether to add a newer runtime before install. Done when both versions are recorded and meet the minimums.Decide where PostgreSQL runs
Choose between a local PostgreSQL instance on the Odoo host and a separate database server. The official Docker image requires a separately running PostgreSQL server, so the container route forces this decision early. A separate server adds network, credentials and backup scope, while a local server keeps the stack on one host with a shared failure domain. The operator documents the choice and the network path, and the partner scopes any high availability design in writing. Done when the database host, port and role for Odoo are defined.
Check pgvector for AI features
Determine whether any planned Odoo AI features need the pgvector extension. Odoo's source installation documentation states that AI features need pgvector on PostgreSQL 15 or later. If AI is in scope, the operator confirms the PostgreSQL major version is 15 or later and that the extension can be installed on that server. If AI is out of scope, the operator records that decision so the extension is not treated as a blocker later. Done when the AI requirement is either met and verified or formally deferred.
Install wkhtmltopdf 0.12.6 manually
Install wkhtmltopdf at version 0.12.6 by hand, because Odoo's packaged installers docs note it is not installed through pip. This version is what supports headers and footers in PDF reports. The operator installs the exact build, runs
wkhtmltopdf --version, and generates a test invoice or report with a header and footer to confirm rendering. Done when the version string reads 0.12.6 and a test PDF renders correctly.Obtain Enterprise access if required
If the deployment includes Enterprise modules, the operator must obtain access first. Downloading Enterprise packages requires logging in as a paying on-premise customer or partner, and Enterprise databases are activated with a subscription code. Community-only deployments skip this step. The operator confirms the subscription status with Odoo and stores the credentials in the secrets vault. Done when the account can download the Enterprise package or the Community-only scope is recorded.
Set up and test backups before go-live
Configure database and filestore backups and restore one into a test environment before the first production start. Odoo's filestore lives under /var/lib/odoo in the Docker image, and the database and filestore must be backed up together. The operator schedules backups, sets retention, and performs a restore test. An implementation partner would typically scope backup design, retention and restore testing in the written statement of work. Done when a restore has been completed successfully and the result is documented.
Which route suits each team profile
The packaged installer suits a small IT team that runs one production instance on a supported Linux server and wants upgrades handled through the operating system's package tooling. The official packages cover Debian-based and RPM-based distributions for both Community and Enterprise, so the team keeps a familiar patching routine instead of building a Python and PostgreSQL toolchain by hand. The route fits when the server OS matches a supported package and the instance does not need heavy custom code.
- Supported platform match: The deb package currently supports Ubuntu Noble (24.04 LTS) and the rpm package supports Fedora 42, so check your distribution and release before choosing this route.
- Routine upgrades: The packaged docs describe keeping installs current with the usual apt-get upgrade command, which suits teams without a build pipeline.
- Enterprise access: Downloading Enterprise packages requires logging in as a paying on-premise customer or partner, so confirm your subscription before planning.
- Windows is a poor fit: The Windows package is offered for testing or single-user local instances, and Odoo discourages production use on it.
- Safer alternative: If your distribution is not on the supported list or you need PDF headers and footers managed carefully, a source install may be safer.
Before committing, confirm the current supported distributions and your Enterprise entitlement with Odoo, and check the wkhtmltopdf requirement for PDF reports.
The source install suits a developer or partner team that builds custom modules, runs several Odoo versions side by side or needs a close view of the code. Odoo's source install documentation says running from source is more convenient for module developers and gives greater control over the setup. Teams that maintain modules for several clients often need this flexibility, and it also suits Odoo's upgrade testing work.
- Module development: Running from source makes the module loop and debugging workflow direct for developers.
- Parallel versions: The source route makes it easier to run multiple Odoo versions side by side on one build machine.
- Runtime requirements: Odoo 19 requires Python 3.10 or later and PostgreSQL 13 or above, and AI features need pgvector on PostgreSQL 15 or later.
- Ongoing maintenance: The team owns the Python environment, dependency pinning, service units and OS patching, so budget that effort explicitly.
- Safer alternative: If the instance is a single production system with no custom code, the packaged installer or Docker image carries less upkeep.
Ask your partner or internal lead to document the exact Python, PostgreSQL and wkhtmltopdf versions per environment, since these drive most source-install failures.
The official Docker image suits a platform team that already runs containers, has its own orchestration and keeps PostgreSQL in a managed or separate service. The image does not bundle a database, so the team connects it to an external PostgreSQL server, which fits existing backup, failover and access controls. Persistent data sits in defined paths, so the team can apply its storage and backup standards to those volumes.
- External database: The image requires a separately running PostgreSQL server, so database operations stay with the team that already runs it.
- Defined data paths: The filestore lives under /var/lib/odoo and custom addons mount under /mnt/extra-addons, which simplifies volume and backup design.
- Enterprise modules: There is no official Enterprise Docker image, but Enterprise modules can be mounted as custom addons, so confirm licensing and the addon path with Odoo before rollout.
- Image lifecycle: The team must track image tags and rebuild after updates, so confirm which tags match the Odoo versions you intend to run.
- Safer alternative: If no one on the team operates containers day to day, a packaged installer on a supported Linux server is usually simpler to run.
Confirm the image tag, PostgreSQL version and the Enterprise module mounting approach with Odoo before you design the pipeline.
Questions buyers ask before choosing an Odoo install route
How much effort does each Odoo install route take to run?
Effort depends more on what your team brings to the route than on the route itself. Packaged installers need the least manual setup on a supported Linux distribution, and updates arrive through the usual package manager. A source install adds Python and PostgreSQL setup, a service definition and dependency management that your team owns. Docker still needs a separately running PostgreSQL server, a persistent volume for the filestore at /var/lib/odoo and a layout for custom addons at /mnt/extra-addons. Every route carries the same recurring work: operating system patching, keeping PostgreSQL at or above Odoo's stated minimum, backups with tested restores, and applying security updates while a version is in standard support. Setup is mostly one-time effort, and operations are recurring. Ask any partner to size each of these items separately in the written scope.
Can a small team run the Odoo packaged installer itself?
Yes, a small team with Linux administration skills can, once it confirms the platform. Odoo's packaged installers cover Debian-based and RPM-based distributions, and according to the Odoo 19 packaged installers documentation, the deb package currently supports Ubuntu Noble (24.04 LTS) and the rpm package supports Fedora 42. Confirm that your distribution and release are on that list. Confirm also that you can obtain Enterprise packages, which require logging in as a paying on-premise customer or partner. Your team would own the PostgreSQL configuration, the manual wkhtmltopdf install (version 0.12.6 is named for PDF headers and footers), backup schedules, restore tests and a patch routine. Standard support covers three years after a major release, and security updates end when that window closes unless you buy extended support. If those duties exceed your staff time, a fixed-scope engagement can cover them in writing.
Can Odoo Enterprise run in the Docker image?
Yes, but not as an official Enterprise image, because none exists. The Docker Official Image for Odoo is Community-based. Enterprise modules can still run in the container as custom addons: you place the module directories in a host folder and mount that folder so the container loads them from /mnt/extra-addons, alongside your own modules. The container also needs a separately running PostgreSQL server and a persistent volume for the filestore, so data survives container replacement. Before you build this, confirm with Odoo that your subscription covers this on-premise deployment and your user count, because the Enterprise license requires a valid subscription matching the number of users. Your team or partner then owns the image build, the mount layout, module version pinning and a migration test for each new image tag.
Is the Odoo Windows package suitable for a production office?
No. Odoo's packaged installers documentation says Windows packaging is offered for testing or for running single-user local instances, and it states that production deployment is discouraged because of a number of limitations and risks. For an office where several people work in the same database, plan a Linux server running the deb or rpm package, or a source or Docker install on infrastructure you control. Windows fits evaluation, training or one person's local copy. Confirm the specific limitations for your Odoo version with Odoo before you decide. Moving from a Windows evaluation to a Linux production server means migrating the database and filestore, so plan that move and test the restore before go-live. Record the platform decision in your risk register, since reviewers will ask why a platform labeled for testing holds business records.
What does a source install add for developers?
A source install gives developers direct control over the Odoo code tree, the Python environment and the server process. According to the Odoo 19 source installation documentation, running from source is more convenient for module developers, gives greater control over the setup and makes it easier to run several Odoo versions side by side. Odoo 19 requires Python 3.10 or later and PostgreSQL 13 or later, and its AI features need pgvector on PostgreSQL 15 or later. Your team takes on dependency installation, the service definition, log handling and every upgrade step, which recurs with each release. This route suits teams that build custom modules or maintain several versions at once. For one production instance with standard apps, the packaged installer usually leaves less to maintain. Enterprise source code is not publicly available, so an Enterprise source install still depends on subscription access.
How do upgrades differ between packaged, source and Docker installs?
The install route changes the mechanics of an upgrade, but the testing burden stays the same. On packaged installs, updates arrive through the usual apt-get upgrade command, yet a major version still requires a tested database migration. On a source install, your team pulls the new code, updates Python and PostgreSQL dependencies where needed, and runs the migration. On Docker, you move to a new image tag, keep the same volumes and mounted addons, and test the migration on a copy first. Odoo's upgrade service moves a database to a newer supported version through an upgraded test database, and on-premise use requires an Enterprise subscription. The Community edition has no access to that service. Odoo 19 standard support runs until September 2028, according to Odoo's support documentation. Custom module compatibility usually drives most upgrade effort, so ask for each module to be listed in the scope.
What should we ask a partner for in a fixed-scope Odoo install quote?
Ask for a written scope that names the install route, the server or container layout and the exact Odoo version, then check that each line maps to a deliverable. Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, so a quote follows from that scope. Ask the partner to list the operating system and its support status, the Python and PostgreSQL versions for your release, who holds the Enterprise subscription, the custom addons to inventory and test, the wkhtmltopdf handling, backup and restore testing, and the upgrade path after go-live. Also ask what is excluded and whether ongoing support or upgrades run as a retainer. Cost comes from partner labor, your internal staff time and any Odoo subscription fees, which sit outside implementation. Ask which items are one-time and which recur, and confirm the Odoo support window against your go-live date before signing.
How DeployOpen scopes, delivers and supports an Odoo install
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so the install route you pick is set against your servers, network and compliance needs. Engagements run as fixed-scope work with deliverables agreed in writing before any build starts.
How we scope
- Confirm which edition you need, Community or Enterprise, and whether Enterprise packages or subscription codes are already in place.
- Record the target operating system, the PostgreSQL and Python versions you can support, and whether the host is air-gapped or cloud-based.
- Agree in writing whether the install route is a packaged installer, a source install or the Docker image, and why.
How we build
- Provision the PostgreSQL server, Python runtime and filestore paths, and document each version pinned for the chosen route.
- For Docker, separate the database service from the application container, mount custom addons, and keep the filestore on persistent storage.
- Test the install with a restore from backup and a database duplicate with neutralization before any production data is loaded.
How we hand over
- Deliver runbooks covering install, update, backup, restore and the commands used to apply security and bug fix updates.
- Document the route chosen, its known limits, and what must be re-checked at each Odoo major version release.
- Walk your operations and security staff through the handover and confirm who holds the Enterprise subscription and access credentials.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, scoped separately from the install engagement.
- Plan upgrades around Odoo's standard support window so each move lands on a supported version with security updates.
- Ask any support provider to confirm response terms in writing, since DeployOpen does not publish fixed SLAs in this context.
