What Is Private Podcast Hosting and How Does It Actually Work?

Podcasts are text files.

That sounds reductive, and it is the most useful thing to understand before you evaluate a single vendor. Once you see what the file does, every design decision in private podcasting stops being mysterious and starts being obvious.

So here is the plumbing, and the four ways companies actually deliver a private show. Then which apps cooperate and which refuse. Then one fact that quietly invalidates a claim you will hear in almost every sales call.

We build these as a podcast production agency, so we have opinions. We have also flagged the places where the whole market declines to document what it does, because those gaps are your best questions for a vendor.

Technical claims here come from published specifications and vendor documentation rather than marketing pages. Where a capability is only asserted in marketing copy, we say so. Where nobody documents the answer, we say that too.

 

How a Podcast Feed Works

Every podcast, public or private, is an RSS feed. That feed is an XML file with one channel and a list of items, one per episode.

Each item carries an enclosure tag with three things: the URL of the audio file, its size in bytes, and its file type. The audio is never inside the feed. It is referenced by address and lives somewhere else, usually on a content network.

Hold onto that, because it has a security consequence most buyers miss.

 

You Have Two Doors to Lock, Not One

The feed and the audio are separate resources at separate addresses. Locking the feed while leaving the MP3 on an open path protects nothing at all. Anyone who sees one episode URL has that episode, feed or no feed.

This is worth asking a vendor directly. Is the audio itself access-controlled, or only the feed? You will learn a lot from how quickly they answer.

 

Apps Pull, Nothing Gets Pushed

There is no notification system in podcasting. Apps poll feeds on their own schedule and notice what changed.

Overcast documents crawling at intervals from a few minutes to 24 hours depending on a show’s popularity, and offers a ping so publishers can trigger a refresh rather than wait. Apple publishes no polling interval at all, so treat any specific number you see for Apple as invented.

One detail matters more than it looks. Several apps fetch feeds centrally from their own servers rather than from the listener’s phone. So suppose a vendor tells you they spot sharing by watching for one feed hit from many locations. Ask how that survives an app that fetches everything from one data center.

 

Nobody Owns the Standard

The tags that make a podcast a podcast come from two places. The iTunes namespace is controlled by Apple and is universal by habit rather than by rule. The Podcasting 2.0 namespace is a community project whose own documentation states plainly that it is not a standards body.

RSS itself is a frozen specification, not an internet standard. None of this is a problem in practice. It is just worth knowing when someone in your IT review asks which standards body governs the format.

 

The Four Ways to Deliver a Private Show

With the plumbing clear, the delivery choice gets easy. There are four doors, and they trade privacy against how pleasant the show is to listen to.

 

Door One: One Feed Per Person

Each listener gets their own feed address, usually a long unguessable token in the URL, sent by email. They add it to whatever podcast app they already use. It behaves like any normal show, offline listening included.

This is the only door with high privacy and high convenience at once. It is also the only one where you can cut off a single person and leave everyone else alone. Someone leaves, you kill their feed, nobody else notices.

It names names, too. Download data maps to a person rather than a crowd. That is the gap between knowing 340 people listened and knowing which 340, which is what lets you report uptake by team.

The cost is upkeep. Somebody has to grant and revoke access. Fine at 40 listeners, and it needs to be automated at 400.

One thing to be clear-eyed about: that token is a bearer credential. Anyone holding the string has the library. It travels in browser history, help-desk tickets and screenshots, which is a different risk from the one people usually worry about.

 

Door Two: One Shared Feed

A single unlisted feed address handed to everybody. Simple to set up, and weak in a way people do not expect.

The risk is not that someone forwards the link. It is that when they do, or when a staff member leaves, your only move is to kill the feed and reissue it to the entire audience. One exit resets everyone.

Call this the Shared Link Leak. It tends to surface about a year in, when the first person with a grudge walks out still subscribed. Shared feeds suit small steady groups under roughly 50 people. Above that, or anywhere churn is normal, the sums stop working.

 

Door Three: An Embedded Player

There is no feed at all. Episodes play inside a player on a page you already control, such as an intranet or a course shell.

Privacy comes free from that page’s existing login, so if the intranet uses single sign-on, so does the audio. No second list to keep.

