Publishing changes – Springcast Pro

"Publishing" is the step that pushes your latest workspace state out to listeners - the RSS feed, the player, and the website - and it can happen automatically after every change or only when you click a button, depending on your workspace setting.

This article covers what "publish" means inside Springcast, when it runs, and how the auto-publish toggle changes the experience.

What "publish" actually does

When Springcast publishes a show, three downstream services are updated:

RSS feed - the XML feed that Apple Podcasts, Spotify, Google Podcasts, and every other podcast app pulls from. Until the RSS feed is regenerated, listening apps see the previous state.
Embed player - the web-based player you can embed on your own site. Until the player is rebuilt, the embed shows the previous state.
Show website - if your workspace publishes a show website through Springcast, it's regenerated.

A publish is per show: the show that changed gets republished, not the entire workspace.

The actual rebuild of each downstream surface happens in the background and usually completes within a minute. The RSS feed update propagates as fast as the listener's podcast app polls for new episodes (typically every 30-60 minutes, sometimes longer).

Auto-publish vs manual - the workspace setting

Each workspace has a single setting that controls publish behaviour: Auto-publish on save (yes / no).

Auto-publish ON

After any edit that affects what listeners hear, Springcast schedules a publish automatically. There's a small coalesce window (about 10 seconds) so a burst of rapid saves doesn't trigger a publish per save - everything within the window collapses into one.

You don't see a "Publish changes" button on the show page because there's nothing to manually click; the system is handling it.

When you save an episode, you'll see a flash like "Saved. Publishing in 10 seconds."

Auto-publish OFF (the default for most workspaces)

The publish doesn't happen automatically. Instead, after any change, the show page shows a Publish changes button. The button stays visible until you click it; clicking it triggers exactly the same publish flow auto-publish would have.

This mode is for workspaces that want explicit control - typically because they're staging several changes (a new episode, marker tweaks, asset swaps) and want to push them all live in one coordinated drop.

You can flip the workspace setting at any time in your workspace settings.

What triggers a publish (or the "Publish changes" button)

Anything that affects what listeners would receive:

Episode edits - title, description, publication date, artwork, source audio upload or delete, any field that ends up in the RSS feed or player.
Marker mutations - adding, editing, or removing a marker on an episode (regardless of whether it's pre/mid/post-roll).
Bulk actions on the Shows page - Apply / Remove / Reset all dirty the affected episodes; once their re-assembly completes, the publish signal fires.
Asset version changes - uploading a new active version re-points campaigns, re-assembles the affected episodes, and signals a publish.
Campaign mutations - creating, updating, pausing, resuming a campaign that ends up changing what audio is in an active episode.
Show settings changes - editing show defaults doesn't republish on its own (it only affects future episodes), but the bulk-action follow-up does.
Re-assembly completion - when Dynamic Content's assembly pipeline produces a new stitched audio file for an episode (or deletes a stale one), it signals a publish so the change reaches listeners.

The unifying rule: if a change is going to affect what a listener downloads next time their app polls, a publish gets queued (or the button appears).

The coalesce window

When auto-publish is on, the system waits ~10 seconds before actually firing the publish. If another save lands in that window, the timer resets. Once 10 seconds elapse with no new saves, the publish runs - just once, with whatever the final state is.

Why: a typical "edit a marker, save, edit another marker, save, edit the description, save" sequence would otherwise queue three publishes back-to-back, each tearing down and rebuilding the RSS feed. Coalescing protects the downstream services and gives the operator a moment to keep editing without paying for it.

You don't see the coalesce window in the UI - it's just a "feels instant" delay between your last save and the publish notification.

The "Publish changes" button (manual mode)

When auto-publish is off, the show page shows a Publish changes button whenever there's something to publish. The button is enabled if any of these is true for the show:

Any episode in the show has unpublished attribute changes (compared to the last published snapshot).
Any episode in the show has been re-assembled by Dynamic Content since the last publish.
The show itself has unpublished attribute changes.

Click the button; the publish runs immediately (no coalesce window in manual mode - you've already decided you want it now). Once it completes, the button disappears and stays hidden until the next change.

After you click - or after auto-publish fires

The publish kicks off three background jobs:

A job to regenerate the RSS feed.
A job to rebuild the embed player.
A job to rebuild the show website (if applicable).

You'll get a flash notification confirming the publish was queued. The jobs complete in the background, usually within a minute. You can keep working on other things; nothing blocks the UI.

If a publish job fails (rare), it shows up in the Job log alongside Dynamic Content assembly jobs.

Common questions

"I edited an episode but the Publish changes button didn't appear (auto-publish off)" - the change probably didn't actually affect listener-facing state. E.g. editing internal notes that don't make it into the RSS feed. If you expected a publish-worthy change and didn't get one, hard-refresh the page; if still nothing, drop a note to support with the specific edit.
"Auto-publish is on but listeners are still hearing the old episode" - the publish reached your RSS feed within ~1 minute, but podcast apps poll on their own cadence. Apple Podcasts can take up to a few hours; Spotify is usually faster. The fastest sanity check is your own embed player URL - that updates as soon as the rebuild completes.
"I'm in manual mode and the button is always there - why?" - probably because something dirtied an episode after the last publish (an assembly job ran, a marker changed). Click Publish to clear it; if it comes back without you doing anything, check the Job log for re-assembly activity.
"Can I publish a specific episode and not the others in the show?" - no. Publish is per-show, all-or-nothing. Behind the scenes, the RSS feed regenerates as one document, so partial publishes aren't possible.
"What if I edit the show while a publish is mid-flight?" - safe. The next publish picks up the latest state. With auto-publish on, the coalesce window handles this naturally. With manual, the button stays visible after the in-flight publish completes, and clicking it queues another one with the latest changes.

Show settings & bulk actions - bulk edits trigger re-assemblies and (eventually) publishes.
Assets - uploading a new version re-points campaigns and signals a publish.
Campaigns - changing a campaign re-assembles the booked episodes and signals a publish.