Releases Overview
Control when and how configuration changes go live on your site.
What is a release?
A release is a snapshot of your configuration that gets deployed to production.
A release isn't a bundle of "staged edits" — it references a source: a specific config (or an experiment) that it snapshots. Creating a release saves a Draft; deploying it is a separate action.
Why releases?
| Without releases | With releases |
|---|---|
| Changes go live immediately | Control when changes deploy |
| No way to recover a prior state | Copy a previous deployed release to return to it |
| Risky changes | Experiment on a traffic slice first |
| No audit trail | Full history of what was shipped |
There's no one-click rollback button. Returning to a previous known-good state means copying that previous deployed release into a new draft and deploying the copy. See Rolling back.
Release workflow
1. Make changes
Edit your configuration:
- Ad slots
- Layouts
- Demand (Prebid bidders)
- Wrapper → Configs
Your edits live in the config; they don't take effect until a release that references that config is created and deployed.
2. Create a release (Draft)
- Go to Wrapper → Releases
- Click + Release
- Choose the source the release snapshots — your current config, or an experiment
- Add release notes (optional) and save
The release is now a Draft — nothing is live yet.
3. Deploy the release
- In the releases list, find your Draft
- Click the Deploy (rocket) action
- On success the release becomes Deployed and your site starts serving that config
4. Verify
Once the release is deployed:
- Confirm the release shows Deployed in Wrapper → Releases
- Visit your site with
?pbjs_debug=trueappended to the URL - Filter the browser console for AAM — you should see
AAM Processing <N> ad slots on pagereflecting the new config - Watch Dashboard → Monetization over the next few hours for regressions
(window.wrapperTag.appVersion is the wrapper library build version, not your release or config version — it won't change just because you deployed a config change, so don't use it to confirm a release.)
For a wider rollout plan, use Wrapper → Experiments to send a percentage of traffic to the new config first. Anima doesn't have a separate preview URL — the live debug-mode flow plus experiments cover testing.
Release status
Every release carries one of three statuses:
| Status | Meaning |
|---|---|
| Draft | Never attempted deployment — still editable, nothing live |
| Staged | One or more deploy attempts have run but none succeeded — failed build or failed push |
| Deployed | Deploy succeeded; the release is frozen |
There's no current status — a release is only Draft, Staged, or Deployed. What your site actually serves is the most recent successful deployment (the published cache), not a flag on the release. Older Deployed releases stay in the list at status Deployed; to return to one, copy it into a new draft and deploy the copy (see Rolling back).
Common tasks
| Task | Link |
|---|---|
| Deploy changes | Deploying → |
| Rollback | Rolling back → |
| Debug-verify on your site | Wrapper Debugging → |
Quick actions with the AI Assistant
The AI Assistant can handle release chores by request — deploying pending changes, listing what's unreleased, rolling back to the last known-good deployed release, or showing release history — each proposed for your approval first. See the AI Assistant guide.
Best practices
Do
- Add descriptive release notes
- Verify in debug mode (
?pbjs_debug=true) after each deploy - Use an experiment for major changes — roll out to a traffic slice first
- Deploy during low-traffic periods for major changes
- Keep the previous release available for rollback
Don't
- Deploy multiple major changes in one release — harder to isolate if something regresses
- Deploy during peak traffic without a prior experiment