Environments and releases

ApiGo manages the API lifecycle with an "API source + environment snapshot" model: you maintain a single API source in the workbench, and releasing it generates an independent snapshot in each environment. Each environment can be taken online or offline and rolled back separately without affecting the others.

Environment model

Each project automatically gets two environments at initialization:

Environment code	Name	API prefix	Default address	Production	Description
dev	Development environment	/dev/	http://127.0.0.1:9600	No	The default environment, and the snapshot source for all releases
prod	Production environment	/	Empty	Yes	The public production environment

• Environments belong to projects and are fully isolated between projects.
• dev is the only environment where APIs can be edited, and the snapshot source for cross-environment sync.
• Other environments only receive release snapshots generated by syncing and cannot be edited directly.

Composing the access address

The final path of a release snapshot is composed of "project prefix + environment prefix + API path":

{projectPrefix}{envPrefix}{apiPath}

For example, with project prefix /api/web, environment prefix /dev/ and API path /user/list, the dev snapshot is reachable at /api/web/dev/user/list. Changing an environment prefix affects the access address of every snapshot in that environment, so proceed with care.

Environment configuration

Entry: Service management → Environment configuration.

Environment list

Column	Description
Environment code	Unique environment identifier, such as dev or prod
Environment name	Display name
API prefix	Path segment prepended to the API path
Environment address	Gateway or service address
Bound service	Service name the environment routes to; defaults to apigo-api
Status	Enabled / disabled
Default	Whether it is the default environment
Production	Whether it is marked as the production environment
Access mode	Public / Restricted
Actions	Edit, authorize users

Editable content

In the current version, environments are generated when the project is initialized. The page does not expose "Add environment" or "Delete environment" entries and only supports maintaining existing environments. When editing:

• Environment code, environment name and API prefix cannot be changed after creation;
• Environment address can be changed to point to the actual gateway address;
• Bound service is selected from the service list in the registry; the service list can be refreshed and instances viewed;
• Access mode can be toggled between public and restricted;
• Remarks can be edited.

Access mode and authorization

Mode	Description
Public	All users in the project can see the environment
Restricted	Visible only to the environment creator, administrators and authorized users

"Authorize users" is available only when the access mode is "Restricted", and only the environment creator or an administrator can use it. Authorized users can select the environment in the API list and view release snapshots.

Deletion restrictions (backend rules)

Although the current UI does not expose a delete entry, the backend still enforces constraints on deletion:

• An environment cannot be deleted while it contains APIs;
• The default development environment cannot be deleted;
• The production environment cannot be deleted; clear the production flag first.

Environment constraints

• Environment codes are unique within a project, and API prefixes are unique within a project.
• There can be only one production environment, and it must stay enabled.
• Only enabled non-dev environments appear as targets in the "Sync environment" list.
• The target environment for migration import must be non-production and enabled.

Release snapshots

What happens during a release

After you click "Release" in the workbench, the platform performs these steps in order:

1. Validates the API configuration and the right to use the data source;
2. Sets the API source status to "released" and records the release time;
3. Generates a release snapshot for the dev environment;
4. After the transaction commits, rebuilds the runtime cache and notifies the gateway to refresh API details and routes.

Each release generates a new revision number (deployRevision), which increments within the version family of the same API. Releases do not overwrite historical snapshots; older revisions can still be viewed and rolled back from the version history.

What a snapshot contains

A release snapshot is a complete, read-only copy of the API in that environment. It contains:

• API basics: name, path, method, protocol, authentication method, access level, group, category, description and tags;
• Execution configuration: SQL/script, pagination settings, data source, schema, table name, transaction switch, response timeout, orchestration rules and plugin configuration;
• Parameter snapshot: request parameters, response parameters and sort parameters;
• Proxy configuration: target address, path, timeout, examples and proxy settings;
• Release information: environment, revision number, API version number, snapshot author, snapshot time and online status.

As a result, editing the API source after a release does not affect released snapshots; you must release again to generate a new revision.

Key identifiers

