Odoo 19 CLI Guide: Command Line Interface, Commands & Usage

The Ergonomic Advantage: How Odoo CLI Simplifies Operations

Odoo’s design philosophy leverages the CLI to remove administrative friction and reduce development cycle overhead. In traditional enterprise frameworks, simple administrative actions such as installing modules, managing databases, generating template schemas, or neutralizing production data frequently require clicking through multi-layered web menus. The CLI completely eliminates this bottleneck.

1. Developer Ergonomics

• Bypassing the Web UI Latency: Instead of entering the Web Client, activating developer mode, navigating to the "Apps" store, clicking update app lists and selecting install/upgrade, a developer can run a single command like ./odoo-bin -d dev_db -u custom_module. This immediately compiles assets, modifies relational schemas and updates views.
• Rapid Scaffold Automation: Setting up folder trees, module manifests, access rules (CSVs), routing models and initial XML structures is tedious and error-prone. The scaffold subcommand creates structurally sound, standard-compliant boilerplate architectures in milliseconds.
• Interactive Data Access: The shell subcommand starts an interactive Python console with a fully initialized environment. This enables developers to test queries, inspect variables, or run ad-hoc scripts using Odoo's core Object-Relational Mapping (ORM) framework directly inside the terminal.

2. System Administrator Ergonomics

• Scriptable Deployments (Infrastructure as Code): Configurations can be easily defined in structured configuration files (odoo.conf) or injected directly via terminal flags. This enables clean multi-worker deployment scripts, container orchestrations and deterministic provisioning.
• Deterministic Database Actions: Large-scale operations such as backing up multi-gigabyte production databases, renaming staging clones, or running database drops often cause HTTP timeouts when executed via a web browser. The db CLI subcommand executes these commands directly on the database using native, safe wrappers.
• Operational Safety Boundaries: Deploying a copy of a production database to a staging server can accidentally trigger automated cron jobs, email real clients, or send test data to live payment processors. The neutralize and obfuscate subcommands secure staging clones with a single execution path.

Architecture of Odoo CLI

The Odoo CLI functions as a central controller routing input parameters, resolving system configuration overrides, spawning connection pools and booting Odoo's Werkzeug WSGI server.

CLI Command References

Starting Odoo without specifying a subcommand defaults to invoking the WSGI daemon wrapper.

• Purpose: Running, updating, or configuring the server runtime.
• Core Flags:
  • -d, --database: Connects directly to the target database.
  • -i, --init: Installs a list of modules on startup (e.g., -i sale,purchase).
  • -u, --update: Upgrades a list of modules, compiling XML structural views and updating Postgres tables (e.g., -u custom_sales). Use -u all to update all modules.
  • --dev=<options>: Enables development tools (e.g., reload to restart on Python file edits, xml to bypass view caching, qweb for template debugging, or all).
  • --stop-after-init: Terminates the process immediately after completing update, installation, or testing tasks.
  • --skip-auto-install: Prevents the auto-installation of optional, transitively dependent modules.

Code Example: Booting with Custom Updates & Live Reloading

# Start server, target "prod_dev", update custom sales app and auto-reload on Python/XML changes
$ ./odoo-bin -c /etc/odoo.conf -d prod_dev -u custom_sales_module --dev=reload,xml

The db subcommands allow system administrators to run Postgres database maintenance tasks directly from the command line, bypassing the slower web database manager (/web/database/manager).

Complete Database Action Commands Registry & Examples:

Operational Shell Walkthrough: Backing up and Restoring a Database

# Step 1: Backup production database with its filestore
$ ./odoo-bin -c /etc/odoo.conf db dump prod_db /var/backups/prod_backup_$(date +%F).zip --format=zip

# Step 2: Restore backup to a staging database with automatic neutralization
$ ./odoo-bin -c /etc/odoo.conf db load staging_db /var/backups/prod_backup_$(date +%F).zip --force --neutralize

The shell command starts an interactive Python console (using your preferred REPL, like ipython, bpython, or ptpython) with your Odoo environment fully initialized. The active database connection is mapped to the standard framework ORM variable env.

• Purpose: Inspecting records, writing ad-hoc scripts, debugging model relationships and running direct bulk updates.
• Command Syntax: ./odoo-bin shell -d <database_name> [-c <config_file>] [--shell-interface=<interface>]

Walkthrough: Launching Shell and Batch Updating Relational Records

To perform a bulk data update on orphaned CRM Leads:

# Launch command in bash:
# ./odoo-bin shell -d my_dev_db --shell-interface=ipython

# --- Python Shell Interface ---
import logging
_logger = logging.getLogger('odoo.shell')

# Search for leads with an empty country field
leads = env['crm.lead'].search([('country_id', '=', False)])
_logger.info(f"Targeting {len(leads)} orphan leads for bulk update.")

# Load the United States country object (database ID reference or xml_id lookup)
us_country = env.ref('base.us')

# Write directly to the database using Odoo's ORM layer
leads.write({'country_id': us_country.id})

# CRITICAL: Commit the transaction changes (Rolls back by default on exit)
env.cr.commit()

print("Relational records committed successfully!")

The module subcommands allow developers to perform module lifecycle actions directly in the database without starting the web server.

• Purpose: Installing, upgrading, or uninstalling modules inside automated deployment routines.
• Command Syntax: ./odoo-bin -d <database_name> module <action> <modules>

# Install inventory and sales applications directly on a staging database
$ ./odoo-bin -d staging_db module install stock,sale

