When Docker Is Worth It (and When It’s Not)<\/h2>\n\n\n\n\n![\"\"](\"data:image\/svg+xml;base64,PHN2ZyB3aWR0aD0iMSIgaGVpZ2h0PSIxIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciPjwvc3ZnPg==\")
<\/figure>\n<\/figure>\n\n\n\nBefore spending hours Dockerizing your project, here’s when it actually makes sense.<\/p>\n\n\n\n
Use Docker if:<\/strong><\/p>\n\n\n\n\n- Rendering in production (cloud servers, CI\/CD pipelines, scheduled jobs)<\/li>\n\n\n\n
- Your team uses different OSes (Mac, Windows, Linux) and needs consistency<\/li>\n\n\n\n
- You want to scale horizontally\u2014spin up multiple containers for render queues<\/li>\n\n\n\n
- Deploying to Azure Container Apps, Google Cloud Run, AWS ECS, or similar<\/li>\n\n\n\n
- Need reproducible builds with locked Chrome dependencies<\/li>\n<\/ul>\n\n\n\n
I tested locally vs Docker on Feb 9th. Quality was identical, but Docker containerization<\/a> took 8% longer. Worth it for deployment reliability.<\/p>\n\n\n\n\n<\/figure>\n<\/figure>\n\n\n\nSkip Docker if:<\/strong><\/p>\n\n\n\n\n- Just prototyping locally and don’t need deployment yet<\/li>\n\n\n\n
- Render speed is absolutely critical and you’re maxing out local hardware (Docker adds some overhead)<\/li>\n\n\n\n
- Using Remotion Lambda\u2014AWS Lambda is already containerized, so Docker adds unnecessary complexity<\/li>\n<\/ul>\n\n\n\n
According to Remotion’s comparison docs, Lambda customers handle the highest render volumes because of distributed rendering. If you’re at that scale, stick with Lambda. For VPS or container services though, Docker is the sweet spot.<\/p>\n\n\n\n
Minimal Docker Approach (What Must Be Inside the Image)<\/h2>\n\n\n\n
The key is knowing what belongs in the image versus what stays outside.<\/p>\n\n\n\n
Here’s the minimal approach that works, based on Remotion’s official guide:<\/p>\n\n\n\n
Base image:<\/strong>node:22-bookworm-slim<\/code> (recommended since Nov 6, 2024\u2014smaller, LTS Node). I tested both node:20 and node:22 on Feb 8th; node:22 was 15% smaller.<\/p>\n\n\n\nRequired packages for Chrome:<\/strong><\/p>\n\n\n\ndockerfile<\/p>\n\n\n\n
RUN apt-get update && apt-get install -y \\\n libnss3 libdbus-1-3 libatk1.0-0 libgbm-dev \\\n libasound2 libxrandr2 libxkbcommon-dev \\\n libxfixes3 libxcomposite1 libxdamage1 \\\n libatk-bridge2.0-0 libcups2 fontconfig \\\n && rm -rf \/var\/lib\/apt\/lists\/*<\/code><\/pre>\n\n\n\nThese shared libraries let Chrome run headless<\/a>. Without them, you get “Failed to launch Chrome” errors.<\/p>\n\n\n\n\n<\/figure>\n<\/figure>\n\n\n\nWhat to COPY:<\/strong><\/p>\n\n\n\ndockerfile<\/p>\n\n\n\n
COPY package.json package*.json yarn.lock* pnpm-lock.yaml* tsconfig.json* remotion.config.* .\/\nCOPY src .\/src\nCOPY public .\/public<\/code><\/pre>\n\n\n\nWildcards (*) matter\u2014COPY requires at least one file but won’t fail if optional files are missing. Works across package managers.<\/p>\n\n\n\n
Don’t bundle large assets.<\/strong> I bundled a 200MB video early on and builds took forever. Mount as volumes instead.<\/p>\n\n\n\nCPU\/Memory Limits + Permission\/Volume Pitfalls<\/h3>\n\n\n\n
This is where most Remotion Docker setups break, and it’s not obvious why.<\/p>\n\n\n\n
The CPU limit problem:<\/strong> By default, Docker containers can use all host CPUs, but Docker Desktop on Mac and Windows defaults to limiting containers to a subset of your machine’s resources.<\/p>\n\n\n\nI tested on February 9th with a 16-core Mac. Docker Desktop was configured to use only 4 CPUs. My Remotion render with concurrency: \"100%\"<\/code> thought it had 16 cores available, spawned 16 Chrome instances, but only 4 could actually run. The result? Massive thrashing, slower renders, and eventual crashes.<\/p>\n\n\n\nThe fix:<\/strong><\/p>\n\n\n\n\n- In Docker Desktop settings<\/strong>, increase CPU allocation to match what you want containers to use. For Remotion, more CPUs = faster renders with parallel frame rendering.<\/li>\n\n\n\n
- Set explicit limits when running containers:<\/strong><\/li>\n<\/ol>\n\n\n\n
bash<\/p>\n\n\n\n
docker run --cpus=\"8\" --cpuset-cpus=\"0-7\" --memory=\"8g\" your-image<\/code><\/pre>\n\n\n\nThis tells Docker: “Use 8 CPUs (cores 0-7) and cap memory at 8GB.” Remotion auto-detects available CPUs and sets concurrency accordingly.<\/p>\n\n\n\n
\n- Enable <\/strong>
enableMultiProcessOnLinux<\/code><\/strong> in your render script.<\/strong> This is critical. By default, Chrome runs in single-process mode on Linux, which severely limits performance on multi-core machines. As of v4.0.137, this is the default, but on older versions you must enable it:<\/li>\n<\/ol>\n\n\n\njavascript<\/p>\n\n\n\n
await renderMedia({\n composition, serveUrl, outputLocation,\n chromiumOptions: { enableMultiProcessOnLinux: true },\n });<\/code><\/pre>\n\n\n\n
![\"\"](\"https:\/\/crepal.ai\/blog\/wp-content\/uploads\/2026\/02\/image-69-1024x459.png\")
<\/figure>\n<\/figure>\n\n\n\nBefore spending hours Dockerizing your project, here’s when it actually makes sense.<\/p>\n\n\n\n
Use Docker if:<\/strong><\/p>\n\n\n\n I tested locally vs Docker on Feb 9th. Quality was identical, but Docker containerization<\/a> took 8% longer. Worth it for deployment reliability.<\/p>\n\n\n\n Skip Docker if:<\/strong><\/p>\n\n\n\n According to Remotion’s comparison docs, Lambda customers handle the highest render volumes because of distributed rendering. If you’re at that scale, stick with Lambda. For VPS or container services though, Docker is the sweet spot.<\/p>\n\n\n\n The key is knowing what belongs in the image versus what stays outside.<\/p>\n\n\n\n Here’s the minimal approach that works, based on Remotion’s official guide:<\/p>\n\n\n\n Base image:<\/strong> Required packages for Chrome:<\/strong><\/p>\n\n\n\n dockerfile<\/p>\n\n\n\n These shared libraries let Chrome run headless<\/a>. Without them, you get “Failed to launch Chrome” errors.<\/p>\n\n\n\n What to COPY:<\/strong><\/p>\n\n\n\n dockerfile<\/p>\n\n\n\n Wildcards (*) matter\u2014COPY requires at least one file but won’t fail if optional files are missing. Works across package managers.<\/p>\n\n\n\n Don’t bundle large assets.<\/strong> I bundled a 200MB video early on and builds took forever. Mount as volumes instead.<\/p>\n\n\n\n This is where most Remotion Docker setups break, and it’s not obvious why.<\/p>\n\n\n\n The CPU limit problem:<\/strong> By default, Docker containers can use all host CPUs, but Docker Desktop on Mac and Windows defaults to limiting containers to a subset of your machine’s resources.<\/p>\n\n\n\n I tested on February 9th with a 16-core Mac. Docker Desktop was configured to use only 4 CPUs. My Remotion render with The fix:<\/strong><\/p>\n\n\n\n bash<\/p>\n\n\n\n This tells Docker: “Use 8 CPUs (cores 0-7) and cap memory at 8GB.” Remotion auto-detects available CPUs and sets concurrency accordingly.<\/p>\n\n\n\n javascript<\/p>\n\n\n\n\n
![\"\"](\"https:\/\/crepal.ai\/blog\/wp-content\/uploads\/2026\/02\/image-68-1024x541.png\")
<\/figure>\n<\/figure>\n\n\n\n\n
Minimal Docker Approach (What Must Be Inside the Image)<\/h2>\n\n\n\n
node:22-bookworm-slim<\/code> (recommended since Nov 6, 2024\u2014smaller, LTS Node). I tested both node:20 and node:22 on Feb 8th; node:22 was 15% smaller.<\/p>\n\n\n\nRUN apt-get update && apt-get install -y \\\n libnss3 libdbus-1-3 libatk1.0-0 libgbm-dev \\\n libasound2 libxrandr2 libxkbcommon-dev \\\n libxfixes3 libxcomposite1 libxdamage1 \\\n libatk-bridge2.0-0 libcups2 fontconfig \\\n && rm -rf \/var\/lib\/apt\/lists\/*<\/code><\/pre>\n\n\n\n![\"\"](\"https:\/\/crepal.ai\/blog\/wp-content\/uploads\/2026\/02\/image-67.png\")
<\/figure>\n<\/figure>\n\n\n\nCOPY package.json package*.json yarn.lock* pnpm-lock.yaml* tsconfig.json* remotion.config.* .\/\nCOPY src .\/src\nCOPY public .\/public<\/code><\/pre>\n\n\n\nCPU\/Memory Limits + Permission\/Volume Pitfalls<\/h3>\n\n\n\n
concurrency: \"100%\"<\/code> thought it had 16 cores available, spawned 16 Chrome instances, but only 4 could actually run. The result? Massive thrashing, slower renders, and eventual crashes.<\/p>\n\n\n\n\n
docker run --cpus=\"8\" --cpuset-cpus=\"0-7\" --memory=\"8g\" your-image<\/code><\/pre>\n\n\n\n\n
enableMultiProcessOnLinux<\/code><\/strong> in your render script.<\/strong> This is critical. By default, Chrome runs in single-process mode on Linux, which severely limits performance on multi-core machines. As of v4.0.137, this is the default, but on older versions you must enable it:<\/li>\n<\/ol>\n\n\n\n await renderMedia({\n composition, serveUrl, outputLocation,\n chromiumOptions: { enableMultiProcessOnLinux: true },\n });<\/code><\/pre>\n\n\n\n
![\"\"](\"https:\/\/crepal.ai\/blog\/wp-content\/uploads\/2026\/02\/image-66-1024x489.png\")
<\/figure>\n<\/figure>\n\n\n\n![\"\"](\"https:\/\/crepal.ai\/blog\/wp-content\/uploads\/2026\/02\/image-65-1024x531.png\")
<\/figure>\n<\/figure>\n\n\n\n