Nova Studio: a self-hosted image and video workbench where video is pure JSON plugins

The problem Nova Studio takes on, and the people it is built for

Most generation front ends assume one vendor. You paste a key, the UI knows the request shape, and swapping providers means waiting for the maintainer. Nova Studio inverts that for video. According to the README, video generation is fully plugin-based and the host ships no upstream video protocol at all, so capability comes from plugin packs rather than from the repository itself.

The stated audience is individuals and small teams. The shape of the product matches that: a statically exported frontend, a small Node.js service built from server.js, SQLite for task storage, and WebSocket for live task updates. There is no cluster, no queue broker, no separate worker fleet to operate. One container on port 3000 is the intended deployment unit, which the docker-compose.yml confirms with a single service definition.

Image and text models are configured separately, each with its own API key and base URL. That split matters because the two are used for different jobs. Image models produce assets; text models drive the reverse prompt feature, which streams back a prompt for an uploaded image, and the Agent mode, which plans and can search the web. Text models can speak either Google's generateContent protocol or the OpenAI Responses protocol.

What Nova Studio does not try to be is a hosted service with a shared model catalog. You define the model list and endpoints yourself, the backend routes by protocol and passes your parameters through, and all client configuration lives in the browser's localStorage. If you want a curated catalog maintained by someone else, this is the wrong shape of tool.

How the frontend, backend and plugin boundary fit together

The frontend is a Next.js 16 and React 19 static export, built as a PWA. The Dockerfile shows the build producing frontend/out/, which is then copied into the production image next to backend/. The backend is the only long-running process, started with node backend/server.js.

Task scheduling and API proxying sit in that backend. The compose file pins two environment variables, NOVA_TASK_DB and NOVA_IMAGE_DIR, so the SQLite task database and the generated image directory land on the mounted ./data volume rather than inside the container layer. WebSocket carries live task updates to the browser, which is why the README describes the task mechanism as lightweight rather than queue-based.

The plugin boundary is the part worth studying. A plugin is three JSON files: manifest.json, ui.schema.json and provider.json. There is no executable code in a pack, which removes a whole class of supply-chain questions but also caps what a plugin can express to whatever the documented schema allows. The video workbench form is rendered entirely from the plugin's ui.schema.json, so tiers, resolutions, durations and media slots are declared by the plugin and the host knows nothing about any specific upstream.

Egress is declared rather than inferred. Any host outside permissions.hosts is refused, and every private or loopback address is refused as well. Credentials are entered per plugin under Settings, stored in the browser, and never written to the database. That is a deliberate separation: the server holds tasks and assets, the browser holds secrets. The settings page is read-only and reports what is installed and why a pack failed to load, so installing or removing plugins requires server access.

One consequence of the pass-through design is stated plainly: result URLs pass through untouched, with no domain rewriting, so the video link is exactly what the upstream returned. If a provider returns a short-lived signed URL, nothing in the host extends it.

Installing Nova Studio with Docker and running a first image task

The repository ships a Dockerfile and a docker-compose.yml, and the compose file is the shortest path to a running instance. It uses the published image tianjiangqiji/nova-image-studio:latest. Run this from a directory where you are happy to keep a ./data folder:

docker compose up -d

The service maps port 3000 to the host and mounts ./data at /app/backend/data, plus ./blacklist.json, ./prompts.json, ./.env and ./plugins at their respective paths inside the container. Those last four files must exist before the stack starts cleanly, so create empty ones if you do not have them yet.

The compose file sets NOVA_TASK_DB to backend/data/nova-tasks.sqlite and NOVA_IMAGE_DIR to backend/data/nova-images. Both sit under the mounted data directory, which is what you want: recreating the container should not discard your task history or your generated images.

If you prefer to build from source, the root package.json exposes the scripts. The install step is install:all, which installs frontend and backend dependencies in sequence, and the production start is start:

npm run install:all
npm run build
npm start

The build script runs the frontend build, and start runs node server.js from backend/. Note that the root dev script is not a hot-reload server: it builds the frontend and then runs the backend in production mode, so the edit-refresh loop for frontend work is npm run dev:frontend against npm run dev:backend.

With the instance up, open the app on port 3000, go to Settings, and add an image model with its API key and base URL, plus a text model if you want reverse prompt or Agent mode. Then use the Text to image form with a prompt. The README states that this form can generate multiple images in parallel. Because configuration lives in localStorage, the model list is per browser profile, not per server account; a second browser starts empty.

Where Nova Studio gets in the way

