ODOO4projects
Amsterdam at night — one of the six regions our servers run in

STAGING, IN PLAIN WORDS

Do You Need an Odoo Staging Environment?

An Odoo staging environment is a copy of your live Odoo that you are allowed to break. It carries the same apps, the same settings and a copy of your real data, and it runs on its own, so nothing you do inside it reaches the system your invoices, orders and stock depend on. You install a module — an add-on, a feature you switch on — into the copy, put it through its paces, and if it misbehaves you delete the copy and the business never noticed.

That is a developer's tool. Staging exists for the person who changes Odoo's code and wants to see the change work on real data before it goes near the live system. If you write or edit Odoo modules for a living, it is the right instrument, and you already know what to do with it.

Most people who search for a staging environment are not that person. They run a shop, a workshop or an office, someone told them they need staging before they touch their Odoo, and the honest answer is that they usually do not. The rest of this page covers how staging works, who it is really for, and what to do instead.

The plain definition

What is an Odoo staging environment?

Staging is a second version of your Odoo that stands beside the one your business actually uses. The version customers and staff touch is called production. Staging is a copy of it, with the same applications and configuration and a recent copy of your data, running separately so that a mistake there cannot reach production.

You use it to try something before committing to it. A new module, a changed setting, a small piece of code: you put it into the copy first, see how it behaves with your real products and your real customers, and only then move it across. If it turns out badly, production never saw it.

Staging is somewhere to be wrong without paying for it.

Another vendor's product, stated fairly

How odoo.sh works with staging

odoo.sh is Odoo's own hosting platform, and it has staging built in. A project on odoo.sh is organised into three stages, named exactly Production, Staging and Development, and you move a branch between them. A staging branch is a neutralized duplicate of the production database: it holds your real data, and neutralization switches off the parts that would reach the outside world. Scheduled actions and outgoing email are stopped (mail is caught rather than sent), and payment providers, shipping connectors and Odoo's own paid services are put into test mode. That way you can test on production's data without emailing a customer or charging a real card.

A few facts worth knowing before you plan around it:

  • Staging databases are not backed up automatically. You either take a manual backup or restore a production backup into the staging branch.
  • A staging database is deleted automatically after one month. To keep using the branch, you rebuild it.
  • When you merge staging back into production, only the source code moves across. Database changes you made while testing are not carried over, so a setting you need permanently has to be committed as code or copied by hand.
  • On a trial project, production and every staging branch drop back to the Development stage after 30 days.

The price, from odoo.sh's own pricing page: base hosting starts at $57.80 a month, and Staging environment is a metered line at $14.40 per environment per month. Dedicated hosting is $480.00 a month, workers are $57.60 each per month, and storage is $0.20 per GB per month. That page states the hosting price does not include the Enterprise licence. You reach odoo.sh through Odoo's Custom plan, US$49.00 per user per month billed yearly, or US$61.00 monthly.

That is an accurate picture of a good product. For a team that ships Odoo code, it is a sensible way to work.

Who the tool is built for

Who staging is really for

Staging is for people who change Odoo's code. A developer adding a module, an agency doing a migration, a technical person on staff who has to know a change works before the warehouse opens on Monday. Their job creates the risk staging removes: they are editing the machinery, and a mistake in the machinery is expensive and stays invisible until it is live.

If you have that person, or you are that person, staging is a normal and sensible expense.

For everyone else, the useful question is whether they need staging at all. For most small businesses the answer is no, and the reason is worth spelling out.

The honest answer

Do you need one? For most small businesses, no.

Two things are true of a typical small business, and both point the same way.

The first is how you get a new capability. You do not write a module; you buy one that is already finished and proven. A stock feature, a report, a payment option: it was built and tested by someone else and is already in use at thousands of businesses. You install it and you use it. There is no code of yours to test, because there is no code of yours.

The second is who tests it. If you have anybody technical at all, the usual arrangement is that your developer runs the module on their own machine before it comes near your live system, and hands it over when it already works. That local test does the job staging does, for the change you are actually making.

So the risk staging removes, breaking live data with an untested code change, barely exists in your week. You are not running a code pipeline. You are adding a capability to a business system, and the honest tool for that is smaller than staging: a backup, an install, and a way back if it goes wrong.

