Skip to main content

Staging & Production Environments

Each client deployment has two separate environments: Production and Staging. These environments are entirely independent — they do not share data, Journeys, Cards, participants, or any other configuration.

Production

Production is the live environment that your participants use. All real participant data, Journeys, and Cards live here. This is the environment your mobile app connects to.

Staging

Staging is a separate environment used for two purposes:

  • Testing new Intervengine releases — when we release a new version of the platform, it is deployed to Staging first so you can verify the update before it goes live.
  • Prototyping changes — you can experiment with Journey designs, Card configurations, and other settings without affecting your live participants.

Staging is not a journey builder for Production. It is a testing and prototyping space. Changes made in Staging do not automatically flow to Production.

How Migration Works

Migration only goes in one direction: Production to Staging. We never migrate from Staging to Production.

When a migration is performed:

  • It is a one-off reset of the Staging environment using a copy of Production data.
  • Journey version numbers are reset to 0 in Staging.
  • Production is completely unaffected — version numbers, participant data, and all configuration remain as they were.
  • After the migration, the two environments are independent again. Ongoing changes in one environment are not reflected in the other.
warning

Because migration resets Staging, any in-progress work in Staging will be overwritten. Make sure you have finished testing before requesting a migration.

Applying Changes to Production

If you prototype a Journey or Card change in Staging and want to apply it to Production, you need to manually recreate the change in Production. There is no automated sync or push from Staging to Production.

This is intentional — it ensures that changes to your live environment are deliberate and reviewed, rather than accidentally pushed from a testing space.

Why Version Numbers Differ Between Environments

Because the environments are independent, version numbers will almost always differ. For example, a Journey might be at v56 in Production and v0 in Staging. This is expected — the version numbers are not related to each other.

After a migration from Production to Staging, Staging Journey versions reset to 0 even though Production remains at its current version. Publishing changes in Staging increments from 0 independently of Production.

Summary

  • Production and Staging are completely separate environments.
  • Migration goes Production to Staging only, as a one-off reset.
  • Changes in Staging must be manually applied to Production.
  • Different version numbers between environments are normal and expected.
  • Staging is for testing releases and prototyping, not for building content that automatically transfers to Production.