- Starting price
- Free software · hardware and services separate
- Free tier
- Yes
- Platforms
- Raspberry Pi 4 · Debian/Linux · browser control · RTMP output · HLS input
- Developer
- Hai-End Streaming community · Hyas
- Launched
- 2021
- Updated
- Aug 9, 2026
The verdict
Hai-End-Streaming is a rare open-source church broadcast appliance with years of real-world iteration, a non-beta 2.x line, current 2026 maintenance, ready-made Pi images, simple local controls, overlays, RTMP delivery, HLS reception, API automation, and fleet tooling. The software is free and repairable, but it is infrastructure rather than a turnkey audience platform: capture hardware, audio, network, destination accounts, updates, monitoring, access control, copyright, consent, support, and failure recovery remain yours. The backend binds on all interfaces and the reviewed API routes do not show an application authentication dependency, so never expose the control plane directly to the public internet. A church or regional network with a capable technical owner can build an unusually economical, resilient system; an unsupported volunteer team should choose a managed service.
Try Hai-End-Streaming ↗Opens hai-end-streaming.de
Hai-End-Streaming is an open-source appliance for sending and receiving live video at churches and other organizations. A Raspberry Pi captures HDMI, SDI through suitable conversion, an ATEM output, a Pi camera, or certain USB sources; the server encodes H.264 video with AAC audio and sends RTMP to YouTube, an Nginx or Wowza server, the New Apostolic Church IPTV portal, or another compatible destination. It can also receive an HLS stream and display it locally. A browser-based interface and optional physical controls are designed to let a trained volunteer start or stop an established workflow without operating a production workstation.
The project is more than a single encoder script. Its public architecture uses Python, FastAPI, GStreamer, Janus, Vue, a REST API, WebSockets, overlay generation, Prometheus instrumentation, Grafana dashboards, Saltstack automation, and VPN-based remote management. The official site describes a fleet model for hundreds or thousands of devices. Hai-End Streaming Solutions, a related service provider, currently advertises more than 650 devices online and another 700 planned across Europe. The primary project site says Pi-based Mark I units are used at more than 500 locations and documents a 1U Mark II enclosure around a Pi 4 or Compute Module 4.
Version 2.0.0 became the first non-beta release in December 2024 after years of field testing. Version 2.0.1 added Blackmagic ATEM Mini Extreme ISO support; 2.0.2 improved overlays, end-card timing, translations, and platform maintenance; and the current 2.0.3 release from April 2026 fixed Cam Link frame drops and added quality-of-service and frame-drop metrics. The main branch remained active in July and August 2026. That public release history is materially stronger evidence than a landing-page roadmap.
We reviewed the official English and German product pages, specifications, hardware FAQ, user documentation, GitLab project and source, configuration, API routing, release history, license, and provider overview on August 9, 2026. We did not flash an image, assemble a device, connect a camera or mixer, stream to a live destination, receive HLS, test latency or quality, simulate network or power failure, inspect a deployed fleet, run a vulnerability scan, assess supply-chain controls, or audit privacy, accessibility, media licensing, or security. Deployment figures and reliability statements are operator claims unless noted.
✓ The good
- True open-source server - the complete core is publicly maintained under AGPL-3.0-or-later rather than hidden behind an appliance subscription
- Field-shaped design - releases address real capture devices, unstable portals, overlays, frame drops, audio errors, power loss, and remote operation
- Low-cost standard hardware - a Pi 4, storage, power, case, capture adapter, and cables can form a repairable endpoint from widely available parts
- Simple recurring operation - a web interface, automation, and hardware-control path reduce the expertise needed during an ordinary service
- Send and receive roles - RTMP encoding and HLS decoding support both originating a service and displaying a remote feed locally
- Vendor-neutral output - destinations can include YouTube or a church-owned RTMP server rather than one proprietary audience portal
- Fleet-ready components - VPN, Saltstack, Prometheus, Grafana, REST APIs, and centralized support can serve many distributed congregations
- Concrete release evidence - stable 2.0.3 shipped in April 2026 and public development continued through summer 2026
- Repairability and portability - the church can inspect, modify, rebuild, migrate, and keep operating without a per-device software license
✗ Watch out
- Not an end-to-end streaming service - it does not automatically provide audience hosting, CDN delivery, a church site, archives, analytics, chat, or pastoral moderation
- Security is deployment-owned - the backend listens on 0.0.0.0:8080 and reviewed control routes do not visibly enforce application authentication
- Hardware compatibility is specific - capture adapters, firmware, audio devices, cables, power supplies, heat, and USB bandwidth can make or break a build
- Output ceiling is specialized - published specifications describe scaling common input to 720p25 rather than a modern 1080p60 or 4K production target
- One direct camera path - the FAQ says multiple cameras require an external video mixer; the Pi is not a replacement for a switching console
- Documentation is uneven - some English pages retain older planned wording or hardware details while implementation and releases move ahead
- Volunteer operations can be demanding - flashing, configuration, patching, monitoring, backups, spares, diagnostics, and Sunday support need accountable owners
- No service warranty in the free project - uptime, incident response, replacement hardware, and recovery depend on the church or a contracted provider
- Broadcast obligations remain external - consent, minors, copyrighted music, privacy, platform policies, captions, retention, and takedowns are not solved by encoding software
Best for
- Church networks standardizing an inexpensive broadcast or receive appliance across many congregations with central technical support
- Individual churches with Linux and AV competence that want open, inspectable, destination-neutral streaming infrastructure
- Congregations originating a fixed single-program feed from an ATEM, camera, or HDMI source without a full production computer
- Sites receiving a central HLS service and displaying it locally through a dedicated, repairable endpoint
- Organizations able to isolate control networks, automate updates, monitor quality, hold spares, and rehearse failure procedures
Avoid if
- You need a turnkey hosted audience page, CDN, mobile apps, archive, chat, analytics, captions, support SLA, and licensing in one contract
- Nobody owns Linux security, network design, RTMP credentials, hardware compatibility, patching, monitoring, and recovery
- Your required production format is multi-camera 1080p60 or 4K with graphics, replay, recording, redundant encoders, and broadcast switching
- You would expose the web interface, REST API, metrics, or device services to the internet without a secured VPN or authenticated gateway
- Your church cannot maintain consent, safeguarding, copyright and streaming licenses, destination policy, moderation, and retention procedures
What Hai-End-Streaming is
Hai-End-Streaming turns a small Linux computer into a dedicated video endpoint. It discovers configured audio and video inputs, builds a GStreamer pipeline, applies images or text overlays, starts and stops a remote RTMP broadcast, receives HLS for local playback, exposes state to a web UI, and integrates with a portal or management system through APIs. Physical controls can make the routine service workflow appliance-like.
It is not OBS in a tiny box, a multi-camera switcher, a video-hosting destination, a content-delivery network, a streaming license, a privacy program, or guaranteed managed support. External hardware and services still supply the camera mix, sound, internet circuit, RTMP endpoint, audience experience, archive, captions, analytics, and human response.
Why distributed church networks choose Hai-End-Streaming: repeatable endpoints instead of miniature studios
A normal software-encoder workflow asks every congregation to maintain a capable computer, operating system, capture stack, scenes, user accounts, and trained operator. Hai-End narrows the endpoint to a predictable job. Central engineers can produce one tested image and configuration, deploy identical hardware, monitor health, push changes, and let a local volunteer use a browser or button. That separation between fleet engineering and Sunday operation is the real product.
Standardization must be engineered, not assumed. Freeze an approved Pi revision, storage medium, power supply, case, capture device, audio path, cables, firmware, image checksum, and destination profile. Burn in each unit, label every port, keep a configured spare, document replacement, and rehearse manual fallback. Use versioned configuration and change control so a central update cannot break every congregation at once. A pilot cohort should receive releases before the full fleet.
RTMP transmission and HLS reception: a reliable program path, not a production switcher
The server accepts supported HDMI, SDI-converted, analog on older configurations, camera, ATEM, and audio inputs, then uses GStreamer to produce H.264/AAC and publish RTMP. Specifications describe input up to 1080p25 scaled to a 720p25 stream and HLS reception up to 1080p25 for local output. Text and image overlays, hymn content, end cards, restart controls, and hardware-specific fixes have accumulated across releases.
Design the signal chain before buying parts. Confirm camera or mixer output format, HDCP behavior, capture chipset and firmware, frame rate, audio embedding, sample rate, lip sync, gain, mono/stereo routing, cable length, cooling, storage wear, and destination ingest settings. Measure end-to-end delay and dropped frames over the church’s real uplink. Use an external mixer for multiple cameras. Record locally or upstream when an archive matters, because a successful RTMP handshake does not prove the program arrived intact.
Web control, REST API, and overlays: operational simplicity needs network containment
The local Vue interface and FastAPI backend expose stream state, configuration, overlays, system actions, a portal API, and WebSockets. The published server launches on all network interfaces at port 8080, supports broad CORS settings from configuration, and mounts the single-page app with the API. That architecture is convenient for a trusted local network and for automation through a protected portal.
The reviewed API router does not visibly attach an authentication dependency to its streaming, settings, overlay, system, or WebSocket groups. Assume anyone who reaches the service may be able to observe or control it until a current deployment proves otherwise. Place devices on a dedicated VLAN, deny inbound internet access, use a managed VPN or authenticated reverse proxy for remote support, restrict ports by source, protect metrics and overlays, rotate RTMP keys, log administration, disable unused services, and test that a guest Wi-Fi client cannot connect.
Fleet management and monitoring: strong building blocks with a large blast radius
The project describes VPN connectivity, Saltstack configuration, Prometheus metrics, Grafana visibility, portal automation, and remote support for large fleets. Version 2.0.3 added quality-of-service and frame-drop metrics, precisely the signals an operator needs when a remote congregation reports “the stream looked wrong.” A standard appliance also makes inventory, training, and spare replacement easier than supporting arbitrary volunteer laptops.
Central management can turn one mistake into hundreds. Separate development, pilot, and production channels; sign or checksum images and packages; restrict Salt credentials; require peer review; stage rollouts; preserve rollback; alert on offline devices, heat, disk, clock, capture loss, buffer pressure, frame drops, and destination failure; and record who changed what. Do not make production devices dependent on one person, one VPN server, one portal, or one repository. Document offline local operation when central services fail.
Pricing
Streaming Server software
Free
Source, modifications, and distribution are available under AGPL-3.0-or-later. Ready-made Raspberry Pi images and documentation are published by the project.
Receive-only minimum
Hardware cost
The FAQ lists a Pi 4B with 2 GB minimum, 8 GB microSD, 5V/3A USB-C supply, micro-HDMI cable, and optional metal case. It recommends 4 GB and 16 GB for headroom.
Transmit endpoint
Hardware cost + capture
Add a supported capture source. Official examples range from inexpensive Macrosilicon devices to Elgato Cam Link, Blackmagic ATEM products, Pi camera, audio hardware, adapters, and enclosure.
Mark II appliance
Quote or self-build
The documented 1U design combines Pi or CM4, display and switches, Ethernet, audio, SDI/HDMI conversion, and power. Availability and current bill of materials require confirmation.
Managed fleet service
Contact provider
Hai-End Streaming Solutions advertises devices, installation, support, monitoring, lifecycle management, and fleet infrastructure for large deployments. This is distinct from the free community software.
The AGPL software has no subscription or per-device fee. That is meaningful for a network with dozens or hundreds of endpoints and avoids pricing every congregation out of reliable participation.
A bare receive unit can be inexpensive, but transmitting adds capture and audio hardware, cases, displays or buttons, cables, spare media, and sometimes an external switcher. Cheap capture adapters should be tested model by model rather than purchased from a generic listing.
Operational cost includes engineering, imaging, inventory, installation, networking, monitoring, updates, support rotations, spare shipment, platform accounts, CDN or portal capacity, and volunteer training. Free software moves spend; it does not erase it.
A managed service can be economical when internal staffing is absent. Obtain device ownership, software and configuration access, support coverage, replacement time, monitoring scope, security responsibilities, data processing, exit rights, and price changes in writing.
Compare total three-year cost against a managed encoder or church streaming platform, including the value of open repair, destination choice, and fleet scale—not only the initial Pi bill of materials.
Where Hai-End-Streaming falls behind
Publish a current English installation and operations manual aligned with stable 2.0.3, including supported images, checksums, upgrade and rollback, backups, factory recovery, and version compatibility.
Add authenticated administration by default, mandatory credential setup, role separation, CSRF protection, secure sessions, rate limiting, hardened CORS, and clear guidance against public exposure.
Publish a security model, supported-release policy, vulnerability-reporting process, dependency and image provenance, advisories, default ports, firewall profile, secrets handling, and hardening checklist.
Maintain a tested hardware compatibility matrix with exact vendor and USB IDs, firmware, supported formats, audio behavior, known issues, thermal results, and current purchase status.
Document output and recording capabilities precisely: resolution, frame rate, bitrate, keyframes, codecs, latency, local archive, failover destinations, reconnect, buffering, and behavior during portal or network loss.
Publish deployment telemetry with date and definition—online, installed, active, church, endpoint, and geography—rather than mixing 500+, 650+, planned, and third-party counts.
Add operator safeguards such as preview confidence, destination identity, audio meters, countdown, privacy mute, safe stop, local record confirmation, and an obvious degraded-state workflow.
Provide a ministry broadcast checklist for participant consent, minors, prayer and testimony privacy, music and performance licensing, captions, chat, archive retention, takedown, and platform policy.
Hai-End-Streaming vs. OBS Studio vs. a managed church streaming platform
OBS Studio offers a much richer production canvas: multiple scenes and sources, filters, recording, plugins, transitions, and broad encoder control on a general-purpose computer. It also leaves each site with more moving parts and operator choices. Hai-End wins when the input is already a finished program and the goal is a standard one-action endpoint. It sacrifices flexible production for repeatable appliance behavior and central fleet operation.
A managed church platform combines encoder support, cloud delivery, audience pages, archives, analytics, apps, and an SLA, often with proprietary hardware and recurring fees. Hai-End preserves source access, local repair, destination choice, and low marginal software cost but requires the organization to assemble that service layer. Small churches should usually buy support; technically mature networks may gain more from owning the stack. Hybrid deployment—open endpoint plus a managed destination—is often the practical middle.
The bottom line
Hai-End-Streaming is unusually credible for a volunteer-originated church infrastructure project. The code is public under an appropriate network copyleft license, hardware is commodity and repairable, stable 2.0 shipped after a long beta, 2.0.3 addressed actual frame-drop measurement and Cam Link behavior, and ongoing commits show maintenance in 2026. The project also understands the organizational problem: hundreds of churches cannot each operate a bespoke studio, so it separates central engineering from simple local control. Its limitations are equally concrete. A Pi encoder does not supply a CDN, audience site, copyright license, support desk, privacy program, redundant uplink, or skilled sound mix. Published specifications target a modest 720p25 program, and multiple cameras need an upstream switcher. Most importantly, the backend is designed for trusted deployment: it binds to all interfaces and the reviewed API groups do not visibly require application authentication. Place it behind a segmented network and secured VPN, never on a public port. Standardize exact hardware, verify images and updates, protect stream keys, stage fleet changes, monitor quality, keep a hot spare, rehearse fallback, and govern what the camera captures. With those disciplines, Hai-End can be an excellent, economical endpoint. Without them, “one-click” hides operational risk rather than removing it.
Alternatives to Hai-End-Streaming
Frequently asked questions
Is Hai-End-Streaming free?
Yes. The core server is free and open source under AGPL-3.0-or-later. Churches still pay for Raspberry Pi hardware, capture and audio devices, network service, streaming destinations, installation, monitoring, maintenance, and support.
What can Hai-End-Streaming send and receive?
It sends a supported captured program over RTMP using H.264 video and AAC audio and can receive HLS for local playback. The current public specification describes common input up to 1080p25 scaled to 720p25 for transmission.
Can it livestream to YouTube?
Yes. The official site lists YouTube and other RTMP servers as destinations. You must configure and protect the destination URL and stream key and comply with the platform’s account, copyright, privacy, and content rules.
Does it support multiple cameras?
Not as a direct multi-camera production system. The FAQ recommends an external video mixer. A Blackmagic ATEM or similar switcher can create one finished HDMI program for Hai-End to encode.
Is Hai-End-Streaming secure to expose online?
Do not expose it directly. The reviewed server listens on all interfaces and its API router does not visibly attach authentication to the control groups. Use a dedicated VLAN, firewall, secured VPN or gateway, restricted metrics, patched images, and rotated credentials.
What is the current version?
The latest tagged release we found is 2.0.3, published April 2, 2026, with Cam Link frame-drop fixes and QoS metrics. Public main-branch development continued in July and August 2026.
Can a nontechnical volunteer operate it?
Routine operation is intentionally simple through a web panel or configured physical controls. Initial hardware selection, imaging, networking, audio/video testing, security, updates, monitoring, and troubleshooting still require technical ownership.
