Install Odoo with Docker—without mistaking “running” for “production.”

The direct answer: for a disposable but data-persistent test, create a Docker network and two named volumes, run PostgreSQL separately, then run odoo:19.0 with /var/lib/odoo mounted. Visit http://localhost:8069. Before any public deployment, replace the demo-grade credential handling and exposed application port with a hardened Compose or orchestrated design.

Know what this quick start does

• Docker Engine is installed and docker version succeeds for your user.
• Port 8069 is free and reachable only from the trusted test machine or network.
• You understand that named volumes survive container removal but are not off-host backups.
• You choose Odoo 19 deliberately. Never make latest your production version policy.
• You use a generated password rather than the illustrative odoo password in Docker Hub’s simplest example.

These commands follow the official image’s documented mount paths and environment variables, while using a user-defined network instead of the legacy container link in the shortest Docker Hub example. Replace the placeholder password consistently in both containers. Shell history and process metadata can expose command-line secrets, another reason this is a controlled quick start rather than production secret management.

Start PostgreSQL, then Odoo 19

1. Create an isolated network and persistent volumes

docker network create odoo-test
docker volume create odoo-db-data
docker volume create odoo-web-data

The database and filestore are different data sets. PostgreSQL stores records; Odoo stores attachments under its data directory. Losing either can make a restore incomplete.

2. Start a pinned PostgreSQL container

docker run -d \
  --name odoo-db \
  --network odoo-test \
  -v odoo-db-data:/var/lib/postgresql/data \
  -e POSTGRES_DB=postgres \
  -e POSTGRES_USER=odoo \
  -e POSTGRES_PASSWORD='REPLACE_WITH_A_STRONG_PASSWORD' \
  postgres:15

The Odoo image documentation currently demonstrates PostgreSQL 15. Odoo 19’s source documentation requires PostgreSQL 13 or newer. Do not publish port 5432: containers on the private Docker network can communicate without exposing PostgreSQL to the host network.

3. Start the official Odoo 19 image

docker run -d \
  --name odoo-web \
  --network odoo-test \
  -p 127.0.0.1:8069:8069 \
  -v odoo-web-data:/var/lib/odoo \
  -e HOST=odoo-db \
  -e USER=odoo \
  -e PASSWORD='REPLACE_WITH_A_STRONG_PASSWORD' \
  odoo:19.0

Binding to 127.0.0.1 keeps this example local to the host. The image defaults its database host alias to db; because this example names the database odoo-db, HOST is explicit. Odoo’s data mount must match /var/lib/odoo.

4. Inspect logs and create a test database

docker logs odoo-db
docker logs -f odoo-web

When startup completes, open http://localhost:8069. Create a non-sensitive test database. Do not import production personal or financial data into an unreviewed laptop or public test server. Avoid demo data on any internet-facing environment because Odoo warns that it includes default logins and passwords.

Stop, start, inspect, and remove safely

docker stop odoo-web odoo-db
docker start odoo-db
docker start odoo-web
docker ps -a
docker volume ls

Start PostgreSQL before Odoo. Removing containers does not remove named volumes unless you explicitly remove those volumes. That persistence is useful, but accidental volume deletion, host disk failure, ransomware, and operator error still require remote backups.

Before changing an image, capture a coordinated backup, pull the tested target tag, recreate on staging, and verify modules and workflows. Moving between nightly builds within Odoo 19 is an update; moving to Odoo 20 is a major-version migration and cannot be reduced to changing the image tag.

Add configuration and custom addons deliberately

The official image supports mounting a custom configuration directory at /etc/odoo and custom addons at /mnt/extra-addons. Start from the image’s linked configuration template because the container already supplies defaults. Mount configuration read-only where possible, own addon source in version control, and ensure the container can read it.

A custom addon changes your upgrade risk. Verify its Odoo 19 branch, dependency versions, license, security rules, migration plan, and test coverage before installing it. Do not copy Enterprise addons into Community without valid Enterprise access and licensing.

What this two-container example intentionally omits

• HTTPS reverse proxy: public Odoo must use valid HTTPS. Enable proxy_mode only behind the trusted proxy and forward the headers from Odoo’s deployment guide.
• Database restriction: configure a precise dbfilter or db_name, then disable database listing and management with list_db = False / --no-database-list.
• Secret management: do not leave production credentials in shell history, a committed Compose file, or a world-readable environment file.
• Production server mode: the default multi-threaded server, including Docker’s default, is primarily for development and demonstrations. Production uses tuned nonzero workers plus limits based on observed workload.
• Health and limits: add restart policy, health checks, memory/CPU limits, log rotation, disk alerts, certificate monitoring, and tested dependency behavior.
• Updates: pin a tested dated Odoo tag or image digest for reproducibility, track current security/build updates, and promote through staging. Do not deploy latest.

Use the Odoo Docker Compose production guide for architecture and review criteria. Compose makes configuration repeatable; it does not automatically make the configuration secure.

Volumes are persistence, not backups

Back up PostgreSQL with a database-aware process and capture the matching Odoo filestore. Store encrypted copies remotely, outside credentials and deletion access available to the application host. Record the Odoo image digest, custom addons, configuration, and restore order. Regularly restore into an isolated environment and test attachments, logins, reports, scheduled jobs, and key transactions.

Do not expose Docker’s socket, PostgreSQL, or port 8069 publicly. Restrict host SSH to keys, patch the host and Docker runtime, minimize installed services, and separate production from development. Protect the Odoo master password, use strong user authentication, and review logs without leaking credentials or personal data.

Use container state and logs, not repeated reinstalls

• Database connection refused: confirm both containers share odoo-test, HOST=odoo-db, PostgreSQL is ready, and credentials match exactly.
• Permission denied on startup: inspect the mounted path and ownership. Named volumes avoid many host bind-mount permission mismatches.
• Data disappeared: verify the recreated container mounts the original named volumes at the exact documented paths.
• Port already allocated: stop the conflicting service or bind a different local test port, such as 127.0.0.1:8070:8069.
• Odoo starts before PostgreSQL is ready: restart Odoo after the database is healthy; in a maintained stack add a health-aware startup and restart strategy.

Official references

• Docker Official Image for Odoo
• Odoo 19 administration
• Odoo production deployment and security
• Odoo 19 source requirements