Skip to content

Documentation / Running Odoo

Managing Services

Start, stop, restart, and manage your Odoo services.

Once a service is created, you can manage its lifecycle directly from the calmo.cloud dashboard.

Starting and stopping #

Start a service #

If a service is stopped, click the Start button on the service page. The container will boot up and Odoo will become accessible at its URL.

Stop a service #

Click Stop to shut down a running service. This stops the container but preserves all data — the database, files, and configuration remain intact. You can start it again at any time.

Restart a service #

Click Restart to stop and immediately start the service. This is useful when:

  • You've installed or updated an addon
  • Odoo seems unresponsive
  • You've changed configuration that requires a restart

Stopping a service does not delete any data. Your database and files are safely preserved.

Deleting a service #

To permanently remove a service:

  1. Open the service you want to delete
  2. Click Delete in the service actions
  3. Confirm the deletion

Deleting a service permanently removes the container, database, and all associated files. Make sure you have a backup before deleting. This action cannot be undone.

Neutralizing a service #

The Neutralize action strips sensitive data from a service. This is useful when you want to create a safe demo or test copy of a production instance — it anonymizes data so real customer information isn't exposed.

Updating the base image #

Each Odoo service is built on a base image. Pulling the latest base image picks up security patches and Odoo updates without changing your service's configuration.

Image pull strategy #

The Image pull strategy setting on the service controls how the base image is kept up to date:

Strategy Behavior
Manual The image is only pulled when you trigger it yourself (default)
Weekly The latest base image is pulled and the service image rebuilt every week
Monthly The latest base image is pulled and the service image rebuilt every month
Quarterly The latest base image is pulled and the service image rebuilt every three months

Automatic pulls only run for running services and are checked once per day.

Pulling manually #

You can trigger a pull at any time, regardless of the strategy:

  • On the service page, open Rerun Steps and click Pull Image
  • In the services list, open the row actions menu and click Pull Image
  • To pull for several services at once, select them in the services list and use the Queue: Pull Image bulk action

Pulling only downloads the latest base image and rebuilds the service image. The running container keeps using the old image until the next Restart or Redeploy — there is no downtime when pulling.

Every pull is recorded in the service's Actions tab and timeline, and the Last image pull column in the services list shows when each service last pulled its image.

Tuning performance #

The Performance section decides how much of its server an Odoo may use. It holds the settings people reach for most often:

Setting What it does
Workers HTTP worker processes. Zero keeps Odoo in threaded mode, which suits small systems.
Cron threads Processes reserved for scheduled actions.
Memory limit (soft) A worker over this limit finishes its request and is then recycled.
Memory limit (hard) A worker over this limit is killed at once. Sized for one heavy request rather than as a multiple of the soft limit: splitting a server between many workers makes each share small, and a share too small kills a large export or a grouped report outright.
CPU time limit Processor time one request may spend.
Real time limit Wall-clock time one request may take. Long imports and reports need room here.
Requests per worker Requests a worker serves before it is recycled.
Database connections Connections one Odoo process may open.

How much a service is offered depends on what kind of service it is. A live system is sized for everything the server has left; a test or demo for around a third of it, and a preview or sandbox for a fifth. A test copy sized like production takes the room production needs, on a server that exists for production — so the first service created no longer decides how much is left for the rest. It is a ceiling on the recommendation only: you can still set any value by hand.

On a server with monitoring enabled, Use recommended values fills the whole section from the hardware the server reports: one worker per half core plus one, two cron threads, and the memory that is actually left for this service — after the operating system's share, after what PostgreSQL reserves and after the other services on the same server have taken theirs. On a small server you may be offered fewer workers than the cores allow, because a worker with too little memory is recycled mid-request. The Database connections value is a slice of the connection limit the server's PostgreSQL accepts.

The block at the top of the section shows that split, so you can see what is left before you raise anything. Database Performance covers the other half of it: how the server's PostgreSQL is sized, and what happens when more is promised than the machine has. Treat the recommendation as a starting point and watch the server metrics afterwards.

These are ordinary Odoo settings and end up in the same configuration file as everything below, so they can also be set through the API as part of extra_config.

Changing them needs a redeploy, and more workers means more memory. Check the server's memory chart before raising them.

Configuring Odoo settings #

The Extra Configuration section allows you to add custom Odoo configuration settings directly to your service. These settings are injected into the Odoo configuration file (.odoorc) when the service starts.

The Odoo configuration file is split into sections, and the Extra Configuration section shows one block per section:

  • Odoo options — the settings Odoo reads for itself, such as workers or limit_time_real. This is the [options] section of the file.
  • Job queue — the settings the queue_job module reads, written to the [queue_job] section.
  • Other section — any other section a module expects, named by you.

Adding configuration #

  1. Open the service you want to configure
  2. Expand the Extra Configuration section (collapsed by default)
  3. Click Add section and pick the block you need
  4. Fill in the settings
  5. Save the changes
  6. Restart the service for the new settings to take effect

Common settings #

The settings under Performance have their own fields; the ones below are typed in as rows.

Setting Description Example
server_wide_modules Modules loaded for every database base,web,queue_job
db_maxconn Database connections per process 64

Changes to configuration settings require a service restart to take effect. Use the Restart button after saving your changes.

Avoid newline characters in configuration values — they are not supported and will cause validation errors.

Running the job queue #

Odoo's queue_job module runs long tasks in the background. It needs three things:

  1. The module has to be available — add the repository that provides it under Addons — and installed in the database.
  2. In Odoo options, list it in server_wide_modules, for example base,web,queue_job. Under Performance, set Workers to at least 1 so the job runner gets its own process.
  3. In the Job queue block, set Channels to the number of jobs that may run at the same time, for example root:2, and set Host to localhost.

root:0 switches the job runner off without removing the configuration.

Configuring settings over the API #

The API writes the same settings as one map, where a key carries the section it belongs to:

{
  "extra_config": {
    "workers": "4",
    "server_wide_modules": "base,web,queue_job",
    "queue_job.channels": "root:2",
    "queue_job.host": "localhost"
  }
}

A key without a prefix belongs to the [options] section. Sending extra_config replaces the whole map, and a running service is redeployed when the settings change.

Viewing live logs #

You can stream the Odoo container logs in real-time directly from the service page. This is useful for debugging issues, monitoring startup behavior, or watching request activity.

How to view logs #

  1. Open a running service
  2. Click the View Logs button in the header
  3. A slide-over panel opens and begins streaming logs in real-time

The log viewer shows both standard output and error output (highlighted in yellow). Logs are streamed live for up to 5 minutes per session. You can close the panel and reopen it at any time to start a new session.

The View Logs button is only available when the service is running.

Viewing actions #

Every operation performed on a service is logged in the Actions tab. Each action shows:

  • The operation that was performed
  • Whether it succeeded or failed
  • When it ran
  • Detailed output (for troubleshooting)

This gives you a complete audit trail of everything that has happened to a service.

Webhooks #

Each service has a unique webhook token that allows external systems to send notifications to calmo.cloud. This is used for:

  • Syncing the list of installed modules
  • Tracking module upgrades
  • Integration with CI/CD pipelines