Multi-instance

Serious work is not done on the site your customers use. Setyenv is built to run on several instances — typically Development, Pre-production and Production — and to move work between them in the two directions that make sense:

• Sync pushes UP. What you built on the lower instance travels to the one above it: the data model, all the administration and the workflows. You compute the difference, read it, and choose line by line what goes.
• Clone pulls DOWN. The instance below refreshes itself from the one above, so you develop against a faithful copy of what is really running.

Nothing travels sideways and nothing travels by surprise: each instance knows exactly one superior, Sync only ever pushes to it, Clone only ever pulls from it, and both are gestures you perform, never a background sync.

For commercial use, only production pays

Your development and pre-production instances are not commercial use: they build and verify the system, they do not run your business. They can therefore run the Community Edition, free and complete, for as long as you like. Only the instance your business actually runs on — production — needs an Enterprise licence.

So a full Dev → Pre → Pro chain costs exactly one licence, for production. If you prefer a key on a lower instance too (to test the licence screen itself, for example), each domain a key is active on counts against the licence's domain limit, like any other. See Community & Enterprise.

WordPress itself never travels

A rule with no exceptions: WordPress core tables are never copied between instances. Not your posts, not your users, not your other plugins' tables. Clone and Sync move what belongs to Setyenv — the data model, the configuration, the records you asked for and the workflows — through the platform's own transports, and they leave the rest of the WordPress installation exactly as it was.

Everything you administer travels, with four exceptions

Clone and Sync carry all the administration of the platform — the data model, roles and groups, applications and modules, forms, dialogs, actions, business rules, UI policies, visibility and view rules, numbering, REST messages and routes, configuration records and workflows — unless you exclude something on purpose. Four things never travel, by construction:

• the event registry and its log;
• the egress allowlist — each instance decides what it may call;
• connections and credentials — OAuth connections and clients, API keys, tokens and secrets;
• the staging configuration itself — the connection and plans that drive the transfer.

What identifies "the same thing" on two instances is its real identity — an entity slug, a role or group slug, an application and module slug, a message key, a workflow's own id — never a row number. A reference from one thing to another travels by that identity and lands on the right row on the other side.

The three pieces

• Connection — how an instance is told who its superior is, and how it authenticates against it.
• Clone — pulling down: what comes by default, and the rules that change it.
• Sync — pushing up: computing the difference and choosing what travels.

All three live under PF Manage → Staging, and they are administrator territory: the platform gates them on schema management, not on being able to edit records.