LocalMiniDrama: a local AI short drama pipeline that stops at the API key

What LocalMiniDrama actually automates, and what it does not

The repetitive part of making an AI short drama is not generating one image. It is keeping a cast of characters visually consistent across dozens of shots, tracking which scene background belongs to which episode, and stitching the resulting clips into something watchable. LocalMiniDrama is built around that bookkeeping. The README describes an eight-step flow: story generation from a premise and style, script editing by episode, character extraction and portrait generation, scene extraction from the script, prop generation, storyboard generation with shot size and camera movement, per-shot image and video generation, and final composition into an episode file.

The word local in the name needs reading carefully. The README states that project data lives in SQLite plus local files and that assets are not uploaded to a cloud service. It does not claim that generation happens on your machine. Every image and every video comes from a remote provider you configure, and the provider table lists DashScope, Volcengine, Kling, Agnes AI, Gemini, Vidu, NanoBanana and OpenAI-compatible endpoints. So the privacy boundary is your project database and your media library, not the generation itself. If your prompts or your reference images are sensitive, they still leave the machine when a shot is rendered.

The intended user is a solo creator or a small team that already pays for model access and wants the pipeline around it. The README is explicit that you bring your own API key.

How the story, storyboard and video stages connect

The repository splits into four top-level pieces: backend-node, frontweb, desktop and docs. The backend is Node.js with Express and SQLite through better-sqlite3, and the README assigns it generation, composition and import/export. The frontend is Vue 3 with Vite, Element Plus, Pinia and @vue-flow/core, with views named FilmList, DramaDetail, FilmCreate and DramaCanvas. The desktop layer is Electron 28 packaged with electron-builder.

The canvas view at /film/:id/canvas is the part worth understanding, because it is not a separate data model. The README states that canvas mode and list mode share the same underlying data. A storyboard is drawn as a vertical pipeline, one row per shot. In the classic mode the row reads text, then first frame and last frame, then video. In the full mode the row is a single all-purpose storyboard prompt feeding video. Node panels let you edit or generate without switching to the list view, and node coordinates are persisted when you drag them.

Workflow groups are the batch mechanism. You box-select storyboards, create a workflow, and rerun the whole group with checkboxes for image, video and voice generation. That is a rerun primitive, not an incremental renderer, so a group rerun regenerates everything selected rather than only the shots that changed. The one-click pipeline behaves differently: the README says it skips content that already exists and retries each step up to three times to absorb rate limiting.

Installing LocalMiniDrama on Windows and rendering a first shot

The README recommends the packaged executable over a source build. Go to the Releases page and pick one of two files: the standard `本地短剧助手 x.x.x.exe`, which the README says includes a sample project and suits newcomers, or the Lite build, which is smaller and aimed at people who already know the flow. Double-click it, open the AI configuration screen, paste an API key, and start.

On first run the app writes its configuration to a fixed location. That path matters if you later wonder why a key change had no effect. The README gives it as `%APPDATA%\LocalMiniDrama\backend\configs\config.yaml`. The release notes for v1.2.8 state that the `upload_url` key, its 180-second default timeout and a retry count live in that same `config.yaml`, and that a cached image URL that has expired is re-uploaded automatically.

If you prefer to run from source, the README requires Node.js 18 or newer and gives two processes. The backend listens on port 5679 and the frontend on port 3013:

git clone https://github.com/xuanyustudio/LocalMiniDrama.git
cd LocalMiniDrama

# 后端（端口 5679）
cd backend-node && npm install
cp configs/config.example.yaml configs/config.yaml   # 填入 API Key
npm run migrate && npm start

# 前端（端口 3013，新终端）
cd frontweb && npm install && npm run dev

After the backend and frontend are running, open `http://localhost:3013` in a browser. The repository also ships `run_dev.bat` at the root, which the README says starts the development environment in one double-click.

A first real pass is short. Create a project, enter a premise and a style, generate the script, let the app extract characters and scenes, then generate one storyboard image and one video for a single shot before running anything in bulk. Generating one shot first tells you whether your video provider key is valid and whether the aspect ratio you picked (16:9, 9:16 or 1:1) matches what you intend to publish.

Where LocalMiniDrama breaks down

