Creating Copies

Creating a copy duplicates an existing Odoo service — including its database and all uploaded files — into a new, independent service. This is one of the most powerful features in calmo.cloud for safely testing changes.

Why create a copy? #

• Test upgrades safely — Try upgrading Odoo or addons on a copy before touching your live system
• Debug issues — Reproduce problems using a mirror of your production data
• Train users — Give team members a realistic environment to practice in
• Client previews — Show clients what changes will look like with their actual data

How to create a copy #

1. Open the source service #

Navigate to the service you want to copy and open its detail page.

2. Click Create Copy #

Click Create Copy at the top of the service's page. The same button is on the service's row in the list and in its Copies tab.

3. Configure the copy #

Choose:

• Neutralize sensitive data — Sanitizes passwords, emails and other sensitive data in the copy (recommended for test environments)
• Obfuscate personal data — Encrypts the personal data in the copy before it comes up, so you can work on it with AI tools. See Obfuscating personal data below
• Server — Select which server to host the copy on. It can be the same server as the source, even while that one is not ready for Odoo, or any other server of your team that is ready for Odoo, for example a dedicated test server. The list is preselected with the source's server for copies (see below); while that server is not ready for Odoo, nothing is preselected and you pick the server yourself.
• Start a coding agent in this copy — Only for teams with coding agents. Turns the dialog into the start of an agent session, see Copies made for a coding agent below

If the chosen server has no memory or database connections left for another copy, the dialog warns you. You can still create the copy, but Odoo on that server may be killed when memory runs out, so pick another server or delete a copy you no longer need.

4. Wait for completion #

calmo.cloud will clone the database and copy all files. You can monitor progress in the Actions tab. A copy on the same server is dumped and loaded locally; a copy on another server is streamed from one server to the other through calmo.cloud, as described under How a copy reaches another server below. The source keeps running while that happens.

Important notes #

• The copy is a snapshot in time — it reflects the state of the original service at the moment the copy was created
• Changes to the copy do not sync back to the original
• The copy gets its own URL, credentials, and hostname
• The copy starts with the source's repositories and their branches, but they are its own from then on: a repository added to the copy, or a branch changed on its Repositories tab, applies to the copy alone, and changes to the source's repositories do not reach the copy. Pull request previews are off on a copy.
• You can delete a copy at any time without affecting the original
• A copy starts with small performance settings of its own (threaded mode, no extra workers), so it does not eat into the room the live system on the same server was sized for. Raise them under Performance if you need to. See Tuning performance.
• A copy takes over its source's backup settings, including whether only the database is backed up, as far as your plan includes them

Copies made for a coding agent #

If coding agents are on for your team and you may start them on the service, Create Copy can start one. Switch on Start a coding agent in this copy, and the dialog becomes the start of an agent session: it asks for the agent's task, repository and model instead of a server and the teams to share the copy with, keeps Neutralize sensitive data switched on, and takes you to the session while the copy is made. Obfuscate personal data stays your choice.

An agent copy is a copy of its own, with its own database and filestore, and it shows up in the service's Copies tab with the type Agent copy. It is made on the service's server for copies, it is not counted by your plan's copy limit, and it stays until you remove it, as described under Releasing. Remove agent copies you are done with: they keep using server resources.

The switch is not offered when you create a copy from a backup.

Emails sent by copies #

A neutralized copy cannot send emails to real people, but you often want to see what it would have sent: an invoice, a reminder, a password reset. The mail catcher keeps those emails for you. It runs once per server and serves every copy, including the agent copies of coding agents, and every preview deployment on it.

Neutralized copies have Catch outgoing emails switched on, and the copy gets a Mails tab that lists every email it sent. Open one to see its sender, recipients, the HTML and text versions and its attachments, which you can download. Delete all empties the copy's mailbox. The tab is visible to people who may edit the service, because caught emails can contain password reset links into the copy.

Servers set up from a provisioning template get the mail catcher automatically. On any other server, switch it on once:

1. Open the server's settings, select the Mail catcher tab and switch it on.
2. On each copy that already exists, switch on Catch outgoing emails and redeploy the copy.

Neutralized copies made after that catch their emails without further steps. Live services never send their emails to the mail catcher. A copy made without neutralizing keeps its own mail servers, so its emails are not caught.

