A video maker where the hard part was never the editor. It was the render

The situation

Vidmattic was an online video maker for marketing videos. You started a canvas, dropped in a base video, and kept stacking layers on top: text, gradients, images, and so on. The UI was deliberately plain. The whole point was that someone non-technical could put a marketing video together without opening an editing tool.

That description makes it sound like a front-end project. It wasn't. The editor is the part users see, and it's the part that took the least inventing. The hard problem sat behind the render button, where a stack of browser layers has to become a real video file without a render farm underneath it.

Our answer was to make the editor's output a data structure rather than a picture. The layer stack serialises into a timeline. That timeline goes onto a queue. A Lambda picks it up, compiles it into an FFmpeg command, renders the file, and writes it to S3. The database stores the path, and the video is served from there.

One thing to be straight about before you read further. The engineer who wrote the account this page is built on joined after the project had started, and he never held the client side of it. So this page covers engineering and nothing else. There are no outcome numbers here, no discovery story, and no budget shape, because we do not hold them. The evidence note near the bottom of this page says exactly what is missing and why.

The problems worth reporting

• Getting FFmpeg inside Lambda at all

  FFmpeg is not a library you import. It's a binary, and a large one, and Lambda is not a machine you install things on. The options are to give up on serverless and run containers or EC2 with FFmpeg baked in, or to get the binary into the Lambda execution environment some other way.

  We packaged FFmpeg as a Lambda layer. The renderer function then stays small and ships on its own, while the binary sits behind it as a separate, rarely changing artifact. That split is the reason deploys stayed quick on a project where the render logic changed constantly and the binary never did.

  The cost is that layers are a real constraint, not a convenience. They have size limits, they are versioned separately from the function, and as the next challenge explains, they are also the first thing local tooling drops.

• The 900-second ceiling is not a performance target, it's a wall

  A Lambda invocation has a hard maximum duration. We ran the renderer at the 900-second maximum, which is the highest the platform allows. There's no tier above it. If a render doesn't finish inside fifteen minutes, it doesn't finish.

  That changes how you think about the work. On a server you'd optimise a slow render because slow is annoying. Here, slow is a failure mode, so the FFmpeg command the Lambda builds has to be efficient by construction rather than tuned afterwards. Every layer type added to the editor is also a question about what it does to render time at the worst case.

  If we were sizing this pipeline again, the honest engineering answer is that a hard ceiling with no escape hatch wants a fallback path for the jobs that would exceed it, whether that's a container-based renderer for long timelines or a segmented render that stitches parts together. On this project the ceiling held for the work in front of it.

• Translating a timeline into an FFmpeg command without the code turning into string-building

  FFmpeg is driven by command-line arguments, and complex compositions produce long, fragile argument strings. The naive version of this project has one function that takes the timeline JSON and concatenates its way to a command. That function grows with every layer type and becomes unreadable at about the third one.

  We built a separate toolbox layer of reusable functions whose only job is turning pieces of timeline JSON into pieces of FFmpeg command. The renderer composes those pieces rather than building strings inline. That's the decision on this project worth copying: the mapping from editor concepts to encoder arguments deserves to be its own named thing, with its own deploy artifact, because it's where all the complexity accumulates.

• Testing a layered Lambda locally, on tooling that doesn't support layers

  Iterating on a render pipeline by deploying to AWS each time is slow enough to change how people work. So we ran LocalStack to get the pipeline on a developer machine.

  The problem is that the free tier of LocalStack does not support Lambda layers, and layers were the whole basis of our packaging. Both FFmpeg and the toolbox lived in them.

  We wrote a small converter script for local runs. It flattens the layers and the function into a single function, which LocalStack can execute. Developers got a working local pipeline, and the production packaging stayed as it was. This is a workaround and worth naming as one: local and deployed artifacts are not identical, so anything that depends specifically on layer resolution is not covered by local tests.

1. Edit

   Konva canvas, serialised to a timeline

   A base video takes text, gradient, and image layers stacked on top, with state held in Recoil. On save, the editor turns that stack into a timeline: a data description of what sits where, over what, for how long. It is the contract between the editor and the renderer.

3. Queue

   SQS

   The timeline goes onto a queue rather than straight to compute. Submission is decoupled from execution, so bursts are absorbed instead of dropped.

5. Render

   Node Lambda with FFmpeg as a layer

   The Lambda builds the FFmpeg command from the timeline using the toolbox functions, then renders the video. It has 900 seconds, and no more.

7. Store

   S3, with the path in Postgres

   The output file is written to S3. The path is stored in the database behind Hasura, and the video is served from there.

1. A canvas editor that treats a video as a stack of layers, not a timeline of clips

   The editor is built on Konva for the canvas and layer manipulation, with Recoil holding editor state and Grommet supplying the UI components. The mental model deliberately avoids the one professional editors use. There's no multi-track timeline to learn. There's a base video and things you put on top of it, which is a model a marketer already has from every other design tool they've used.

   

2. A GraphQL back end where the data layer is generated, not written

   NestJS handles application logic over a GraphQL API, with Hasura sitting on Postgres as the data layer. Projects, layer stacks, render jobs, and output paths are all straightforward relational data, and generating the API over that schema meant the team spent its time on the render path rather than on writing resolvers for CRUD.

   

3. A renderer that is a data compiler, and is deployed as one

   The Lambda's job is narrow: take a timeline, produce a command, run it, write the file. It lives in its own repository and deploys independently of the application. FFmpeg and the toolbox functions sit beneath it as layers, so a change to how a gradient is composited does not redeploy a video encoder.

   

4. A separate admin panel, kept out of the product

   Operational tooling runs as its own React application rather than as privileged routes inside the user-facing product. That keeps admin capability out of the codebase users load, and it means the two can change on their own schedules.

   

How it runs

AWS Lambda

Render load is bursty, so a provisioned fleet is either idle or short. Lambda runs each job in isolation with nothing running between jobs. The trade we accepted for that is the 900-second maximum duration, which we ran at its ceiling and which has no tier above it. FFmpeg ships as a Lambda layer, which keeps the renderer function small and independently deployable.

AWS SQS

The queue sits between the editor and the compute so job submission is decoupled from job execution. That gives natural back-pressure on bursts, and makes retries and dead-letter handling a configuration concern rather than something the application has to implement.

AWS S3

Rendered files are written to S3 by the Lambda, and the object path is stored in Postgres. Video files are large and rarely modified after creation, which is exactly what object storage is for. No separate media server sits in the path.

Next.js

The editor is the application, so the front end needed to be a real app rather than a rendered page, while the surrounding marketing and account surfaces wanted fast first loads. Next.js covers both without a second front-end stack.

Konva

The product's core interaction is manipulating stacked layers on a canvas. Konva gives that model directly, with hit detection, transforms, and layer ordering handled, instead of building canvas primitives from scratch. Recoil holds the editor state around it, and Grommet supplied the surrounding UI components.

NestJS

The back end coordinates projects, render jobs, and outputs over GraphQL. NestJS gave the application layer a structure that stayed navigable as the render path grew more involved.

Hasura

Projects, layer stacks, job status, and output paths are ordinary relational data. Hasura generates the GraphQL API over the Postgres schema, so the team wrote resolvers for the things that needed logic and none for the things that did not.

Firebase

Authentication was not where this project's difficulty lived, and building it would have taken time from the render pipeline. Firebase handled sign-in with no infrastructure for the team to run.