in production
Most Creator apps start the same way: one person builds it, and every change goes straight into the app everyone's using. That's fine until the app starts to matter — then a quick edit on a Tuesday afternoon becomes an outage on a Tuesday afternoon. Creator's Environments feature exists for exactly this. The catch is adopting it without tripping over the edges.
Your app now exists three times
Changes only move forward — never back
to Stage at once
in a single publish
across all applications
for testing roles
What you actually get
Environments are Zoho's SDLC framework built into Creator — available on Creator 6 and every paid plan. Your app now exists three times. Development is where all the editing happens; it's the only place the app can be changed. Stage is where you test. Production is where your users live. Changes move in one direction only: Development to Stage, then a staged version to Production.
Creator does a fair bit of the work on the way. Components get marked Added, Modified or Deleted so you can see what's shipping. Dependent components in the same app come along automatically. Pre-publish validation catches duplicate values and field-length violations. And the app locks during a publish, so two people can't collide. Every publish to Stage is saved as a version with per-component detail — a clear record of what shipped.
Note — versioning isn't an authorship log
Audit Trail doesn't run in Development or Stage, so the version history tells you what changed, not who asked for it. Keep your own note of who requested and approved each release — the platform won't record it for you.
Four practices that make it work
1 · Plan your test data before you load anything
Data is isolated per environment, on purpose. Records can't be transferred during a publish or reached from another environment — publishing moves schema and logic, never records, so Development starts empty. The v2.1 API takes an environment header that lets you write records into Development or Stage, and you get five demo users per environment for testing roles.
// Records never move during a publish, so Development and Stage start empty. // Seed test data with the v2.1 API, targeting an environment on the request. // (Illustrative — confirm the exact header/param name against current v2.1 docs.) POST /api/v2.1/<owner>/<app_link_name>/form/<form_link_name> environment: development // or: stage Content-Type: application/json { "data": { "Customer_Name": "Test Traders Pvt Ltd", "Status": "Pending" } }
Watch out — do this first
Suspend schedules and redirect email, SMS and push notifications in both non-production environments before you load a thing. Scheduled workflows really do fire in Development and Stage. Creator gives you those controls for exactly this reason — use them, or your test data starts messaging real customers.
2 · Treat publishing as forward-only
Zoho is blunt about this: published versions can't be rolled back to an earlier one. Recovery means fixing forward through Stage again, so budget a second release window. Publishing to Production also drops the app into Maintenance Mode for a moment.
Take a production backup before every release — but be clear about what it buys you. Restoring creates a new application that you re-link by hand, because two apps can't share a link. It won't bring back integration-field data or portal users. Treat it as data recovery for a bad day, not an undo button.
3 · Make the warnings a team rule
Pre-publish checks come in two kinds. Errors block the publish. Warnings don't. And data loss is only a warning.
Watch out — the platform will let you delete live data
Delete a form in Development, publish that deletion, and the records sitting in that form in the target environment go with it. Creator will happily let you click through. Put it in writing: nobody publishes a component marked Deleted without a second person looking — and never on the same day as a backup you haven't verified.
4 · Decide who publishes, and write it down
Environments are open to super admins, admins, and developers who've been granted environment permissions. When you publish you can notify up to three people, chosen from the app's admins and developers — but those are recipients, not approvers, and a business stakeholder can't even be on the list. Sign-off is an agreement your team makes; the platform doesn't enforce it. So name the person who approves production releases.
Creator gives you the pipeline. The approval step and the deletion rule are on you. The governance is yours to write
What stays in production
Some capabilities don't support environments at all: portal configuration, publish components, backup, Audit Trail, Mobile SDK and datasources. Two matter most. Backup isn't available for Development and Stage, so treat in-progress work there as unbacked — if you'd hate to lose it, publish it. And approval workflows, portal configuration and some data-sharing setups can't be tested outside production; changes to them land straight in front of real users, so sequence those releases with care.
Note — a setup detail that catches teams out
Adding an app to environments removes anyone with the Developer role from it. Re-add them to Development and Stage as part of onboarding, or they'll wonder why the app vanished.
The numbers worth knowing
You may have heard there's a 10-app ceiling. There isn't — and this is a case where the documentation is easy to misread. What's actually documented is that you can add up to 10 applications to environments in one go. That's a batch size, not a cap on how many apps you can run. The limits that genuinely shape release planning are the other ones:
| Limit | Value | Why it matters |
|---|---|---|
| Apps published to Stage | Up to 3 at a time | Caps how many releases you can have in flight together |
| Components per publish | 800 | A very large change set may need splitting across publishes |
| Versions kept in Stage | 30, across all apps | Older staged versions age out — don't rely on Stage as an archive |
| Concurrent publishes | 1 per environment | Publishes serialise; plan release windows so they don't stack up |
| Publish window | 30 minutes | Changes revert if the publish doesn't complete in time |
| "10-app ceiling" | Not a cap | 10 is the batch size for adding apps to environments, not a running limit |
The takeaway
- Environments turn ad-hoc editing into a real release process: marked changes, dependency handling, validation and a versioned record of what shipped.
- Releases only go forward. Back up before every production publish, and plan recovery as a fix-forward release, not an undo.
- Data loss on a deletion is only a warning, not an error — make "no solo publish of a component marked Deleted" a written rule.
- The governance is yours to write. Name the person who approves production releases; the platform won't.
- Start with one app. Enable environments, run a trivial change all the way through, and write down what your team learns — but pilot with an app whose data you can afford to lose, because the exit isn't clean.
Building something that matters on Creator?
Set it up with a real release pipeline from day one — or bring us the app you're scared to edit, and we'll get environments running around it.
Get started with Zoho Creator