Identifier	Meaning
sourceApiId	API source ID, identical across environments
apiLinkId	Version family link ID that ties multiple versions of the same API together
releaseId	Snapshot ID of a specific release in a specific environment
deployRevision	Revision number, incremented on each release
sourceVersion	API version number, determined by the "Version" field in the API basics
isCurrent	Whether this is the snapshot currently effective in the environment

Cross-environment sync

Only online APIs in the dev environment can be synced to other environments.

Steps

1. In "API list → Released", select the dev environment;
2. Find the target API and click "Sync environment";
3. The dialog shows the current sync status per target environment (API version, revision number, last synced time);
4. Click "Sync" on the target environment row.

Preconditions for syncing

Condition	Message when unmet
The API source is released	Only released APIs can be synced to environments
The target environment exists	Environment does not exist
The target environment is enabled	Target environment is not enabled
The dev snapshot exists	Release first
The data source is readable by the current project	Data source does not exist or the current project is not authorized
Mock is not enabled on the API	The API has Mock data enabled and can only be released to the development environment for integration

Idempotency and snapshot copying

• If the target environment already has the same revision as dev, syncing returns the existing snapshot and creates no new revision.
• If the target environment already has a historical snapshot with that revision, it is made current and the online/offline status is synced.
• Otherwise the current dev snapshot is cloned to the target environment as a new snapshot, and the access path is recalculated.

Syncing only copies snapshot content and does not change the edit state of the API source.

Going online and offline

Development environment

• Operate on the dev row in "API list → Released".
• The API source can be edited only while offline.
• APIs that were never released or whose snapshot was destroyed cannot be taken online directly; release them first.
• If the API source was saved after the snapshot, it cannot be taken online directly; the message "There are modification records; click Release to go online again" appears.
• Taking it online or offline updates the status of the current dev snapshot as well.

Other environments

• Click "Take online / offline" on the corresponding environment row.
• Only the currently effective snapshot can be operated on (isCurrent = 1).
• Before going online, the platform verifies the data source is still accessible.
• Once offline, callers immediately lose access, and the runtime cache is refreshed.

Status and callability

Whether an API is callable depends on both "a current snapshot exists" and "it is online". Releasing without going online, going offline, or deleting the snapshot all cause calls to fail.

History and rollback

Click "History versions" on a non-dev environment row to view all release snapshots of the API in that environment:

Column	Description
Revision	Snapshot revision number
API version	API version number at release time
Current	Whether it is the currently effective snapshot
Synced at	Snapshot generation time
Actions	Roll back

Rollback rules:

• Only non-current snapshots can be rolled back to;
• Rolling back is not supported in the dev environment; release again from the development page;
• Before rolling back, the platform verifies the data source is still accessible;
• Rollback makes the selected snapshot current and marks the other snapshots in the same environment as non-current;
• The runtime cache is refreshed immediately after rollback.

Rollback does not change the dev snapshot or the API source. It only switches which release the target environment currently uses.

Runtime synchronization

Release, sync, going online/offline, rollback and deletion all trigger a runtime refresh:

1. Rebuild API details and routes in Redis;
2. Publish API_DETAIL and ROUTE change notifications;
3. The gateway picks up the latest configuration and applies it.

Administrators can click "Refresh" in the API list to manually re-send a full change notification (API details, routes, flow control, degradation, cache and IP rules), for cache anomalies or reconciliation.

FAQ

Symptom	Cause	Resolution
Clicking Release does nothing or reports a data source error	The data source was deleted or the current project is not authorized	Select an available data source again
The sync environment list is empty	There are no other enabled environments	Check environment configuration and access permissions
Syncing fails with a Mock message	Mock is enabled on the API in dev	Disable all Mock rules and retry
The API in the target environment is not updated	The target revision is already the latest, or you did not sync again	Confirm dev was re-released, then sync again
The online button is disabled	dev was saved without re-releasing	Release again from the workbench
The API is still reachable after going offline	The gateway cache has not refreshed yet	Wait for the notification to take effect; an administrator can refresh manually
The rollback button is grayed out	The selected snapshot is the current one, or you are in dev	Select another historical revision; in dev, release again

Related documentation

• API list
• Versions and migration
• API definition and lifecycle
• Gateway and runtime synchronization