Nova Studio's video tab is pure JSON: the host ships no upstream video protocol and plugins declare their own form

The host ships no upstream video protocol, so video capability is only ever a plugin

Nova Studio is explicit that video generation contains no upstream-specific protocol. The host supplies the surrounding machinery and nothing more: the workbench tab, the task queue, history, media upload, and form rendering. Everything that makes a video provider a video provider lives in the plugin pack instead, and the project enumerates it plainly as who to call, what to send, how to poll, where the result is, and what the form looks like.

A plugin is three JSON files and no executable code: `manifest.json`, `ui.schema.json`, and `provider.json`. That is the whole security model in one sentence. Because a pack cannot execute anything, installing one cannot run code on the server, and the blast radius of a bad plugin is limited to what it declares in its manifest. The reference implementation is `backend/plugins/ccode-h3/`, covering MiniMax H3 with eight models and support for first and last frame, reference image, video and audio, and upscaled tiers.

Installation is an administrative act rather than a UI one. An admin drops the plugin directory into `backend/plugins/` and then restarts the backend, or clicks Reload in Settings. The official collection doubles as a template and is designed to be cloned straight into place:

cd backend/plugins && git clone https://github.com/tianjiangqiji/nova-studio-plugins.git .

One practical wrinkle: the plugin protocol documentation under `docs/plugins/` is written in Chinese, while the rest of the project's documentation is English. For a non-Chinese-reading maintainer that is the single biggest obstacle in an otherwise well-structured extension path.

The entire video form is rendered from the plugin's ui.schema.json

Form rendering is the part that makes the plugin approach more than a URL template. The whole left-hand panel of the video workbench is generated from the plugin's `ui.schema.json`, and the schema is where tiers, resolutions, durations, and media slots are declared. The host knows nothing about any specific upstream, which is what allows a pack targeting a first-and-last-frame video model and a pack targeting a text-to-video model to present coherent, different interfaces from the same shell.

The credential model is a deliberate part of the same design. `apiKey` and `baseUrl` are entered under Settings, on a Plugins section, per plugin, and they are stored in the browser rather than in the database. Combined with the fact that all client configuration lives in the browser's localStorage, the server never holds your provider credentials. If the server is lost or replaced, keys are re-entered on each client rather than restored from a database dump.

The Settings page is also deliberately read-only in one direction. It lists what is installed and, importantly, why a pack failed to load, but installing and removing plugins requires server access. So there is no self-service plugin install from the browser, and the failure explanation you see there is the diagnostic channel when a pack will not load. Protocol reference material is split by concern across the manifest, the UI schema, and the provider documents, with a separate page for errors, a cookbook of known-good patterns, and a lifecycle page describing how a task progresses.

Egress is allowlisted and every private or loopback address is refused

Because a plugin decides where to send requests, the host has to constrain where those requests may go. The rule is that any host outside `permissions.hosts` is refused, and additionally every private or loopback address is refused. That second clause is the one doing real work: even if a plugin declares a host permission, a destination that resolves to a loopback or private-range address is still blocked. It closes the obvious path where a plugin pack reaches back into the machine it is installed on.

The complementary rule concerns results. Returned URLs pass through untouched, with no domain rewriting, so the video link you get is exactly what the upstream returned. That matters for two reasons at once. It means a plugin cannot quietly redirect a finished asset to infrastructure you did not intend, and it also means the project does not proxy media through itself, which keeps large video files off the server's disk and bandwidth.

The other half of the trust model is that video is not special-cased anywhere. The same JSON pack structure describes what to call and how to poll, and the same allowlist applies to every plugin, so adding a second video provider does not create a second security surface. For an organisation reviewing packs before installation, the review surface is three JSON files per pack, which is a tractable thing to read.

Image and text models are configured separately, and text means Google or OpenAI Responses

The bring-your-own-model story is deliberately narrow. Image models and text models are configured as separate categories, each with its own API key and base URL. You define the model list and the endpoints yourself, and the backend routes by protocol while passing your parameters through unchanged. That last part is the point: there is no parameter whitelist rewriting your request, so whatever a provider accepts can be sent.

