Why FFmpeg Jobs Fail on Heroku and What Developers Can Do About It

Developers running FFmpeg on Heroku frequently encounter silent job failures caused by three core platform constraints. Heroku's dynos use an ephemeral filesystem where all files written to /tmp are wiped on every restart, which occurs at least once every 24 hours, meaning long transcoding jobs can lose their output mid-process. A hard 30-second router timeout on web dynos causes any FFmpeg transcode exceeding that window to be dropped with an H12 error, and the standard fix of offloading work to a queue requires adding Redis, a queue library, and custom worker plumbing. The FFmpeg buildpack also adds around 80MB to the app slug, pushing larger Rails or Next.js applications close to Heroku's 500MB slug size limit. Developers can work around these issues by streaming output directly to S3, using worker dynos with job queues, and building retry logic, though this effectively means maintaining a distributed video pipeline on a platform not designed for it.