Site Environment

A Site Environment is an ordered execution and release boundary within a Site. It lets you use one set of Workflow and Connection definitions across development, testing, and production while keeping operational values and published state separate.

New Sites contain two Environments by default: Test and Production. You can add intermediate Environments when your delivery process needs stages such as user acceptance testing or staging.

What is scoped to an Environment

Area Environment-specific behaviour
Connections A Connection's identity is shared across the Site, but its endpoints, credentials, and other Property values are stored separately for each Environment.
Workflow revisions With Release Management enabled, each Environment can run a different published revision of the same Workflow.
API Keys Each API Key belongs to one Environment and authorizes only the Workflows assigned to that key.
Host and browser access The Environment's Host name selects its HTTP and MCP routes. Allowed origins controls which browser origins may call those routes.
Version-control branch When the Site uses GitHub, each Environment has a branch name.

This separation lets a Workflow use test-system credentials and a test revision in one Environment, then production credentials and an approved revision in another.

Environment order

Flowgear assigns each Environment a rank. The order controls authoring and promotion:

  • The first Environment has rank 0. It is the build Environment and is normally named Test. Direct Workflow saves are persisted here.
  • Optional intermediate Environments sit between the first Environment and Production. You can reorder or remove them.
  • The Production Environment is marked as production and remains last. You cannot reorder or remove the first or Production Environment in the Console.

The platform uses rank and the production flag for these roles, not the display name alone. A new intermediate Environment is inserted immediately before Production.

How the active Environment is selected

The Console Environment selector changes the context used by Environment-aware management screens. Published HTTP and MCP requests use the request hostname to select an Environment, and a Sub-Workflow inherits the active Environment from its parent Workflow.

Designer runs, interactive starts, trigger activation, and status controls are runtime-specific. Follow the guide for the Workflow's runtime from Different Ways to Run a Workflow.

Hostname routing

Each Environment that exposes HTTP or MCP Workflows needs a unique hostname within its Site. Flowgear stores hostnames in lowercase. The Console recommends these patterns:

  • Non-production: {customPrefix}-{envName}-{tenantKey}.flowgear.net
  • Production: {customPrefix}-{tenantKey}.flowgear.net

After setting a hostname, create a support ticket to request its DNS entry. Request a controlled update window if you need a custom .flowgear.net domain.

The hostname selects the Environment before Flowgear matches a Workflow route or API Key. The legacy _profile query parameter does not switch the Environment. If an older client still sends _profile, its value must match the Environment already selected by the hostname or the request fails.

Connections and API Keys

Configure each Connection in every Environment where its Workflows will run. Keep non-production endpoints and credentials separate from production values.

Create API Keys in the Environment whose hostname will receive the request. A key from another Environment cannot override hostname routing. For an embedded App, the Cookie-based Key, signed-in user, permitted Workflow, and selected Environment must all agree. For a direct service or standalone App, use a Token-based Key scoped to the target Environment.

Workflow revisions

When Release Management is disabled, saving a Workflow publishes the new revision to all Environments. When Release Management is enabled, a save publishes to the first Environment only. Use Manage releases to promote that revision to each subsequent Environment.

Allowed origins

Allowed origins is a list of browser origins, one per line, that are permitted to call HTTP and MCP routes in the Environment. Enter complete origins such as https://portal.example.com, without a path.

Flowgear always includes the supported Console origins. Leave the field empty when only the Console needs browser access. Use * only when every browser origin is intentionally trusted.

Flowgear creates the CORS response at the Environment boundary. Do not add Access-Control-* headers inside a Workflow. CORS restricts browsers; it does not replace API-key authorization.

Environment-scoped permissions

Enable Environment-scoped permissions enabled under Settings → Site settings when Site users should see only selected Environments.

The administrator who enables the setting receives access to every Environment. Assign Environment access to other users from Settings → Site users. Those permission changes take effect after the affected user signs out and signs in again.

Environment-scoped permissions filter the Environments available in the Console and further restrict user-based API Keys, including Cookie-based and delegated MCP-user keys. They do not replace the user's Site role or the API Key's permitted Workflow list.

Manage Environments

To add or change an Environment:

  1. Open Settings → Site settings.
  2. Under Environments, click New Environment or click Edit on an existing Environment.
  3. Enter the Environment name.
  4. If the Site uses GitHub, enter the required Branch name.
  5. Enter the Host name when the Environment will expose HTTP or MCP Workflows.
  6. Add any required Allowed origins, one per line.
  7. Click Confirm, then save the Site settings.

The edit dialog also displays the read-only Environment key. Environment names are case-sensitive in the Console contract; review integrations that refer to a name before changing it.