ffmpeg architecture recommendation

Posted October 23, 2021 145 views
Node.jsDockerDigitalOcean Droplets

I have a basic CRUD web application that allows users to generate images, gifs, videos. The process can take a while since it can generate thousands of images/gifs/videos. Right now, I just execute a Node script in a child process and it works perfectly fine.

However, my traffic is growing and I always get worried when 2+ processes are triggered at the same time.

I’m open to recommendations here, but I would like to execute my Node script from a droplet that I create on-demand and kill when it’s done.

What is the best way to achieve this?

  • Should I create/use a Docker image with ffmpeg and use that to create a droplet? (Does it need to build the image for each droplet created?)
  • Should I create a droplet, take snapshot, then use the snapshot to create my on-demand droplets

Thank you!

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Submit an Answer
1 answer

Since you’re looking for suggestion, here’s mine.

If your users access your application primarily from the desktop browser (preferably Chrome), you may want to offset such image/video/gif generation onto the clients’ devices instead.

Thus, the users generate their own assets on their local device, right in the browser.

That is what I currently do on app . experienceafrica . today. I’m using FFMPEG WASM (web assembly running in browser) which allows the running of all FFMPEG commands (it’s just a port, so same use)

That way, you can save yourself of all the cloud-based architecture complexities, unless doing so is critical to your services.


  • You can save time and resources, and not having to do things in the cloud
  • You offset whatever computational needs to your users


  • Best works in Chrome 92+ (as at in 2021 October. The other browsers are just too unreliable or doesn’t support)
  • Limit of file size possible to process. ShareArrayBuffer has got some limitations.

You gotta weigh your options. In my use case, doing everything in browser on Desktop works.

You may just include warnings/disable the viewing of the application when on mobile or unsupported browser. It’s unfortunate, but Chrome remains the only browser that supports these cutting edge technologies.

  • Thanks for your suggestion! I actually already have an identical client-side architecture :D

    The problem is, I am limited to the user computer resources (memory) and when a user needs to generate thousands of images/gifs/videos it crashes their browser. Which is why I moved this logic to the backend.