The path we recommend first

The simpler way: back up, install, test

There is a lighter version of the same safety net, and it is the one we recommend first.

Everything a staging environment protects against comes down to one fear: that a change breaks your live system and your data goes with it. You can settle that fear directly, on the system you already have, without a second environment to pay for and keep running.

  1. Take a backup. Backups run on your instance already. Before you install anything, take one by hand, so you hold a known-good copy from the moment before the change. Backups run on paid plans: four rotating slots on On the Rise and Powerhouse, one on Side Hustle. The 30-day trial has none. Slots work first-in, first-out, so a new backup overwrites the oldest: a backup is your latest safety copy, not a permanent one. If you are on Side Hustle, check the backup exists before you install, and finish your test before the next scheduled backup replaces it.
  2. Install the module. Modules install from the On the Rise plan upwards, from inside your own Odoo, in one click. On Side Hustle, module installation is not included. Contact support and we will take it from there. You install straight into your live system, which is the point: you want to see it work with your real data.
  3. Test it, for real. Open the module, click through what it does, and run it against your actual products, customers and orders. Ten minutes of real use tells you more than any test environment.
  4. If it does not work, put the backup back. If the module misbehaves, tell us through support and we restore the backup you took; the request is handled by support like any other. Restoring puts the system back to the state it was in when you took the backup. Anything entered since then (orders, invoices, payments) goes back with it, so test at a quiet moment and keep the gap short. On a one-slot plan the backup is only as fresh as the next scheduled run, so finish the test before that replaces it.

The whole sequence is a backup, a click, a look, and, only if you need it, a restore. For a single module that is less work than setting up and maintaining a staging environment, and it happens on the system your staff already use.

When the change is bigger

When it does get complicated, we set up staging for you

Sometimes the change is bigger than a single module.

A version upgrade that moves your whole system to a new Odoo. Several modules arriving at once. A migration where the data itself is being reshaped. A change nobody in the business wants to be the one who risks on the live system. These are the moments where a plain backup and restore is not enough, because you need to see a whole rebuilt system working beside the real one before you commit.

That is a staging environment, and it is exactly the job it was built for. If you reach that moment, tell us. We set up the staging environment for you: the copy, the test data, the place to try the change. You do not need to learn how the branches work, or hold a hosting account somewhere else to get one.

We scope it with you and price it before we start, and we only suggest it when the change is genuinely bigger than a module, not for one app you could install on a backup.

That is the honest split. You install finished modules on a backup; we build you a staging environment the day a small business genuinely needs one.

Straight answers

Frequently asked questions

Do I need a staging environment for my Odoo?

Most small businesses do not. You need one if you change Odoo's code, writing or editing modules or migrating a whole system, and you want to test the change on real data before it goes live. If you add finished modules to a running business system, a backup and a careful test does the job that staging would.

What is an Odoo staging environment?

A copy of your live Odoo, with the same apps and a recent copy of your data, running separately so a mistake in it cannot reach the system your business uses. You try a change in the copy first and move it to the live system only once it works.

How much does an Odoo.sh staging environment cost?

odoo.sh's own pricing page lists base hosting from $57.80 a month and Staging environment as a metered line at $14.40 per environment per month, and states the hosting price does not include the Enterprise licence. odoo.sh is reached through Odoo's Custom plan.

Can I test a new module without a staging environment?

Yes. Take a backup first, install the module into your live Odoo, and try it on your real data. Modules install from the On the Rise plan upwards, in one click. If it misbehaves, the backup you took is what puts the system back.

What happens if a new module breaks my Odoo?

If you took a backup first, tell us through support and we restore it, and your system goes back to the moment of your backup. That is why the backup comes first: it is the safety net that makes a staging environment unnecessary for a single change.

Can you set up a staging environment for me?

Yes. When a change is bigger than one module, a version upgrade, several modules at once, a migration, tell us and we set up the staging environment for you. You do not need a hosting account elsewhere or to learn how staging branches work.

One change, handled properly

Talk to us about your change.

Installing a module: take a backup, click install, and ask us if anything looks wrong. A bigger change: we set up a staging environment for you.

Contact support