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.
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
Changes are staged — they don't take effect until a release is created.
2. Create release
- Go to Wrapper → Releases
- Click Create Release
- Add release notes (optional)
- Click Deploy
3. Verify
Once the release is live:
- 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 - Confirm
window.wrapperTag.appVersionhas updated - Watch Dashboard → Monetization over the next few hours for regressions
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. Your site serves whichever Deployed release is currently current |
A previously-Deployed release that's no longer current remains in the list with status Deployed — "previous" isn't a separate status. To return to one of those prior releases, 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 AI Assistant
| You say | What happens |
|---|---|
| "Deploy my pending changes" | Creates a draft release from the current config and deploys it |
| "What changes are pending?" | Lists unreleased config edits |
| "Roll back to the previous deployed release" | Copies the last known-good deployed release into a new draft and deploys the copy |
| "Show release history" | Displays past releases with their status and notes |
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