How to Live Stream a Corporate Town Hall on a VPS (Internal All-Hands Streaming Guide)

Last updated: July 5, 2026 · Reviewed by StreamingVPS.com Engineering Team

Streaming a corporate town hall or all-hands meeting on a VPS means running a self-hosted engine (Wowza, Ant Media, or NGINX-RTMP) that restricts playback to employees only — via IP whitelisting, VPN, or signed tokens — while sizing bandwidth for peak simultaneous viewers, not average headcount. Done right, it costs a fraction of an enterprise webinar platform’s per-attendee pricing and keeps sensitive company announcements off third-party infrastructure entirely.

That’s the short answer. The harder part is getting the access control and bandwidth math right before 3,000 employees hit “join” at 10am and half of them get a spinning wheel instead of the CEO’s face.

\n

Key Takeaways

  • A corporate town hall stream needs three things a public livestream doesn’t: employee-only access control, bandwidth sized for a hard peak (everyone joins within the same 5-minute window), and a fallback path if the primary connection drops mid-meeting.
  • IP whitelisting alone breaks for remote/hybrid employees off the VPN — pair it with token-based authentication (Wowza SecureToken, Ant Media’s JWT Stream Security Filter, or nginx secure_link) so remote staff can watch without opening the stream to the public internet.
  • Budget roughly 1.5-2.5 Mbps per concurrent viewer for 720p-1080p HLS; a 2,000-person all-hands can demand 3+ Gbps of peak egress from a single origin, which is why companies over ~500-1,000 concurrent viewers typically add regional relay VPS instances instead of one giant box.
  • NGINX-RTMP has native allow/deny directives for both publish and play — genuinely simpler for basic IP-based restriction than Wowza or Ant Media’s equivalents, even though it lacks their token-auth and DVR features.
  • Keep the live Q&A/polling layer on a separate process or VPS from the video engine; built-in chat systems commonly start lagging once concurrent participants pass 500, and you don’t want that congestion competing with your video stream for CPU and bandwidth.

What Do You Actually Need to Restrict a Live Stream to Employees Only?

Three mechanisms cover almost every internal-streaming scenario, and most companies end up combining two of them:

IP whitelisting. Wowza Streaming Engine Manager has a Client Restrictions setting under Playback Security that lets you specify “Only allow playback from the following IP addresses” as a comma-separated list, with wildcards allowed for whole octet blocks (per Wowza’s own security documentation). This works well if all employees connect through a known corporate VPN egress IP or office network range. It breaks the moment someone joins from a coffee shop on their personal hotspot.

Token authentication. Wowza’s SecureToken module appends a signed hash and expiry (wowzatokenhash, wowzatokenendtime) to each playback URL, generated server-side by whatever system sent the calendar invite. Ant Media’s equivalent is its JWT-based Stream Security Filter — you configure web.xml under /usr/local/antmedia/webapps/{Application}/WEB-INF/ to require a signed JWT on the playback request (per Ant Media’s stream security docs). Tokens are the right call for remote and hybrid employees who aren’t on a static IP.

NGINX-RTMP’s native access directives. This one surprises people: nginx-rtmp-module ships with allow play, deny play, allow publish, and deny publish directives that work exactly like the standard ngx_http_access_module — no plugin, no extra config file, just IP ranges directly in the rtmp {} block. For a single-office or single-VPN-range company, this is genuinely the fastest engine to lock down.

CORS and embed restrictions matter too. If employees watch through an internal intranet page rather than a direct link, lock down which domains can embed the player. Ant Media’s cors.allowed.origins setting restricts which origins can fetch the stream, and versions 2.5.0+ support contentSecurityPolicyHeaderValue=frame-ancestors 'self' <https://your-intranet-domain>; to stop the stream being iframed elsewhere.

\n
Access control methodWowzaAnt MediaNGINX-RTMP
IP whitelist/blacklistNative (Client Restrictions UI)Via REST API IP filter (API access only, not stream playback)Native (allow/deny directives)
Signed token authSecureToken moduleJWT Stream Security FilterRequires secure_link module + custom config
Embed/CORS restrictionVia reverse proxy or CDN configNative cors.allowed.origins + CSP header (2.5.0+)Via nginx add_header directives
Setup complexity for IP-only restrictionLow (GUI)Medium (config file)Lowest (one directive)

How Much Bandwidth Does a Company-Wide Town Hall Actually Need?

More than most IT teams budget for, because the traffic pattern is nothing like a normal streaming audience. A public stream ramps up gradually; a town hall gets a calendar reminder and 80% of the audience joins inside the same five minutes.

Industry guidance on webinar bandwidth puts per-viewer consumption at roughly 2-3 Mbps for typical webinar-quality video — on the higher end of what you’d plan for HLS at 720p-1080p. In our own testing on a streaming-optimized VPS, a single 1080p HLS rendition at a 3-second segment length runs closer to 1.5-2.5 Mbps per concurrent viewer depending on encoder settings, with the gap explained by bitrate and codec choices rather than the protocol itself.

Do the math for a real company: 2,000 employees, 65% peak attendance (a reasonable target per engagement benchmarks, which put a healthy town hall attendance rate above 70% of invitees), gives you 1,300 concurrent viewers. At 2 Mbps average that’s 2.6 Gbps of peak egress — more than a typical single VPS network interface can sustain cleanly, and enough to saturate a shared uplink even before you count encoding overhead.

