This article is also available in:

How do I duplicate an Odoo instance (build myself a test environment)?

Testing a version upgrade, having a client sign off on a configuration, letting a developer break things safely: in all of these you want a copy of production, not production. Hodiploy duplicates a whole instance in a few clicks.

How to do it

Log in to Hodiploy from your Client Area
On the row of the instance to copy, open the "Actions" menu, then "Duplicate"
Pick the destination: a new instance, or an existing instance that the copy will overwrite
For a new instance, give it a name and an address
Check the options in the "On the copy" section (see below)
Confirm

The copy takes the source instance's configuration (resources, Odoo version, Git repository, email sending settings) and a copy of its database and attachments, in the state they are in at the time of the duplication.

The original instance is not interrupted.

On the Git side

If the repository comes from your connected GitHub account, there is nothing to do: the copy follows the same repository and branch, and redeploys itself on every push
With manual Git (SSH), the SSH key is reused, but each instance needs its own webhook. Hodiploy shows you the URL to add to your repository at duplication time: without it, the copy will not redeploy on its own

In both cases you can change the branch afterwards, from the edit page. That's actually the most common scenario: duplicate production, then switch the copy to the development branch.

What is done to the copy

A copy of production that keeps its scheduled jobs and its real outgoing mail server writes to real customers from a sandbox. Hodiploy takes care of it, and leaves you in control.

Two boxes are ticked by default in the duplication window:

Turn the scheduled jobs off: Odoo's scheduled actions (recurring invoicing, mass mailings, synchronisations) will not fire on the copy. Odoo's own internal housekeeping keeps running
Send the e-mails to MailHog: every outgoing mail goes to your machine's mail catcher, where you can read it. The outgoing mail servers registered in the database are disabled along the way, otherwise they would take precedence over this setting

A third box, unticked by default, anonymises the data: contact names, e-mail addresses, phone numbers and bank details are replaced with dummy values. That is what you want before handing a copy to an outside provider.

With no box to tick and no condition, the copy also loses the source's Odoo Enterprise subscription code and gets a fresh database identifier. Without that, Odoo would see your subscription reported from two databases and flag it as duplicated.

The first two boxes can still be unticked. A copy that really must send mail does exist: untick them knowing what you are doing.

Duplicate, copy into, or restore?

Duplicating creates a new instance from this one, as it is right now. That's what you want for an up-to-date sandbox
Copying into an existing instance overwrites an instance you already have, again with the source's current state. That's what you want to refresh a working environment that is already configured and wired to your repository, instead of creating one more. You choose whether to copy the database, the attachments, or both
Restoring a backup copies the instance as it was on the date of the chosen set. That's what you want to investigate an incident, or to check what a backup contains

A locked instance cannot be overwritten, by anyone. Unlock it first if it really is the one you are aiming at.

What about resources?

The copy consumes CPU and RAM on the same server as the original. Remember to allocate it less power than production, from "Edit", and to delete it once it has served its purpose.

A question about duplicating?

Updated on: 27/08/2026

Was this article helpful?

Thank you!