Rendley docs

Rendering and export

Render on a server

The server approach uses the same SDK that is used on the client side; however, it operates in a controlled environment where you have greater control over the rendering process and resources. This method launches a headless Chromium browser to handle the rendering.

You can find the full implementation on GitHub.

Requirements

  • GPU hardware for the WebGL context
  • A minimum of 4 CPU cores

Chunking

Compared to the client rendering approach, the server rendering method can chunk a large video into smaller parts and render them in parallel. These parts are then combined into a single video file.

The number of chunks can equal the number of CPU cores available, as each chunk is processed in a separate process. Currently, the server performs chunking by default and is configured to use all available cores.

Infrastructure

At present, we provide the rendering server as a Docker container. We do not manage the overall infrastructure or scaling.

Getting started

Clone the rendering server and follow the README to start a local instance:

git clone https://github.com/rendleyhq/video-rendering-server.git
cd video-rendering-server
docker build -t rendley-render .
docker run --gpus all -p 3000:3000 rendley-render

The server exposes a REST API. POST a serialized composition and receive the rendered video:

curl -X POST http://localhost:3000/render   -H "Content-Type: application/json"   -d '"composition": "<serialized JSON>"}'

Scaling

Each container handles one render at a time by default. To scale horizontally, run multiple containers behind a load balancer and route jobs round-robin. The rendering process is stateless: every asset URL in the composition is fetched fresh, so no shared filesystem is needed between workers.

For vertical scaling, increase the number of CPU cores and the CHUNKS environment variable. A 16-core machine rendering a 2-minute video at 1080p typically finishes in under 30 seconds.

Output parity

The server renders using the same SDK and the same WebGL pipeline as the browser. Output is bit-for-bit identical to client-side rendering, so you can preview in the browser and render on the server with confidence that the result matches.