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 #

In the service actions, click Create Copy.

3. Configure the copy #

Choose:

• Neutralize sensitive data — Sanitizes passwords, emails and other sensitive data in the copy (recommended for test environments)
• Server — Select which server to host the copy on. It can be the same server as the source 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).

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
• You can delete a copy at any time without affecting the original

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 coding-agent sandboxes 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.

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. Pull request previews and coding-agent sandboxes are not affected by this, and copies of different services can be made side by side.

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.