The honest limitation is the one the README does not hide but does not emphasize: there is no local model. If you have no API key for an image provider and a video provider, the app cannot produce a single frame. The provider table shows that image and video support is uneven. Kling, Gemini and Vidu are video or image only, NanoBanana is image only, and local Ollama and other OpenAI-compatible endpoints are text only. A text-only setup gives you scripts and storyboards and nothing else, which may still be useful but is not the product's promise.

The second limitation is Windows. The README's platform badge reads Windows, the quick-start section is built around an `.exe` download, and the first-run configuration path is a `%APPDATA%` location. There is a docs/quickstart.md that the README links as covering development, packaging and Docker, so a container path may exist, but the README itself does not present macOS or Linux as supported desktop targets. Treat a Linux desktop install as unverified until you read that document.

The third is cost and latency, which the design makes visible rather than hides. The retry logic exists because providers rate-limit. A one-click pipeline across a full episode is many image calls and many video calls, and video generation is the slow, expensive half. The failure mode that will bite a new user is a partially generated episode: some shots rendered, some failed after three attempts, and a composition step that has to be rerun after the gaps are filled. If your plan is a long series with a fixed budget, the per-shot cost is the number to estimate before you start, and the README gives you no estimator for it.

LocalMiniDrama compared with Toonflow and FilmAction AI

People searching for this project often arrive from Toonflow or FilmAction AI, and the difference is architectural rather than cosmetic. Toonflow and FilmAction AI are the names that appear alongside LocalMiniDrama in search results, and the pattern those tools follow is a hosted or bundled generation experience where the model choice is made for you. LocalMiniDrama inverts that. It is a workflow shell that holds no model of its own and instead asks you to configure text, image and video providers separately, with nine prompt categories you can override.

That inversion has a concrete consequence. With a hosted tool, the consistency of a character across shots is the vendor's problem. With LocalMiniDrama, consistency comes from the reference-image mechanism, the `@图片N` multi-image reference syntax and the last-frame chaining that the README lists under storyboard editing. You are responsible for whether shot 12 still looks like the character you approved in shot 2. The README's own sample videos, generated with 即梦 1.0, are presented as evidence that consecutive shots hold character appearance, which tells you the project considers this a headline capability rather than a solved detail.

The trade is control against convenience. LocalMiniDrama gives you provider choice, prompt-level control and a local project database. A hosted alternative gives you fewer decisions and, usually, less to configure. If you do not want to manage API keys, quotas and per-provider quirks, the hosted route is the better fit, and LocalMiniDrama will feel like overhead.

Maintenance, releases and what the MIT licence means here

The last push to the default branch was on 2026-09-14, and the repository is not archived. Recent tagged releases are v1.2.6 on 2026-04-12, v1.2.7 on 2026-06-02 and v1.2.8 on 2026-07-01. The cadence across those three is roughly two months between tags, with commit activity continuing between releases, and the v1.2.8 notes list Agnes AI integration, canvas enhancements, a ModelArk private asset library, configurable image hosting and prompt optimization.

Upgrade cost is low for the packaged build: download the new `.exe` and run it, and the README's first-run config path under `%APPDATA%` is outside the application directory, so it should survive a replacement. That also means the config is not versioned with the app, and a key or a `config.yaml` edit is a manual step you own. For a source build, the upgrade is a pull plus `npm install` in both `backend-node` and `frontweb`, and the README documents a `npm run migrate` step for the database, which is the part to watch when the schema changes between versions.

The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are included. That is a permissive licence, not a copyleft one, so a derived product does not have to be open sourced. This is a description of the licence text, not legal advice; if you plan to redistribute a modified build, read the LICENSE file and get your own counsel. One practical note for anyone packaging this commercially: the app depends on remote provider APIs whose own terms govern the generated media, and the MIT licence says nothing about those.

Editorial conclusion

LocalMiniDrama fits a solo creator or small studio on Windows who already holds API keys for at least one image and one video provider, and who wants the storyboard bookkeeping handled locally. It does not fit anyone expecting a bundled model or offline video generation, since every image and every video frame is produced by a remote provider. Before committing a real project, verify three things: that your chosen video provider is actually listed in the AI provider table, that the generated clips survive the final composition step at the aspect ratio you need, and that the config.yaml path under %APPDATA% is the one the app is reading.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. xuanyustudio/LocalMiniDrama on GitHub