It took a single notice. The YouTube channel that held years of a newsroom's
video was gone in one action, and every video embed across the site was suddenly
pointing at something that no longer existed. On a publication that runs video on
most of its articles, that is the kind of morning that empties an archive.
It was a non-event. We changed one setting, the whole site began playing the same
videos from our own storage, and readers never saw a gap. This is the story of why
a deleted channel was a configuration change rather than a catastrophe, and the one
decision, made years earlier, that made the difference.
Platforms can delete you, and you do not get a vote
Channels and accounts get removed for all sorts of reasons, and most of them are
not a fair fight: an automated copyright match against music in the background, a
strike from a report, a policy you did not know had changed, a regional block, an
API quietly deprecated, or an entire product shut down (the internet is littered
with services that were permanent right up until they were not).
The common thread is that the decision is theirs, the timing is theirs, and the
content you put on their platform was never fully in your hands. For a newsroom,
video on a third-party platform is best treated as reach, not as custody.
Publish to platforms, never store on them
The decision that turned the incident into a shrug was made on the very first
upload: every video goes to our own S3 bucket first. The original lives with us.
Pushing a copy out to YouTube, Dailymotion or Vimeo is a distribution step, for
reach and free bandwidth, not the place the file actually lives.
It is the same discipline behind the rest of our media handling: the original is
offloaded to storage we control on upload, and everything downstream is a copy or
a rendition of it. So when a platform pulls a video, or an entire channel, nothing
is actually lost. The master is still sitting in the bucket exactly where it was
put.
One video, four sources
On top of that, each video is a single logical asset with up to four play sources
linked behind it: YouTube, Dailymotion, Vimeo, and Amazon (the file served from
our own S3 through CloudFront).
The important word is source. Where a video plays is a stored setting, not an
embed baked into the post. That one distinction is the whole game. If the player
reads a source field, you can change where every video comes from without editing
a single article. If instead every post contains a literal YouTube iframe,
changing the source later is a database migration under pressure, which is exactly
when you do not want one.
The original lives in S3 and is published out to YouTube, Dailymotion and Vimeo. Where a video actually plays is a stored setting, a site-wide default with a per-video override, so any source can be the active one.
Two dials: site-wide and per video
The source has two levels of control.
Site-wide, you set the default that every video plays from. We ran on YouTube,
because that is where the audience and the bandwidth were.
Per video, you can override that default, and in a newsroom that is not a rare
event. Long videos that carry clips or background music from other sources get
flagged by YouTube's automated Content ID constantly, often even when you hold the
rights, and clearing a strike means filing an appeal and waiting days. So those
videos are set, right there on the upload screen, to play from Dailymotion, Vimeo
or S3 instead, while the rest of the library stays on YouTube. The content most
likely to be struck simply sidesteps the platform that polices it hardest, with no
downtime and no appeal queue.
The site-wide default sets the source for every video at once. A per-video override pins a single clip to another source: the long documentary full of licensed music is set to Vimeo on the upload screen, so it sidesteps the platform most likely to strike it, while everything else stays on the default.
The day the whole channel went
Then the version of the problem you cannot patch one video at a time: the entire
channel was deleted at once. Every video that defaulted to YouTube would fail in
the player, all at the same moment, across the whole archive.
Because the play source was a single site-wide setting, and because every original
was already sitting in S3, the fix was to change the default from YouTube to Amazon
and save. Every embed on the site re-pointed to the S3 copies, served through
CloudFront, in one action. The outage was as long as it takes to change a dropdown.
Compare that to the alternative if YouTube had been the storage rather than a
distribution target: the archive would simply be gone, and the "recovery" would be
re-sourcing and re-uploading thousands of videos that no longer existed.
When the channel was deleted, every video that defaulted to YouTube failed at once. Because the play source is a single site-wide setting and the originals were already in S3, changing the default to Amazon restored the entire archive in one click.
The fallback is not a downgrade
It is worth being clear that playing from your own infrastructure is not a degraded
emergency mode. The S3 source plays through CloudFront like any other CDN-backed
asset. When you want adaptive streaming at scale, you put it in front: an upload
event triggers AWS Elemental MediaConvert to produce HLS renditions, CloudFront
caches the segments, and a standard player streams quality that adapts to each
viewer's connection.
In other words, falling back to your own storage is not making do. For many sites
it is the best source they have. The platforms were the convenience, not the
foundation.
What it is really about: custody
Strip away the specifics and the principle is simple. Own the original, and treat
every external platform as interchangeable reach you opt into, never as the home of
your media. In practice that is three habits:
- Keep the master somewhere you control (for us, S3).
- Make playback a setting, not a hard-coded embed, so the source is a dial.
- Publish to platforms for reach, but never let one become your only copy.
Do that, and platform risk (a strike, a deleted channel, a shut-down service, a
pricing change you cannot stomach) stops being an existential event and becomes a
switch you flip. The same thinking applies anywhere you syndicate: images to a CDN,
articles to third-party readers, audio to podcast directories. Keep the master,
keep the destination swappable.
A two-minute gut check for your own setup
Three questions worth answering honestly:
- If your video platform closed your account tonight, do the originals exist anywhere else? If the only copy is on the platform, that is the first thing to fix, before anything clever.
- Is playback a per-post embed, or a source you can change centrally? If it is baked into content, switching later is a migration, not a setting.
- Do you publish to platforms, or store on them? Publishing is healthy. Storing is the trap.
If the answers make you uncomfortable, you already know where to start.
The bottom line
We keep newsrooms fast and unbreakable on WordPress and AWS, and
this is the resilience side of the same coin as keeping the media pipeline lean:
the originals never leave your control, so neither a platform nor a traffic spike
can take the archive down.
If your video lives on someone else's platform and losing it would hurt,
let's talk.
Top comments (0)