Deploying Changes
Push your configuration changes to production. In Anima, configuration edits don't go live on their own — they stage until you create and deploy a release.
When to deploy
Deploy after making changes to:
- Ad slots (new, edited, deleted)
- Layouts (targeting, slots)
- Demand partners (enabled, configured)
- Global settings
All configuration edits — ad slots, layouts, demand seats, wrapper settings — stage until you deploy a release. There are no changes that apply to your live site automatically on save.
How to deploy
Step 1: Review your staged changes
Before releasing, confirm what's changed. A release snapshots a source — your current config (or an experiment) — so open Wrapper → Configs to review the config the release will capture, and you'll know exactly what's going out.
Step 2: Create the release
- Click + Release and choose the source config (or experiment) to snapshot
- Add Release Notes (recommended):
- What changed
- Why it changed
- Any expected impact
Example notes:
Added new in-content slot to article layout.
Increased floor price to $1.25 for sidebar slots.
Step 3: Deploy
- Click Deploy
- Wait for the deploy to complete — config-only changes propagate through the CDN in seconds; a change that rebuilds the wrapper library takes a few minutes
- Confirmation appears when live
Using the AI Assistant
In Operator mode, the assistant can help you stage changes into a release — for example:
- "Draft a release with my pending changes"
It proposes the change and asks for your approval first. You still deploy the release here in the release flow. See the AI Assistant overview for how Operator mode works.
After deploying
Verify deployment
Wrapper config is served from the CDN/API, not your browser cache — a stale local copy is the usual reason a change "didn't deploy":
- Confirm the release shows Deployed in Wrapper → Releases
- Visit your site with a hard reload (or incognito) to bypass any cached config
- In the console, check
window.__wrapp_loader.config_sourceto see where the active config came from (a fresh fetch vs. a cached copy) - Confirm your change is reflected with
?pbjs_debug=true(filter the console for AAM), and watch for errors
Monitor performance
For the first 1-2 hours:
- Watch analytics for anomalies
- Check fill rates and CPM
- Monitor page speed
Deployment timing
Best times to deploy
| Change type | Recommended timing |
|---|---|
| Minor tweaks | Anytime |
| New slots/layouts | Low traffic period |
| Floor changes | Morning (before peak) |
| Major overhaul | Weekend or low-traffic |
Avoid deploying during
- Peak traffic hours (unless urgent)
- Active experiments (may invalidate results)
- Revenue-critical events
Troubleshooting
Deployment stuck
| Check | Solution |
|---|---|
| Network issue | Refresh and retry |
| Large change | Wait a few minutes |
| System issue | Check status page |
Changes not appearing
| Cause | Solution |
|---|---|
| Caching | Hard reload / incognito; check window.__wrapp_loader.config_source; verify deployment status in the portal |
| Deployment pending | Wait for completion |
| Wrong domain | Check domain selector |
Something broke
Don't panic:
- Check browser console for errors
- Compare with previous version
- Rollback if needed
Release notes and preflight
Keep release notes short and specific — what changed and why — so a future rollback is easy to reason about ("Pre-floor-rebalance baseline" beats "update"). That's the whole art; don't overthink the format.
More valuable than the notes is a quick preflight before you deploy:
| Check | Why it matters |
|---|---|
| Blast radius — how many slots / layouts / bidders does this touch? | A one-slot floor tweak is low-risk; a wrapper-config or layout change affects every page. Deploy wide-blast-radius changes during low traffic. |
| One logical change per release | If something regresses, you can tell what caused it — don't bundle a floor change with a new layout. |
| Rollback triggers decided up front | Know what "bad" looks like (revenue or fill down past a threshold after an hour, bootstrap errors in the console) so you roll back on data, not nerves. |
| Verification plan | Which page you'll load with ?pbjs_debug=true, and which dashboard you'll watch, for how long. |
Common questions
How quickly do changes go live?
Usually 1-5 minutes after deployment. CDN propagation may add slight delay for some users.
Can I deploy specific changes only?
No, releases include all pending changes. If you want to deploy selectively, revert unwanted changes before deploying.
What if I deploy a mistake?
There's no one-click rollback. Copy your previous good release forward into a new release and deploy it — see Rolling back.