Started with a simple FFmpeg script. Worked great for one file. Then came 500 4K videos and suddenly I was the bottleneck.
Hard-coded paths? Check. Teammates couldn't run it? Check. Hours of rendering time? Double check.
We needed to scale – and Supabase turned out to be the secret sauce.
Here's what we built:
- Supabase Storage for all media assets (inputs + outputs) – S3-compatible, no self-hosting headache
- Supabase PostgreSQL + pgmq extension** for job queuing – transactional safety so no two runners grab the same job
- Environment variables for Supabase URL, service keys, bucket names – clean across dev/staging/prod
The magic part: Docker runners that all connect to the same Supabase instance. One command and we went from 1 to 8 parallel transcodes:
docker compose up -d --scale render-runner=8
Supabase handles the concurrency. pgmq ensures atomic job claims. Storage serves the files. Runners just... run.
No more manual panic. No more "it works on my machine." Just boring, reliable scaling.
Full walkthrough with all env vars, Docker setup, and security best practices here:
https://www.ffmpeglab.com/articles/ffmpeg-env-vars-scalable-runners.html
Anyone else using Supabase for media processing? Would love to hear your setup!
#FFmpeg #Supabase #PostgreSQL #DevOps #Scalability #Docker #MediaProcessing
The user describes their journey from a single FFmpeg script to a scalable solution using Supabase. They utilized Supabase Storage for media assets, PostgreSQL with pgmq for job queuing, and Docker for running parallel processes. They share their setup and ask for others' experiences with Supabase for media processing.
egress bomb?
elaborate?