Convenience drops hard. No subscribing, no offline listening, no alert when an episode lands. This suits audio inside a bigger flow, such as one unit of a course. It fails when the show is meant to become a habit.

 

Door Four: A Locked Microsite

A standalone gated site holding the episodes, with room for transcripts and notes.

This suits an audience outside your systems, such as clients, investors or course members. You get something branded that needs no internal login, with the same convenience penalty as door three.

 

Which Apps Actually Cooperate

Check this before you announce anything internally. It is the most common avoidable launch failure we see.

Tokenized feeds, meaning door one, work broadly. Apple Podcasts takes a manually added feed URL, and so do Overcast, Pocket Casts, Castro, Castbox, Player FM, Podcast Addict and most other independent players.

Feeds protected by a username and password are far more fragile. Pocket Casts describes its support as limited and unofficial, working through credentials placed in the URL. Overcast recognizes such feeds and excludes them from search, and will not accept publisher pings for them. Apple requires feeds submitted to its directory to be publicly reachable, which is a different situation from a listener adding a private URL by hand.

Some large apps do not take gated feeds at all. Spotify, iHeartRadio, Amazon Music and Audible are the names that catch people out. Spotify has a separate entitlement system for this, which is a build rather than a setting.

Call this the Spotify Assumption. A team announces an internal show, then discovers half the staff cannot use the app they actually listen in. Name the working apps in your launch email and the problem disappears.

 

Why Single Sign-On Cannot Protect a Feed

This is the most useful thing in this article for anyone whose IT team will review the plan.

SAML and OIDC work by redirecting a browser to an identity provider, collecting a login, and redirecting back with an assertion. That flow needs a browser.

A podcast app is not a browser. It makes a plain HTTP request for an XML file and expects XML back. There is no screen to show a login page on, no redirect to follow, no session to establish. So single sign-on cannot gate an RSS feed. Not on any platform, in any product, at any price.

When a vendor says their private podcasting is SSO-protected, they mean one of two things. Either they are gating a microsite or an embedded player, which is doors three and four above. Or they have dropped RSS entirely for a dedicated app their users log into.

Both are legitimate. Neither is an SSO-protected podcast feed, and knowing the difference will save you an awkward second meeting.

 

So the Market Splits in Two

Once you see that, the vendor market organizes itself.

One group keeps RSS. Listeners use whatever app they like, identity is basically an email address, and access control is the token in the URL. You get reach and convenience, and a weaker identity story.

The other group drops RSS for a dedicated app with a real login. Now you can have proper single sign-on, directory sync that adds and removes people automatically, device management, and analytics tied to a named account. You give up the thing that made a podcast easy, which is that people listen where they already listen.

Neither is correct in the abstract. If your blocker is that IT will not approve email-based access for sensitive material, the second group solves your problem. If your blocker is that nobody will download another app, the first group does.

 

What This Setup Will Not Do

Before you pick a door, three limits hold on every platform. Any vendor hinting otherwise is overselling.

A downloaded episode is permanent. Once it lands on a phone it is a file on that phone, and no platform can recall it, expire it, or wipe it remotely. Killing a feed stops the next episode and does nothing about the last one. So nothing goes in a private show if a leak would do real harm.

The feed URL is a credential, not a link. Anyone holding that token string has the whole library. The realistic leak is not an attacker, it is a full feed URL pasted into a help-desk ticket that sits in a system with different access rules.

And private is not the same as compliant. A gated feed says nothing about recording consent, employee data rules, retention schedules, or the fact that a transcript is a Level A accessibility requirement rather than an optional extra. Those apply regardless of how tight your access control is.

 

We Audited Eight Platforms. Here Is What They Actually Document.

Marketing pages in this market make confident security claims. Documentation is a different matter, so we went and checked.

In September 2026 we read the public documentation of eight private podcast platforms. Castos, Transistor, Captivate, Podbean Enterprise, Supporting Cast, uStudio, Storyboard and Hello Audio. Help centres, developer docs and pricing pages. We created no accounts and contacted no vendors. We recorded only what a buyer could find without picking up the phone.

For each one we looked for eight things, and separated what appears in documentation from what appears only in marketing copy. Here is what we found.

 

 

The Pattern: Nobody Documents the Token

Seven of eight platforms say nothing at all about what is in a private feed URL or whether it expires. That is the single most consistent silence in this market.