The mail catcher keeps up to 5,000 emails per server for at most 30 days. A copy that sends a mass mailing can push older emails of other copies on the same server out. The mail catcher is included from the Starter plan on. Caught emails can also be read and cleared through the API and by AI assistants.

Obfuscating personal data #

An AI assistant or coding agent that works on a copy sends what it reads to its model provider. An obfuscated copy keeps the names, addresses and conversations of your contacts out of that.

calmo.cloud uses Odoo's own odoo obfuscate for this. It encrypts these values in place with a random password that is thrown away right after, so nobody can turn them back, calmo.cloud included:

• contacts: name, email, phone, address, VAT number, company registry, website and notes
• chatter and emails: subject, body, sender and recipients, and the old and new values of tracked fields
• CRM leads, bank accounts, employees (work and private contact details, identification numbers), applicants, event attendees, mailing contacts and helpdesk tickets, where those apps are installed
• the logins of portal users. Internal users keep their logins, so your team can still sign in

Products, prices, amounts, dates and the structure of your data stay as they are, so the copy still behaves like your system. Obfuscated values show up as long strings starting with odoo_cyph_.

You can obfuscate a copy when you create it, or later with Obfuscate on an existing copy, test or demo service; the service restarts for it. It cannot be undone, and live services cannot be obfuscated.

Once a service is obfuscated it stays that way. Every backup restored into it is obfuscated before the service comes back up. If that fails, the restored database is dropped and the service stays stopped, so the backup's data never becomes reachable. Copies of an obfuscated service are always obfuscated as well.

A server for copies #

A common setup is a production server and a separate test server. Set Server for copies on a service to send everything derived from it there by default: manual copies, preview deployments for pull requests and the agent copies of coding agents are then created on that server instead of next to the production system. Leave it empty to keep copies on the service's own server.

The server for copies must be one of your team's servers that is ready for Odoo. When creating a copy manually you can still pick any other server in the dialog.

Copies on another server are included from the Starter plan on. On Free every copy is created on the service's own server; a server for copies chosen before moving to Free is kept, but only used again once your plan includes it. See Pricing and billing.

How a copy reaches another server #

When the copy is created on a different server than its source, calmo.cloud moves the data the same way it does everything else on your servers: over the SSH connection it already has to each of them. No key is added to any server for this, your servers do not need to reach each other, and the SSH key calmo.cloud uses to manage a server never leaves calmo.cloud.

1. The source's server packs the deployed addons, and later the database dump, into a stream.
2. calmo.cloud pipes that stream straight into the copy's server, which unpacks it into the copy's directory. Nothing is stored on calmo.cloud on the way; the data only passes through.
3. The copy's server loads the dump into its own PostgreSQL and starts the copy.
4. The dump is deleted from the source's server as soon as the transfer ends, whether it succeeded or failed.
5. What arrives is unpacked as files only: calmo.cloud strips anything a service directory has no business holding, and replaces what was at those paths rather than merging into it.

Each transfer is an action on the copy's server, so you can follow it in the copy's Actions tab; the dump step runs on the source's server and is listed there as well.

One at a time. A copy is made from a fresh dump of the service, so only one copy of a service is created at a time: while an earlier one is still being deployed, the Create Copy button is greyed out and the API answers 409. The button is greyed out as well when your plan has no room for another copy. Pull request previews and agent copies are not affected by this, and copies of different services can be made side by side.

For a team with coding agents, the button stays available on a service an agent copy can be made of, whichever of these stops a plain copy. The dialog then only makes an agent copy: Start a coding agent in this copy is on and locked, with a note saying why.

What your servers need: nothing beyond what calmo.cloud needs anyway, that is SSH access to both servers. The source keeps running while the transfer happens. Each step of a copy — the dump, the transfer, the load — may take up to 50 minutes; for a system too large for that, restore a backup on the other server instead.

Copies of shared services #

If the service is shared with other teams, the copy dialog also asks under Share the copy with which partner teams the copy keeps — they keep their roles. A partner team that creates a copy gets one that runs on the hosting team's server for copies and is shared with that partner team alone; a partner team never chooses the server.