How many workers does Odoo actually need?

CPU cores x 2 + 1 gives you the ceiling, but load determines the right number in practice, since one worker handles roughly 6 concurrent users. On a 4-core server with 30 concurrent users, 5 workers plus a cron thread runs comfortably, as long as RAM keeps up.

Why is workers = 0 the default for the development profile?

Setting workers = 0 runs Odoo in threaded mode: a single process, simpler debugging, and working --dev options. It can't take advantage of multiple cores, though, so it should never be pointed at real users.

What separates limit_memory_soft from limit_memory_hard?

The soft limit waits for a worker to finish its current request, then recycles it gracefully. The hard limit doesn't wait, it kills the worker immediately, even mid-request. Think of the hard limit as the safety net, while the soft limit handles day-to-day memory hygiene.

What does proxy_mode actually do, and when is it needed?

With proxy_mode = True, Odoo trusts the X-Forwarded-* headers sent by your reverse proxy, which lets it see the real client IPs and HTTPS scheme correctly. Turn it on whenever nginx, Apache or Traefik sits in front of Odoo, and leave it off otherwise.

Why does my config say longpolling_port instead of gevent_port?

It's the same port under a new name. When the live-chat/bus worker moved to gevent in Odoo 16, longpolling_port became gevent_port. The tuner picks whichever key matches the version you select, and both default to 8072 anyway.

Is this a substitute for load testing?

No, not on its own. What it gives you is the same starting point an experienced Odoo engineer would sketch out before measuring anything. From there, validate under production-like traffic and let real metrics guide your workers and limits.

Free tool · odoo.conf tuner

odoo.conf Tuner

Feed in your server specs and out comes a production-ready odoo.conf: workers, cron threads, memory and time limits, proxy and database settings included. Every value traces back to Odoo's official deployment guidance. No signup, no email gate.

Odoo version

Deployment profile

CPU cores

Total RAM

Expected concurrent users

This counts people active at once, not your total account list. For a company of 100 employees, that peak usually lands somewhere between 20 and 40.Behind a reverse proxy (nginx, Apache, Traefik) Turns on proxy_mode so Odoo trusts the X-Forwarded headers coming from upstream. You'll need this whenever HTTPS terminates at the proxy rather than at Odoo itself.PostgreSQL runs on the same server Sets aside 25% of RAM for the database and sizes db_maxconn to match 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

Think of this as a starting point rather than a substitute for load testing, so validate it under real traffic and adjust from there.

Backed by real migrations

Numbers like yours, validated on real migrations

These are three engagements where the projection actually turned into operational reality on Odoo, and the full case studies live on the migration service page.

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

Implementation, migration and audit counts span our senior consultants' careers, including work delivered before Octura was founded in 2024. Go-live weeks and retention are measured on Octura engagements.

How the tuner computes your odoo.conf

Every number below follows Odoo's official deployment guidance, the same rules our engineers use on client servers, applied directly to the specs you entered:

Workers: cores x 2 + 1 sets the CPU ceiling, and each worker handles roughly 6 concurrent users. Starting from your expected user demand, the tuner caps that figure at the CPU ceiling minus cron threads, and it never drops below 2 workers for a live deployment.
Memory: a worker typically averages around 325 MB, split between 80% light requests near 150 MB and 20% heavy ones closer to 1 GB. Once 1 GB is set aside for the OS, plus 25% for PostgreSQL if it shares the host, the pool shrinks down until everything fits. limit_memory_soft then divides 85% of the available RAM across processes, and the hard limit sits 25% above that.
Limits and security: production runs with strict time limits (60s CPU / 120s real), list_db turned off, and a nudge to set the master password. Staging and development, by contrast, get relaxed limits so long imports and debugging sessions aren't interrupted.

Note that the tuner only handles the Odoo side of things. For the PostgreSQL side (shared_buffers, work_mem, max_connections), try pgtune

How this calculation is made

The Octura Odoo Worker and Memory Tuner is calculated from the standard Odoo sizing formula, workers = CPU cores × 2 + 1, then reduced by the cron threads your deployment reserves and capped by the RAM actually available, budgeting roughly 325 MB per worker. It returns the odoo.conf worker count and the hard and soft memory limits that fit your server.

Common odoo.conf tuning questions

How many workers does Odoo actually need?
CPU cores x 2 + 1 gives you the ceiling, but load determines the right number in practice, since one worker handles roughly 6 concurrent users. On a 4-core server with 30 concurrent users, 5 workers plus a cron thread runs comfortably, as long as RAM keeps up.
Why is workers = 0 the default for the development profile?
Setting workers = 0 runs Odoo in threaded mode: a single process, simpler debugging, and working --dev options. It can't take advantage of multiple cores, though, so it should never be pointed at real users.
What separates limit_memory_soft from limit_memory_hard?
The soft limit waits for a worker to finish its current request, then recycles it gracefully. The hard limit doesn't wait, it kills the worker immediately, even mid-request. Think of the hard limit as the safety net, while the soft limit handles day-to-day memory hygiene.
What does proxy_mode actually do, and when is it needed?
With proxy_mode = True, Odoo trusts the X-Forwarded-* headers sent by your reverse proxy, which lets it see the real client IPs and HTTPS scheme correctly. Turn it on whenever nginx, Apache or Traefik sits in front of Odoo, and leave it off otherwise.
Why does my config say longpolling_port instead of gevent_port?
It's the same port under a new name. When the live-chat/bus worker moved to gevent in Odoo 16, longpolling_port became gevent_port. The tuner picks whichever key matches the version you select, and both default to 8072 anyway.
Is this a substitute for load testing?
No, not on its own. What it gives you is the same starting point an experienced Odoo engineer would sketch out before measuring anything. From there, validate under production-like traffic and let real metrics guide your workers and limits.