It matters because the feed URL is the credential. If it never expires, a link pasted into a help-desk ticket three years ago still works today.

Two vendors offer manual workarounds that quietly confirm the problem exists. Captivate lets you regenerate a listener’s URL if you suspect sharing. Hello Audio makes the initial subscribe link single-use. Neither is expiry, and neither would be necessary if expiry were standard.

 

Read Encryption Claims Carefully

Podbean’s marketing says private podcasts are “encrypted during transit and stored in encrypted data storage.” That is true, and it is standard practice. It also answers a different question from the one buyers think they are asking.

Encryption in transit and at rest protects the file from interception and from someone reading the storage bucket. It says nothing about whether one listener’s audio URL works when pasted into someone else’s browser. Those are separate controls, and only the second one is about private access.

When you see an encryption claim, ask the follow-up. Is the audio URL itself access-controlled per listener?

 

The SSO Claims Do Not All Line Up

This is where the architecture point from earlier becomes useful in a buying conversation.

Podbean and uStudio both claim single sign-on and both are coherent, because they deliver primarily through their own apps and portals. Podbean names the protocol, names the identity providers, and lists which surfaces SSO covers. uStudio says the same about its enterprise app.

Castos and Supporting Cast both advertise single sign-on while delivering by per-subscriber RSS into ordinary podcast apps. Neither states what the SSO covers. The reasonable reading is that it gates a dashboard or portal login while the feed stays a bearer URL. That is fine. But a buyer cannot tell it from the page.

So ask the question plainly. Does your single sign-on protect the feed, or the website?

 

Two Findings Worth Knowing Before You Shortlist

Castos offers two private modes. Its own documentation says the shared Generic Private RSS feed “cannot be revoked or disabled once it’s shared.” Their marketing elsewhere says revoking a feed removes access instantly. Both are accurate about different products. A buyer who reads only the marketing page will pick the wrong one.

Supporting Cast states that its platform monitors listening and automatically revokes access if content is shared outside the organization. No mechanism is published. That is detection after the fact rather than prevention. And as we noted earlier, several podcast apps fetch feeds from their own servers, which complicates any location-based signal.

 

The Most Honest Pages We Found

Two deserve credit, because candour is rare here.

Hello Audio documents what happens when you block a listener, including the part nobody likes: “Some apps keep the files on their phone if they’ve been downloaded. We can’t remove files from their phone.” That is the truth we opened this article with, stated plainly by a vendor on its own help page.

And uStudio describes its own private RSS option as being for “selective, low-security sharing.” A vendor conceding the limits of its own model is worth more than a page of security adjectives.

 

What to Do With This

Take the seven rows in the table above into your vendor calls and ask them directly. Most of these answers exist internally. They simply are not published.

And apply the same test to us. A provider should be able to say whether their audio URLs are access-controlled, what revocation does to links already issued, and what their SSO actually covers. Anyone who will not is asking you to take security on faith.

This audit is a snapshot of public documentation on 15 September 2026. Vendors update their docs, and a silence today may be a help article next month. If you are reading this much later, check again.

 

What This Costs

Pricing in this market is deliberately unclear, and the shape of it tells you something.

Consumer-grade hosts fold private feeds into plan tiers, sometimes gated behind a subscriber count. Enterprise vendors mostly publish nothing and quote per organization.

That is not evasion so much as a real difference in product. A 40-person onboarding feed and a 4,000-person program with directory sync and named-user reporting are not the same thing, and a flat rate would misprice both. Expect quotes to key off listener count, episode volume, and whether you need provisioning and login integration.

Our own private podcast hosting works the same way, and we would rather scope it on a call than post a number that fits nobody.

Conclusion

A private podcast is a feed with a secret address. Nearly everything else follows from that one sentence.

It explains why per-person feeds are the only ones you can revoke cleanly. It explains why some apps refuse gated feeds. It explains why single sign-on cannot protect one, and why vendors who claim otherwise are describing a different product.

If you are deciding between the four doors, the question that settles it is how often your listener list changes. Steady and small, a shared feed is fine. Anything with normal staff churn, take door one.

If you are weighing this up for a company rather than a personal project, the wider case sits in why every B2B company should have a show. And if you want us to scope the delivery side, our private podcast hosting page is the place to start.