How many workers should Odoo have?

The ceiling is CPU cores x 2 + 1, but the right number is driven by load: one worker serves roughly 6 concurrent users. A 4-core server with 30 concurrent users runs well with 5 workers plus a cron thread, provided RAM allows it.

Why does the development profile set workers = 0?

workers = 0 runs Odoo in threaded mode: one process, easier debugging, working --dev options. It cannot exploit multiple cores and must never serve real users.

What is the difference between limit_memory_soft and limit_memory_hard?

The soft limit recycles a worker gracefully after it finishes its current request. The hard limit kills it immediately mid-request. The hard limit is the safety net; the soft limit does the day-to-day memory hygiene.

What does proxy_mode do and when do I need it?

proxy_mode = True makes Odoo trust X-Forwarded-* headers from your reverse proxy, so real client IPs and HTTPS scheme are seen correctly. Enable it whenever nginx, Apache or Traefik sits in front of Odoo, and only then.

Why does my config say longpolling_port instead of gevent_port?

Same port, renamed. Odoo 16 renamed longpolling_port to gevent_port when the live-chat/bus worker moved to gevent. The tuner emits the right key for the version you pick; both default to 8072.

Is this a substitute for load testing?

No. It gives you the same starting point an experienced Odoo engineer would write down before measuring. Validate under production-like traffic and adjust workers and limits from real metrics.

Free tool · odoo.conf tuner

odoo.conf Tuner

Enter your server specs and get a production-ready odoo.conf: workers, cron threads, memory and time limits, proxy and database settings. Computed from Odoo's official deployment guidance. No signup, no email gate.

Odoo version

Deployment profile

CPU cores

Total RAM

Expected concurrent usersUsers active at the same time, not total accounts. A 100-employee company typically peaks around 20 to 40.Behind a reverse proxy (nginx, Apache, Traefik) Enables proxy_mode so Odoo trusts X-Forwarded headers. Required for HTTPS termination at the proxy.PostgreSQL runs on the same server Reserves 25% of RAM for the database and sizes db_maxconn to the worker pool.

Computed values

HTTP workers5

Cron threads1

Memory limit (soft, per worker)1015 MB

Memory limit (hard, per worker)1268 MB

Estimated use / available RAM1.9 GB / 7 GB

odoo.conf

# odoo.conf generated by the Octura odoo.conf tuner
# https://octurasolutions.com/tools/odoo-conf-tuner
# Odoo 18 | production | 4 CPU cores | 8 GB RAM
# ~25 concurrent users | reverse proxy: yes | PostgreSQL on same host: no

[options]

# ---- Workers ----
workers = 5
# Odoo defaults to 2 cron threads; sized here against the CPU budget.
max_cron_threads = 1
# Recycle cron workers after N seconds (0 disables, Odoo 18+).
limit_time_worker_cron = 0

# ---- Memory limits (per worker, bytes) ----
limit_memory_soft = 1064304640
limit_memory_hard = 1329594368
# The gevent (websocket/longpolling) worker follows the limits above
# by default. Give it its own budget if live chat sessions pile up:
# limit_memory_soft_gevent = 1064304640
# limit_memory_hard_gevent = 1329594368

# ---- Time limits (seconds) ----
limit_time_cpu = 60
limit_time_real = 120
# Cron jobs follow limit_time_real by default (-1); raise it instead
# of the global limit if long batch jobs get killed (0 = no limit).
limit_time_real_cron = -1
limit_request = 65536

# ---- HTTP / proxy ----
# Behind a proxy, bind to loopback so Odoo is not reachable directly.
http_interface = 127.0.0.1
http_port = 8069
gevent_port = 8072
proxy_mode = True
# Let the web server deliver large files (needs matching nginx
# X-Accel-Redirect / apache X-Sendfile config before enabling):
# x_sendfile = True

# ---- Database ----
db_maxconn = 64
# The gevent worker shares db_maxconn by default; cap it separately
# if PostgreSQL connections are tight:
# db_maxconn_gevent = 8
# Point these at your PostgreSQL server:
# db_host = db.internal.example.com
# db_port = 5432
# db_sslmode = require
# db_user = odoo
# db_password = CHANGE-ME

# ---- Logging ----
log_level = info
# logfile = /var/log/odoo/odoo.log   (unset = stdout, fine under systemd/docker)

# ---- Security ----
list_db = False
# Only serve your production database (regex on the db name):
# dbfilter = ^mydb$
# Set a strong master password before going live:
# admin_passwd = CHANGE-ME

# ---- Misc ----
# Hours before transient (wizard) records are vacuumed; default 1.0.
transient_age_limit = 1.0
# data_dir = /var/lib/odoo
# addons_path = /opt/odoo/addons,/opt/odoo/custom-addons

Get a free server review

A starting point, not a substitute for load testing. Validate under real traffic and adjust.

Backed by real migrations

Numbers like yours, validated on real migrations

Three engagements where the projection turned into operational reality on Odoo. Read the full case studies on the migration service page.

ManufacturingV12 → V17
Industrial Manufacturer, Texas
12custom modules ported, zero data lost
DistributionV14 → V18
Wholesale Distributor, Quebec
30%faster page loads after the upgrade
Professional ServicesCE → Enterprise
Consulting Firm, Brussels
0hproduction downtime during cutover

How the tuner computes your odoo.conf

Every value comes from Odoo's official deployment guidance, the same rules our engineers apply on client servers, applied to the specs you enter:

Workers: the CPU ceiling is cores x 2 + 1, and each worker serves roughly 6 concurrent users. The tuner takes your user demand, caps it at the CPU ceiling minus cron threads, and never goes below 2 workers for a served deployment.
Memory: a worker averages about 325 MB (80% light requests at ~150 MB, 20% heavy at ~1 GB). After reserving 1 GB for the OS, and 25% for PostgreSQL when it shares the host, the pool shrinks until it fits. limit_memory_soft splits 85% of available RAM across processes; the hard limit is 25% above it.
Limits and security: production gets strict time limits (60s CPU / 120s real), list_db disabled, and a reminder to set the master password. Staging and development get relaxed limits for long imports and debugging.

The tuner covers the Odoo side only. For the PostgreSQL side (shared_buffers, work_mem, max_connections), use pgtune

odoo.conf tuning, common questions

01How many workers should Odoo have?
The ceiling is CPU cores x 2 + 1, but the right number is driven by load: one worker serves roughly 6 concurrent users. A 4-core server with 30 concurrent users runs well with 5 workers plus a cron thread, provided RAM allows it.
02Why does the development profile set workers = 0?
workers = 0 runs Odoo in threaded mode: one process, easier debugging, working --dev options. It cannot exploit multiple cores and must never serve real users.
03What is the difference between limit_memory_soft and limit_memory_hard?
The soft limit recycles a worker gracefully after it finishes its current request. The hard limit kills it immediately mid-request. The hard limit is the safety net; the soft limit does the day-to-day memory hygiene.
04What does proxy_mode do and when do I need it?
proxy_mode = True makes Odoo trust X-Forwarded-* headers from your reverse proxy, so real client IPs and HTTPS scheme are seen correctly. Enable it whenever nginx, Apache or Traefik sits in front of Odoo, and only then.
05Why does my config say longpolling_port instead of gevent_port?
Same port, renamed. Odoo 16 renamed longpolling_port to gevent_port when the live-chat/bus worker moved to gevent. The tuner emits the right key for the version you pick; both default to 8072.
06Is this a substitute for load testing?
No. It gives you the same starting point an experienced Odoo engineer would write down before measuring. Validate under production-like traffic and adjust workers and limits from real metrics.