Skip to main content

Configuring an instance

Two configurations, not one

Every instance has the configuration you have saved and the configuration its container was actually built with. Antelao stores a snapshot of the second one, and the difference between them is what the Changes page lists.

Saving a change never touches the running instance. Applying it does.

Remote or localagainst prod-1
# odoocli instance config status --instance acme
Remote or localagainst prod-1
# odoocli instance config apply --instance acme

This split exists because the alternative is worse. If saving applied immediately, every edit would be a restart, and a half-finished set of edits would be a half-restarted instance.

Restart is not always enough

Some settings only take effect when the container is recreated, not restarted. Anything that changes a bind mount is in that category, addons paths in particular. Applying a change picks the right action for you; doing it by hand with instance container restart may silently do nothing.

Editing

Remote or localagainst prod-1
# odoocli instance config edit --instance acme

In the Web UI the same settings are on the instance's Configuration tab, grouped the way the wizard groups them.

Where instance configuration is stored

A server keeps instance configuration in one of two places, chosen when you create the server configuration:

SourceMeaning
DatabaseIn the master database. The default
JsonOne JSON file per instance under the instance root
Remote or localagainst prod-1
# odoocli instance config source --instance acme

Configuration is written to exactly one source. Switching is a server-level decision, not a per-instance one.

Exporting and importing

Exporting gives you the instance's configuration as JSON, which is useful for review, for version control, or for building a similar instance elsewhere.

Remote or localagainst prod-1
# odoocli instance config export --instance acme
Remote or localagainst prod-1
# odoocli instance config import --instance acme
Never import a configuration onto an instance that holds live data

An imported configuration brings the source instance's active database name with it. If you import a configuration exported from another instance, the target instance now believes it owns the source's database. Removing the target then attempts to drop the source's live database.

An ownership check is the only thing that stops this. Treat config import as a tool for building a new instance, not for editing an existing one.

Presets

Presets carry a set of defaults for a kind of instance, so that "a production instance" and "a throwaway test instance" do not have to be configured field by field.

Remote or localagainst prod-1
# odoocli instance config preset --instance acme

A preset is mandatory when creating an instance: there is no unnamed default.