How We Built Nexrender Cloud
Hi, it’s Vlad, creator of Nexrender.
About ten years ago, I was writing electronic music and needed a way to publish it to YouTube with visuals. After Effects was the obvious choice, but repeating the same steps for each video quickly got annoying. So I automated it. That script eventually turned into Nexrender.
I published it on GitHub. At some point (in about 8 years), it passed 1700 stars. That’s when we started wondering who was actually using it — and why.
Who’s Out There
At first, I added anonymous analytics to one version to understand the usage extent. It turned out Nexrender was facilitating millions of renders a month. Then me and my small team scraped GitHub, followed commit trails, and sent a lot of cold emails. Eventually we spoke with over 200 users.
Most of them had found ways to make Nexrender work in serious production workflows — internal tools, automation scripts, rendering pipelines, some even CI-integrated.
They weren’t complaining. In fact, many were fans. What they needed wasn’t a new tool — it was less maintenance. They wanted fewer moving parts, better visibility, and someone to call when things broke. Some wanted to scale their workloads; others just didn’t want to run any infrastructure themselves.
Building the Cloud
We started small, with a simple hosted version that kept the same job format and behavior. For most users, switching meant changing endpoints and tokens — nothing else. That simplicity made adoption straightforward.
There was no sales process. We built demos by hand and handled onboarding ourselves. If something broke, we fixed it. We reviewed templates, tuned project setups, helped people clean up their render queues, and patched jobs manually when needed.
The underlying system was rough, but it worked. That was enough to keep going.
The Founding Team
Anastasiia, Dominik, Alex, and I have been building things together for years. A lot of projects have failed. A few worked out. We’ve done infrastructure, products, consulting, and more client launches than we care to count.
We’ve stayed up late to fix outages. We’ve watched renders break and succeed in real time. We’ve learned to keep things steady when they go well, and calm when they don’t. That’s the culture this platform was built on.
Rebuilding for Real Scale
The early version of the cloud worked — until it didn’t. The more serious the workloads became, the more obvious it was that we needed to rebuild.
So we did.
We also faced lots of production edge cases like huge projects, rare localizations, rendering glitches, and unique customer requirements.
The current system runs on autoscaling render fleets and multi-region queues. It supports job deduplication, prioritization, retries, and clean recovery. There’s a full lifecycle REST API, webhook delivery, and real-time logging with per-frame error tracing. We’ve built dashboards to track asset load, job rates, and crash patterns. Deploys are zero-downtime, with rollback pipelines ready.
It’s not over-engineered. It’s stable. We’ve seen it run six-figure job volumes with no human intervention.
Where We Are Now
We’re no longer doing everything ourselves. We now have a CTO and a team to support our enterprise clients. The system is monitored, structured, and covered under real SLAs. When something needs attention, it gets it quickly.
That said, we’re still involved. We still read logs. Still ship fixes. Still care about the details. But the company doesn’t depend on our sleep schedules anymore, which is an improvement.
Who Uses It
Some of our customers are large entertainment venues generating personalized content. Others are developer teams building headless video APIs. A few are in live sports, where rendering highlight reels has to happen minutes after the final whistle.
Most of them started with the OSS version. At some point, they realized they didn’t want to manage render nodes, queues, or failures. That’s usually when they move to the cloud.
The migration takes minutes.
The whole thing is still bootstrapped.
No outside funding.
No growth theater.
Just infrastructure that works, built by the people who needed it first.
What’s Next
We’re not done. Far from it.
We’re keeping Nexrender moving forward, with several projects already underway:
Multi-engine core — rebuilding the foundation to support multiple rendering engines, not just After Effects
Lottie rendering — almost ready for release, for fast, lightweight animations
Onboarding UI — a full visual flow for getting from template to production without touching the API
Smart caching — skip downloading assets that haven’t changed, saving both time and cost
Integration center — connect data from databases, spreadsheets, UI inputs, and other sources without custom glue code
We’re also listening. If there’s something you’d like to see next, open an issue or join the discussion on our website.