The largest limitation is stated by the project itself: the host ships no upstream video protocol. If you install Nova Studio expecting video generation, you get a workbench tab, a task queue, history, media upload and form rendering, and nothing that can talk to a video vendor until a plugin pack is present. The official collection at nova-studio-plugins is the intended source, and the reference implementation in the repository is backend/plugins/ccode-h3/ for MiniMax H3, which the README says covers 8 models, first and last frame, reference image, video and audio, and upscaled tiers. One reference pack is not a broad catalog.

Plugin management assumes server access. The settings page is read-only and the installation path is dropping a directory into backend/plugins/ followed by a backend restart or a Reload click. On a managed platform where you cannot touch the filesystem, you cannot add a provider.

UI design mode has a display constraint. The README notes it is available on wide screens only, which rules it out on the tablet and mobile layouts the project otherwise supports.

Because credentials live in the browser and never in the database, every user supplies their own keys. That is good for privacy and bad for shared deployments: there is no central place to configure a key once for a team, and clearing browser storage means re-entering credentials.

Finally, the plugin protocol documentation is written in Chinese. The README links manifest, ui.schema, provider, lifecycle, errors and cookbook pages under docs/plugins/, and the quickstart claims a working plugin in 10 minutes, but an English-only reader will be reading those specs through translation. That is a real adoption cost for the one feature that most distinguishes the project.

How the plugin model differs from configuration-driven tools

The obvious comparison is a generation front end that ships a fixed provider list and lets you choose from it. Tools built that way tend to be faster to start with: you pick a provider, paste a key, and generate. The trade-off is that adding a provider the maintainer has not implemented is not something you can do, and provider-specific parameters get flattened into whatever the shared form supports.

Nova Studio takes the opposite position. The host knows nothing about any specific upstream, and the form itself is generated from the plugin's ui.schema.json, so a plugin can declare its own tiers, resolutions, durations and media slots. Parameters are passed through rather than normalized. Adding a provider is a JSON authoring task, and the README points to docs/plugins/LLM.md for pasting into an AI assistant to have the plugin written for you.

The cost of that flexibility is that the plugin author carries the integration. Polling behavior, result location, error mapping and form layout all live in the pack, and the host only enforces the boundary: declared egress hosts, no private or loopback addresses, no executable code. A pack that misdeclares its hosts will be refused rather than silently allowed, and docs/plugins/errors.md exists precisely because packs fail to load.

If your provider is already supported by a mainstream front end and you never expect to change it, the plugin machinery is overhead you will not use. If you have a provider that mainstream tools ignore, or you want video credentials to stay in the browser while the server only sees tasks and assets, the plugin boundary is the reason to pick this project.

Maintenance, licensing and what to check before you deploy

The repository is not archived, and the last push was on 2026-09-02. The version badge in the README reads v3.3.0 and package.json agrees, and no releases were retrieved for this write-up, so versioning appears to be tracked in the README badge and package.json rather than through published release notes. There is no changelog in the top-level file listing, which means an upgrade decision has to be based on the diff and the version number.

Upgrade cost concentrates in three places. The task database is SQLite at backend/data/nova-tasks.sqlite, so schema changes between versions touch a file you are mounting from the host. Plugin packs are versioned separately from the host, and the README does not document a compatibility matrix between host version and plugin schema, so a pack that works today is not guaranteed to work after a host upgrade. The frontend is a static export copied into the image, so a frontend change requires a rebuild rather than a file drop.

The licence is AGPL-3.0. That is a network copyleft licence: if you modify Nova Studio and let users interact with it over a network, the licence's source-availability condition applies to your modified version. Running an unmodified copy for yourself is a different situation from forking it into a service you offer to others, and the difference is worth confirming with someone qualified rather than inferring from this paragraph. The repository also ships a LICENSE file, which is the text that governs, not the badge.

The Dockerfile is worth reading for one operational detail: the backend dependency stage installs python3, make and g++ because better-sqlite3 needs them at install time, then purges them. If you build outside that image, you need those tools available or the backend install will fail.

Editorial conclusion

Adopt Nova Studio if you already hold API keys for image models and text models and want a browser UI, a task queue and a plugin boundary between your credentials and any video vendor. Skip it if you expect video generation to work out of the box, because the host ships no upstream video protocol and a plugin pack must be added first. Before committing, read docs/plugins/errors.md and confirm that the egress rule in permissions.hosts matches the endpoints your provider actually uses, and check whether the AGPL-3.0 network clause fits how you intend to run it.

Frequently asked questions

Official sources

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