Rendley vs Shotstack: In-Browser SDK vs Cloud Render API

If you are evaluating video infrastructure for a product, the choice between Shotstack and Rendley is really a choice between two rendering models. Shotstack is a cloud render API: you describe an edit as a JSON timeline, POST it, and a server-side worker returns a finished file. Rendley ships a real editing engine that runs in the user's browser, and pairs it with a REST API and a hosted MCP server so you can render from a backend too.

Neither model is universally correct. This post is about where each one fits.

The core architectural difference

Shotstack's product is a mature, production-grade rendering service. You send a timeline (clips, transitions, HTML/text overlays, audio) as JSON to the Edit API, the render happens on Shotstack's infrastructure, and you poll for a URL. There is also a Create API for generative media, bulk rendering for high-volume jobs, and a source-available white-label Video Editor SDK. Importantly, that editor SDK is a UI layer; the actual pixels are still rendered by the cloud.

Rendley's SDK is a different animal. @rendley/sdk is a JavaScript/TypeScript engine that runs completely in the browser and renders client-side using WebCodecs and WebGL, with an FFmpeg (WASM) fallback where hardware codecs are not available. Under the hood it uses Pixi.js for compositing and Lottie for vector animation. This is not a demo wrapper around a cloud call. It is the same engine that powers app.rendley.com.

npm install @rendley/sdk

The practical consequence: with Rendley's SDK, a preview and an export can happen on the user's machine without a round trip for every edit. With Shotstack, editing UI can live in the browser, but rendering is a server concern. If your use case is "let users trim and caption a clip and export it, ideally without shipping frames back and forth," those are meaningfully different starting points.

Where the two overlap: the REST API

Both companies expose a REST API that returns a finished video, and this is where the comparison is closest.

Shotstack's Edit API is the more battle-tested of the two. It has been running in production for years, advertises a 99.9% uptime SLA, and is used by large brands. Its JSON timeline schema is well documented, and it offers first-party SDKs for Node, Python, PHP, and Ruby. If your backend is PHP or Ruby, that language coverage is genuinely broader than what Rendley publishes today.

Rendley's REST API lives at api.rendley.com/v1 (built on Go/chi) with an OpenAPI schema you can pull from api.rendley.com/docs/swagger.json. You authenticate with a Bearer API key generated in app settings. The surface covers project CRUD and collaborators, uploads (including multipart), POST /export with a matching /export/cost, a GET /jobs polling pattern that resolves to a signed URL, and a full /ai/* suite. Two things distinguish it:

• A prompt-to-video agent endpoint (/agent/sessions) that turns raw footage plus a brief into an assembled edit.
• Deterministic edits: the same request returns the same edit, which matters for caching, testing, and reproducible pipelines.

MCP and agents

It is still uncommon for a video API to ship an official MCP server, and both of these do.

Rendley runs a hosted server at mcp.rendley.com exposing 18 tools, covering workspace and project management, edit_video/check_edit, export_project/check_export, brand-kit operations, and file uploads. It is built on @modelcontextprotocol/sdk, drives the hosted editor via headless Chromium, and works with Claude, ChatGPT, Cursor, Codex, and any remote-MCP client. It requires a paid plan and the source is Apache-2.0 on GitHub as rendleyhq/rendley-mcp.

Shotstack ships an official MCP server too, with roughly a dozen tools mapped onto its render and Create APIs. If your interest is "an agent can call this thing," both qualify. The difference is mostly in tool count and in what the tools drive underneath (Rendley's tools operate the same editor and API that a human uses).

Generative AI

Rendley aggregates 25+ AI models from multiple providers inside a single project: video generation (Veo, Kling, Seedance, Sora, Wan, Hailuo), image (Flux, DALL-E, Nano Banana, Imagen), plus voice and audio through ElevenLabs and others. Every AI call has a matching /cost endpoint, so you can price a generation before you commit to it.

Shotstack approaches generative media through its Create API and Director AI, a prompt-driven generation layer. It is a coherent, well-supported path if you want generation and rendering from the same vendor with a smaller, more curated model set.

Pricing models are not the same shape

This is where you need to model your own workload, because the two bill on different axes.

Shotstack bills largely per rendered minute: pay-as-you-go around $0.30/min, or roughly $0.20/min on a subscription starting near $39/mo (200 credits). Output is capped at 1080p unless you are on enterprise, which unlocks 4K. There are 10 free credits that expire after 30 days. This is clean and predictable when your cost driver is "minutes of video rendered on someone else's servers."

Rendley uses subscription plans plus a credit system: Free, $15, $30, and $70 per month, where one credit equals $0.01 and credits meter AI generation rather than base rendering. The full editor and SDK come with the plan. The Free plan renders at 720p with a small watermark; paid plans remove the watermark and raise the resolution ceiling (1080p on Starter, 4K on Pro and Business). If a lot of your rendering happens client-side via the SDK, you are not paying per render minute for that work at all.

Where Shotstack is the stronger choice

Credit where it is due. Shotstack wins in several real scenarios:

• Proven high-volume cloud rendering. Years in production, a 99.9% SLA, and large enterprise logos. For headless bulk rendering at scale today, it is battle-tested.
• Broader backend SDK coverage. Node, Python, PHP, and Ruby out of the box.
• A mature, thoroughly documented JSON timeline for template-at-scale, backend-driven rendering.
• Simplicity when you never need an embedded editor. If all you want is server-side rendering with a per-minute meter, that model is easy to reason about.

Where Rendley fits better

Rendley makes more sense when you want the editor itself in your product, not just a render endpoint. Because @rendley/sdk renders in the browser, you can embed a true editing experience, keep previews local, and reach for the cloud GPU worker (RunPod serverless) only for heavier exports. You get three integration surfaces (SDK, HTTP API, MCP) built on the same engine, deterministic edits, a prompt-to-video agent, 25+ AI models with per-call cost visibility, and EU-based object storage (Hetzner, in Nuremberg, Germany).

If your product roadmap includes "users edit video inside our app," the in-browser engine is the deciding factor. If it is purely "our backend renders finished files at volume," Shotstack's mature cloud service is a strong, safe pick.

Want to see the engine? The SDK docs live at docs.rendleysdk.com, and you can spin up an account at app.rendley.com.

---

Competitor details (pricing, features, SLA) are drawn from Shotstack's public pricing page and MCP documentation as of mid-2026 and may change. Verify current terms with each vendor.