Long-form by nature
Videos run for tens of minutes per scene, with several scenes per movie — a rendering workload where small inefficiencies multiply.
Client work · Media pipeline engineering
Lillowe Beats: replacing a paid video API with a renderer they own
Lillowe Beats produces long-form meditation videos — ambient imagery, layered music, hour-scale runtimes. The render step ran on a paid third-party API. We built a self-hosted FFmpeg renderer behind the same API shape, so the existing automation kept working untouched.
Drop-in API
FFmpeg rendering
Self-hosted
At a glance
- Client Lillowe Beats — meditation music and video production.
- Scope Self-hosted renderer, compatible API, n8n pipeline integration, VPS deployment.
- Runtime Long-form scenes (up to 30+ minutes per scene), looping audio, outro fades.
- Result The same workflow JSON that called the paid API now calls the client's own server.
The client
A music business where video is the product
Meditation content is consumed in long sessions, so every upload is a long video with visually calm scenes and music that loops without seams. Producing them at volume means automating the render — which is exactly where the cost and control problems live.
Audio must be seamless
A loop that clicks or an abrupt ending breaks the experience the entire product depends on. Fades and loops have to be exact.
An existing pipeline
The n8n workflow that assembles movies already worked. Whatever replaced the render step had to speak the same language.
The problem
Paying per render for something the business could own
- The video render step depended on a third-party service with its own pricing, limits and availability.
- Long meditation videos are exactly the kind of render that gets expensive at volume.
- Creative control was capped: the service decided which effects and input types were possible.
- Rebuilding the pipeline around a new provider meant rewriting working automation.
- Any replacement also had to handle image sources from cloud storage and cinematic video clips, not just still images.
Why it happens
Hosted render APIs are the fastest way to start and the slowest way to scale. Once the workflow is stable, the render step becomes a recurring bill for a process the business could run on its own server.
This describes the trade-off the project was scoped to remove.
What we built
A render engine behind a familiar API
The key design decision: compatibility. The new renderer accepts the same movie JSON, uses the same endpoints and returns the same response shape as the service it replaces.
Drop-in API shape
Create, check status, list and delete render jobs — plus a health check and a cleanup endpoint for old jobs. The existing n8n workflow points at the new base URL and keeps its exact request body.
FFmpeg render core
The engine builds each movie from scene objects: images or video clips, durations (including 30-minute scenes), scaling and fit rules, overlays and audio.
Seamless audio and outro fades
Music looping and fade-in / fade-out are first-class render options, engineered so long ambient tracks join without audible seams at the lengths meditation content demands.
Cinematic clip support
Alongside static images, the renderer accepts cinematic video clips as scene sources — so the pipeline can mix slow-motion footage with still artwork.
Resolution presets
Standard output presets — full HD, square, and 1080×1920 story formats — with custom width and height when needed, matching how the pipeline targets each platform.
Job tracking and cleanup
Renders run as background jobs with status polling, so a long video does not hold a workflow open — and completed jobs can be cleaned up automatically to protect disk space on the server.
Evidence
What the delivered system contains
The API documentation and deployment files describe the renderer that was built and shipped to the client's VPS.
6
API endpoints delivered: create, status, list, delete, health and cleanup
30 min+
per-scene durations supported for long-form meditation content
4
output presets (full HD, squared, story, feed) plus custom dimensions
0
changes required to the client's existing workflow request format
Verified build facts
These facts come from the delivered API documentation and renderer source. No cost-saving or output-volume claims are made — the client's hosting economics are the client's own.
FFmpegNode.jsn8nVPSJSON2Video-compatible API
How a render runs
From prompt to published video
1
Create
The workflow posts a movie object to the renderer's create endpoint.
2
Render
FFmpeg assembles scenes, loops the audio and applies fades in the background.
3
Poll
The workflow checks status until the movie is complete.
4
Publish
The finished video is picked up for publishing; old jobs are cleaned up.
Honest limits
What this case study does not claim
No cost-savings number
Self-hosting shifts cost from per-render fees to a server the client already operates. We have not published a savings figure because the client's usage volume and hosting economics are theirs to state.
Compatibility, not parity guarantees
The API accepts the same shape as the service it replaced. Where a hosted provider may offer effects beyond the built set, the documentation is explicit about what is supported rather than silently dropping options.
Operational responsibility moves to the server
Running your own renderer means owning uptime and disk cleanup. The deployment includes a health endpoint and a cleanup job to make that manageable — but it is real operational responsibility, and we say so.
FAQ
Questions about this build
Why keep the old API's format instead of designing a cleaner one?
Because the goal was to replace the bill, not the workflow. Compatibility means the existing pipeline — prompts, movie assembly, publishing — keeps working with a base-URL change, with no rewrite risk and an easy rollback if anything needs rethinking.
Can it handle very long meditation videos?
Yes. Scene durations of 30 minutes and beyond are supported, renders run as background jobs with status polling, and a cleanup endpoint removes old completed jobs so disk usage does not creep on a server that is producing video around the clock.
Who maintains the server?
The renderer runs on the client's own VPS. Deployment scripts and documentation were delivered with the build, and the health endpoint makes monitoring straightforward. Operations — uptime, storage, scaling — stay with the client, which is the trade-off chosen deliberately over per-render pricing.
Get your plan
Paying per render for content you produce every day?
Tell us what your pipeline makes and what it costs to run. On a free strategy call we will map where self-hosting makes sense — and where it does not.
- A free 15-minute AI strategy call — no obligation.
- A scoped blueprint: the biggest recurring cost, and the first fix.
- Honest fit check — sometimes the hosted API is still the right answer, and we will say so.
The fastest way in: answer six short questions and we will map your production pipeline, find the biggest leak and show the fastest win — before we ever get on a call.
Free strategy call · No commitment · We reply by email
Keep going
Related pages
More client work
Relevant AI services
Next steps
Ready to own your rendering pipeline?
Book a free AI strategy call and we will walk your production flow against this build.