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: schema definitions, configuration records and 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.

        Dev  ──────── Sync ────────▶  Pre  ──────── Sync ────────▶  Pro
             ◀─────── Clone ───────        ◀─────── Clone ───────

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.

Instance-local things never travel either, and this is deliberate: secrets, tokens and credentials are excluded by construction, and so are the internal identifiers each instance mints for itself. What identifies "the same thing" on two instances is its real identity — an entity slug, a message key, a workflow's own uid — never a row number.

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.