Video Streaming Engineer to Build Multi Camera RTMP/RTSP Relay Server (MediaMTX, Linux, AWS)

We are building a video infrastructure layer for a sports technology platform. Cameras are installed at sports venues and need to stream to a central relay server, which then makes each feed available in several formats: RTSP for a third party AI analysis partner, phone friendly live viewing (HLS or WebRTC), and recorded replays stored in cloud storage. We have already designed the full architecture and know exactly what we want built (details below). We need an experienced engineer to implement it, get it running end to end with 2 test cameras, and, most importantly, make the process of adding each new camera as simple and repeatable as possible. This starts as a small MVP but is intended to scale to 100+ cameras across many venues. The single most important goal Adding a new camera should be close to trivial. Ideally we preconfigure a camera with a server address and a unique stream path, plug it in, and it appears on the relay with no manual server side work per camera. We want you to design the naming, authentication, and provisioning so that onboarding camera number 200 is the same effort as camera number 2. If your proposal explains how you would make per camera onboarding effortless, it goes to the top of our list. What we need built A hosted Linux relay server (we plan to start on AWS Lightsail, then move to EC2 for production) running MediaMTX as the core. Specifically: Receive camera streams via RTMP push (our cameras support native RTMP push, H.264). Expose each stream as RTSP so our AI analysis partner can pull it. Expose each stream as HLS and/or WebRTC for phone and browser live viewing over HTTPS. Record individual matches to disk on demand (start/stop, not 24/7 recording of every camera), using FFmpeg with stream copy and no transcoding. Upload completed recordings to cloud storage (Cloudflare R2 preferred, or AWS S3) with automatic expiry/deletion after a set retention window. Per camera authentication so only our real cameras can publish and only authorized consumers can pull. HTTPS handled via Caddy or Nginx as a reverse proxy in front of the live/replay endpoints. Basic health and stream status monitoring so we can see which feeds are live and which have dropped. A recording control detail We do not want to blindly record every camera around the clock. We need a small recording worker (Python, Node, or similar, your recommendation) that starts and stops recording jobs on command via an API call, reads from the local stream, records with FFmpeg stream copy, uploads the file to cloud storage, and cleans up the local copy. The trigger to start/stop will come from our own backend via a simple API or webhook; you are building the worker that responds to those triggers, not our backend logic. Scope boundaries To be clear about what is and is not in scope: we handle all application logic, payments, user accounts, and access rules on our own systems. You are building only the video relay, streaming, recording, and storage layer, plus the small worker that starts/stops recordings on command. You do not need to touch or understand our app backend beyond the simple API contract for triggering recordings. Ideal skills and experience Strong hands on experience with MediaMTX (or very similar, such as Nginx RTMP, SRS, or Ant Media) and a track record of running one in production. Solid FFmpeg knowledge, especially stream copy recording without transcoding. Comfortable with Linux server administration, systemd services, firewalls, and locking down ports. Experience with RTMP, RTSP, HLS, and WebRTC and understanding the tradeoffs between them. AWS (Lightsail/EC2) and cloud object storage (Cloudflare R2 or S3) including lifecycle/expiry rules. HTTPS setup with Caddy or Nginx. Bonus: experience streaming from IP cameras and working with third party AI or computer vision pipelines that consume RTSP. Deliverables A working relay server receiving both test cameras and serving each feed as RTSP, HLS/WebRTC, and on demand recordings uploaded to storage with automatic expiry. Per camera authentication in place. A documented, repeatable procedure for adding a new camera, including the exact publish URL format and any provisioning steps. Clear written documentation and a short handover so our team can operate and extend it. Infrastructure defined as reproducible scripts or config (your approach) rather than undocumented manual steps. To apply Tell us briefly about a similar streaming or relay system you have built, which media server you used and why, and, in one or two sentences, how you would make adding a new camera as simple as possible at scale. Please start your reply with the word "COURTSIDE" so we know you read the full posting.