# Symmetrically upgrade custom account modules and force compile XML configurations
$ ./odoo-bin -d staging_db module upgrade custom_invoice_reports,custom_payment_provider

# Completely uninstall legacy custom modules and delete associated database tables
$ ./odoo-bin -d staging_db module uninstall obsolete_app

Securing databases is critical when copying production data to secondary environments. The neutralize and obfuscate subcommands protect customer data and prevent accidents, like sending staging transactional emails to real clients.

• Neutralize Purpose: Instantly disables outgoing email systems (SMTP), deactivates live payment gateways, switches external warehouse APIs to sandbox testing mode and sets enterprise licenses to testing states.
• Obfuscate Purpose: Scrambles sensitive textual information (customer names, emails, phones) within identified database tables while keeping the structural relational integrity intact.

# Neutralize a recently restored database
$ ./odoo-bin neutralize -d restored_dev_db --config=/etc/odoo.conf

# Symmetrically obfuscate contact records using a shared cryptographic key
$ ./odoo-bin obfuscate -d restored_dev_db --pwd=SecretTeamKeyPhrase --pertablecommit -y

The scaffold command accelerates new feature development by generating structured, standard-compliant boilerplate Odoo module templates.

• Purpose: Creating directories, manifests, base python models, views and security files based on Odoo conventions.
• Command Syntax: ./odoo-bin scaffold <module_name> <target_addons_directory>

Execution Walkthrough:

# Create a tracking module named 'project_analytics' in our custom addons folder
$ ./odoo-bin scaffold project_analytics /opt/odoo/custom_addons

This generates a structured directory layout:

project_analytics/
├── __init__.py
├── __manifest__.py
├── controllers/
│   ├── __init__.py
│   └── controllers.py
├── models/
│   ├── __init__.py
│   └── models.py
├── views/
│   ├── views.xml
│   └── templates.xml
├── security/
│   └── ir.model.access.csv
└── demo/
    └── demo.xml

outcome:

These subcommands help teams test performance and estimate code footprint overhead.

• Populate: Generates massive volumes of valid mock database records using predefined model generators. This allows developers to test database query speeds, index usage and custom reports under realistic workloads.
• Cloc (Count Lines of Code): Scans directories or databases to count custom lines of code. It automatically filters out white space, documentation comments, test suites and third-party libraries to provide accurate metrics for custom developments.

# Populate the database with mock records (100x scaling factor for partners)
$ ./odoo-bin populate -d performance_db --models=res.partner --factors=100

# Audit custom lines of code inside the custom addons folder
$ ./odoo-bin cloc --path=/opt/odoo/custom_addons --verbose

These commands manage language translations and automate code syntax upgrades during major version migrations.

# Load French translation tables into the database
$ ./odoo-bin -d sandbox_db i18n loadlang fr_FR

# Export translation templates to a standard PO file
$ ./odoo-bin -d sandbox_db i18n export project_analytics -l fr_FR -o /tmp/analytics_fr.po

# Rewrite codebase schemas and Python views to upgrade from Odoo 18.0 to 19.0
$ ./odoo-bin upgrade_code --from=18.0 --to=19.0 --addons-path=/opt/odoo/custom_addons

High-Performance Production Configurations (Multi-processing)

In production environments, Odoo must be configured to run in multi-worker mode to effectively distribute client requests across multiple CPU cores. Setting the --workers option greater than 0 forks Odoo into a multi-process supervisor that manages worker life-cycles.

Real-World Production Startup Shell Execution:

# Run server in multi-processing mode with custom system limits
$ ./odoo-bin -c /etc/odoo.conf \
   --workers=9 \
   --max-cron-threads=2 \
   --limit-memory-soft=2147483648 \
   --limit-memory-hard=2684354560 \
   --limit-time-cpu=360 \
   --limit-time-real=720 \
   --proxy-mode \
   --logfile=/var/log/odoo/odoo_prod.log

Step-by-Step Developer Workflow Integration

Follow this end-to-end command-line workflow to build, debug, test, secure and deploy an Odoo module:

$ ./odoo-bin scaffold asset_tracker /opt/odoo/custom_addons

$ ./odoo-bin -d test_sandbox --addons-path=/opt/odoo/custom_addons -i asset_tracker --dev=reload,xml

# $ ./odoo-bin shell -d test_sandbox
>>> env['asset.tracker.item'].create({'name': 'Server Rack A1', 'cost': 1200.0})
>>> env.cr.commit()

$ ./odoo-bin db duplicate test_sandbox test_staging --neutralize

$ ./odoo-bin -d test_staging --addons-path=/opt/odoo/custom_addons -u asset_tracker --test-enable --stop-after-init

$ ./odoo-bin db dump test_sandbox /tmp/backup.zip --format=zip
$ ./odoo-bin db load staging_diagnostic /tmp/backup.zip --force
$ ./odoo-bin obfuscate -d staging_diagnostic --pwd=SharedSecretKey --pertablecommit -y

Conclusion

The Odoo CLI is a comprehensive suite of tools that simplifies development, automates deployments and makes system maintenance predictable. From module scaffolding and interactive shell debugging to database backups and automated testing, mastering the CLI will greatly improve your daily productivity.

By using configuration files (odoo.conf) and standardizing your CLI commands, you can automate repetitive tasks, catch errors early in CI/CD pipelines and maintain consistency across development, staging and production environments.

Reference: https://www.odoo.com/documentation/19.0/developer/reference/cli.html