Environments and publishing

Each banner has a production environment. You can add other environments for testing or staged releases.

An environment stores its slug, production status, published version, and last publish time. Only one environment can be marked as production for a banner.

Manage environments

Open the banner's deployment controls to list its environments. Creating or deleting an environment requires Admin permission for the Banners section. The production environment cannot be deleted.

Environment slugs use lowercase letters, numbers, and hyphens. A slug cannot start or end with a hyphen.

New environments do not have a published version. Until the first publish, the dashboard returns the default bundle URLs for that environment. This avoids handing you an environment URL that has no stored asset.

Publish a snapshot

Publishing to an environment creates a new immutable version from the current banner configuration. The environment then points to that version.

Publishing requires Publish permission for the Banners section and publish access to the selected banner. It is not limited to team owners or administrators.

A publish can stop when the selected compliance mode conflicts with the blocking configuration. Review the mismatch before choosing whether to acknowledge it and continue.

The version pointer is saved before the CDN build runs. If the build fails, the version remains selected and its build status is failed. Publish again after correcting the cause. Do not treat a saved version pointer as proof that the CDN artifact was rebuilt.

Promote between environments

Promotion copies the version already published in a source environment to a target environment. It does not take a new snapshot of the current draft.

The source must have a published version, and that version must still belong to the same banner. Promotion uses the same Publish permission and compliance-mode check as a direct environment publish.

Promoting to production updates the banner's current published version and rebuilds both the production environment bundle and the default production aliases. A failed target build leaves the promoted version selected. The promotion result reports the failure, but the reused version keeps its existing stored build status.

Use the environment bundle

An environment publish writes three assets:

banner/PUBLIC_BANNER_ID/env/ENVIRONMENT_SLUG/latest.js
banner/PUBLIC_BANNER_ID/env/ENVIRONMENT_SLUG/loader.js
banner/PUBLIC_BANNER_ID/env/ENVIRONMENT_SLUG/loader-gtm.js

The production environment also writes the same assets to the default production path:

banner/PUBLIC_BANNER_ID/default/latest.js
banner/PUBLIC_BANNER_ID/default/loader.js
banner/PUBLIC_BANNER_ID/default/loader-gtm.js

The loader is the small bootstrap script. The latest.js file contains the published banner configuration and runtime wrapper.

There is a current exception for non-production environments: the environment-scoped loader files are stored at their environment paths, but the generated loader requests default/latest.js. To exercise a non-production snapshot, load its environment-scoped latest.js directly. Verify the requested URL in the browser network panel before treating an environment test as valid.

Verify a release

1. Confirm the target environment shows the intended version and the publish or promotion returned a built result.
2. Load the exact environment asset you intend to test.
3. Use a private window or clear CookieBeam storage before testing first-visit behavior.
4. Exercise an accept path, a reject path, and preference changes.
5. Check the network panel for the expected environment slug.
6. Promote the tested version to production when it is ready.

Production promotion changes live traffic. A non-production publish does not change the default production aliases.

A version's stored built status can predate a later promotion. Verify the promotion result and the target asset together.