For text, two protocols are named. Google models are called through `generateContent`, and OpenAI models through the Responses protocol. Anything else is out of scope for the text path, so the set of usable text providers is narrower than the set of usable image providers. The reverse-prompt mode depends on this layer: it uploads an image and streams a prompt back using any configured text model, which means the quality of that feature is bounded by whichever text protocol you have configured.

The three runtime dependencies map one to one onto the backend's described architecture. `server.js` runs on Node, SQLite holds task state through `better-sqlite3`, generation APIs are proxied over `undici`, and live task updates are pushed to the browser over `ws`. Those three packages, plus the standard library, are the entire server surface named in the package manifest, which is a small enough dependency list to audit by reading it.

Above that sit seven working modes with named entry components: text-to-image, image-to-image, an agent workspace, the UI design workspace, reverse prompt, GIF generation, and the plugin-driven video workbench. The GIF mode encodes in the browser with `gifenc` after multi-frame generation and grid assembly, so GIFs cost no server-side media work.

The Docker build installs a C++ toolchain, then purges it before shipping

The Dockerfile is three stages on `node:22-slim`, and one detail in the middle stage is worth reading twice. Installing `better-sqlite3` needs a native build toolchain, so the backend-deps stage installs `python3`, `make`, and `g++` before running `npm ci --omit=dev`, and then immediately purges all three with `apt-get purge -y --auto-remove`. The compiler is present exactly as long as it is needed and absent from the image that runs, so the native module ships without carrying a build environment around it.

The frontend stage copies only `frontend/package.json` and its lockfile before the full source, which is the standard cache-friendly layering. The production stage copies the backend, the resolved `node_modules`, and the built frontend from `frontend/out`, which is where a Next.js static export lands, then creates the data directory, exposes port 3000, and starts `node backend/server.js` with `NODE_ENV=production`.

Compose sits on top with one service published on port 3000 and a restart policy of `unless-stopped`. Two environment variables point the task database and image directory into the mounted volume: `NOVA_TASK_DB` and `NOVA_IMAGE_DIR`, both under `backend/data`. Alongside the data mount, compose also binds `blacklist.json`, `prompts.json`, `.env`, and a `./plugins` directory onto their expected paths, which is the supported way to add plugin packs and supply configuration without rebuilding the image. Note that the port mapping is `3000:3000` with no loopback bind, so the published port listens on all interfaces.

UI design mode stores nothing until you tick off what the model proposed

The UI design mode is the most involved of the seven modes, and it is the one with the strictest human checkpoint. You start from a flat mockup, a vision model proposes slices and background candidates, and none of it is stored until you tick items off in a confirmation dialog. That confirmation step is the design decision: an agent proposing a decomposition of your design should not be able to commit it unilaterally.

The slice editor that follows is a full image editor, with zoom and pan, drag-to-create, rubber-band multi-select, eight-way resize, per-corner radius, snapping, a context menu, keyboard shortcuts, and undo and redo to fifty steps. Three view modes let you check the work: original shows the source with outlines, knockout shows the post-cutout result, and slices only shows a checkerboard. Knockout is generated locally and stated as costing nothing.

The mode is wide-screen only, and narrow viewports show a hint to switch rather than a degraded layout. That is a deliberate cutoff rather than an omission, though it does mean the mode is unavailable on a phone. The list of asset operations is described as four in number, covering algorithmic transparency and AI transparency among them, but the documentation here cuts off before enumerating all four, so the complete set is not readable in this copy.

Beyond that mode sit the smaller tools: an agent workspace that goes chat to plan to images with vision descriptions, web search, reasoning, and local browser CDP for opening and reading pages, plus reverse prompt, a prompt gallery, an assets view, and an infinite canvas.

Editorial conclusion

Nova Studio fits a small team that already holds API keys for image and text providers and wants a browser workbench it hosts itself rather than another hosted generator. It does not fit you if you need video on day one without writing or installing a plugin, because the host contains no video protocol at all. Two things to check first. Whether the plugin protocol documentation is usable by you, since those documents are written in Chinese while the rest of the project is not. And what you are exposing, because the Docker compose file publishes port 3000 on all interfaces rather than on loopback; the design keeps keys in browser storage instead of the database, which is the right instinct, but the instance is still reachable. Pin a version rather than tracking latest, since there are no GitHub releases and the compose file defaults to the latest tag.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. Project website
4. README
5. tianjiangqiji/nova-image-studio on GitHub