Two things reduce this in practice: office employees usually share one LAN connection rather than each pulling a separate stream from your origin (put an on-prem relay or local rebroadcast in large offices), and you rarely need more than one rendition — internal town halls don’t need a full adaptive bitrate ladder the way public-facing content does, since your audience is on managed corporate networks, not mobile data.

Company size (employees)Realistic peak concurrent viewers (65%)Approx. peak egress @ 2 Mbps/viewerRecommended setup
Under 200~130~260 MbpsSingle 4 vCPU / 8 GB VPS, direct HLS
200-1,000~650~1.3 GbpsSingle 8 vCPU / 16 GB VPS with a 2 Gbps+ uplink, or origin + 1 relay
1,000-5,000~3,250~6.5 GbpsOrigin VPS + 2-4 regional relay VPS instances (per office region)
5,000+3,000+6+ GbpsOrigin-edge cluster or a hybrid CDN with signed URLs
\n

Should One VPS Handle a Global Company, or Do You Need Regional Relays?

If your workforce is in one country and mostly on one corporate network, one right-sized VPS with HLS delivery is genuinely enough — this is the same origin-only architecture we cover in our CDN for live streaming guide, just without the public CDN layer since access is restricted anyway.

If employees span multiple continents, a single origin creates two problems: transatlantic or transpacific HLS segment fetches add 150-300ms of extra latency per hop, and every remote office pulls its full bandwidth share across an expensive long-haul link. The fix is the same origin-edge pattern used for public streaming — a small relay VPS in each region (US, EU, APAC) pulling the master stream once from the origin and re-serving it to local employees over local infrastructure. Wowza’s stream repeater or Ant Media’s cluster mode both support this without re-encoding at each hop, since it’s a pure segment relay, not a transcode.

What About Live Q&A and Polling at Scale?

This is where most internal town hall setups fail — not the video, the chat. Research on large virtual events consistently notes that built-in chat and polling systems start lagging once concurrent participants cross roughly 500, with messages arriving out of order or dropping entirely. If your CEO is taking live questions, a stalled Q&A widget is more visible to the room than a slightly soft video bitrate.

Run the interactive layer as its own service — a separate WebSocket process, ideally on its own VPS or at minimum its own port and process group away from the streaming engine — so a spike in question submissions can’t compete with the video stream for CPU cycles or network throughput. Pre-moderate or rate-limit submissions (our chat moderation guide covers the keyword-filter-plus-classifier pattern) so a flood of duplicate questions doesn’t overwhelm whoever’s curating them for the presenter.

RTMP or WebRTC for an Internal Town Hall?

For the standard one-to-many broadcast — leadership presents, employees watch — RTMP ingest transcoded to HLS is the practical default. It’s cheap per viewer, plays natively in every corporate browser without a plugin, and the 6-15 second latency is irrelevant for a one-way announcement.

WebRTC only earns its higher per-viewer server cost when you need genuine two-way interaction: an executive fielding live spoken questions from employees on camera, or a panel discussion with remote participants who need sub-second round-trip latency to avoid talking over each other. Ant Media’s WebRTC stack (see our WebRTC on a VPS guide) handles this well for the presenter/panelist side; keep the broader viewing audience on HLS to control cost.

\n

FAQ

Can employees outside the corporate VPN watch a town hall stream?

Yes, but only if you deliberately allow it — token-based authentication (Wowza SecureToken, Ant Media JWT Stream Security Filter, or nginx secure_link) lets remote and work-from-home employees watch without being on the VPN, while still blocking anyone without a valid token. IP whitelisting alone would lock them out.

How much bandwidth does a 2,000-employee town hall need?

At a conservative 1.5 Mbps per viewer for 720p HLS, 2,000 simultaneous viewers need roughly 3 Gbps of aggregate egress if everyone connects directly to one origin. In practice attendance rarely peaks above 60-70% of headcount at once, and multiple viewers per office share one LAN connection, so real egress is usually far lower — but you still need to size for the peak, not the average.

Do I need a CDN for an internal town hall stream?

For companies under about 500 concurrent viewers on one VPS, a single well-sized origin server with HLS delivery is usually enough. Past that, or if employees are spread across multiple countries, a private relay architecture (regional edge VPS instances pulling from one origin) keeps latency and origin bandwidth manageable without exposing the stream on a public CDN.

Can I run live Q&A and polling on the same VPS as the video stream?

Yes, but treat it as a separate service from the video engine. Run the WebSocket-based chat/polling layer on its own port or process (or a lightweight second VPS) so a spike in Q&A traffic can’t starve the video stream’s CPU or bandwidth, and rate-limit or moderate submissions before they hit the moderator queue.

Is RTMP or WebRTC better for an internal town hall?

RTMP-to-HLS is the more common choice for one-way town hall broadcasts because it scales to thousands of viewers cheaply and every corporate device can play HLS in a browser. WebRTC is worth it only if you need sub-second latency for two-way interaction, such as live executive Q&A where employees speak on camera, since it costs more server resources per viewer.

Get Your Town Hall Off Third-Party Webinar Platforms

Enterprise webinar platforms charge per attendee and put your leadership’s unscripted remarks on someone else’s infrastructure. A pre-installed Wowza, Ant Media, or NGINX-RTMP VPS from StreamingVPS.com gives you the same access control and bandwidth headroom without the per-seat pricing — and the streaming engine is live in 60 seconds, not a multi-week platform onboarding. Check our pricing page or Wowza streaming VPS plans to size a box for your next all-hands.

Leave a Reply

Your email address will not be published. Required fields are marked *