# LingGuo-Drama: a workbench for assembling AI generated short drama from a script

> A Go and Vue 3 back office for short drama and motion comic production that chains script, characters, storyboard, image and video generation together, with Asynq carrying the slow work and FFmpeg doing the final cut.

**LingGuoAI/LingGuo-Drama** — 🎬 灵果短剧AI - 基于AI的一站式短剧/漫剧生成平台 《一句话生成完整短剧/漫剧，从剧本到成片短剧/漫剧全自动化》Lingguo-Drama AI-An AI-powered one-stop generation platform for mini-dramas and motion comics

- Repository: https://github.com/LingGuoAI/LingGuo-Drama
- Website: http://www.lingguoai.com
- Stars: 1,521 · Forks: 261
- Language: Go
- License: not declared
- Published: 2026-10-07 · Updated: 2026-10-07 · Language: en
- Canonical page: https://hysenlabs.com/projects/lingguoai-lingguo-drama

## One compose file brings up MySQL, Redis and the Go backend

The repository is small enough to read in one sitting: a `server/` directory, a `web/` directory, a `docs/` folder and two files at the root that carry the whole deployment story. There is no vendored framework, no generated client, no monorepo tooling file. What the project is, it is plainly, and the whole environment starts with a copy of the example env file and a compose build.

```bash
cp .env.example .env
docker compose up -d --build
```

The compose file defines four services. `mysql` runs the 8.4 image with utf8mb4 forced on the server charset and collation, `redis` runs 7.4 alpine with appendonly on and a password, `server` builds from `./server` with its own Dockerfile, and the web front end is served on port 80. Both datastores carry healthchecks, and the Go service declares `depends_on` with `condition: service_healthy`, which is the detail that makes the first start reliable. Migrations run at boot rather than as a separate step.

Those defaults are all named in `.env.example`, and the names are worth reading because they reveal how the project was assembled: the database is `spirit_fruit`, the containers are `spiritfruit-mysql` and `spiritfruit-server`, and the passwords are `spiritfruit_pass` and `spiritfruit_redis`. A project called LingGuo-Drama ships a MySQL database called spirit_fruit. Nobody went back and renamed these, which is harmless in a container but confusing when you are writing your own SQL or grepping a log line at midnight.

## The production chain from script entity extraction to the final cut

The README describes the creative workflow as a seven step chain, and unlike most project docs this one is a real pipeline description rather than a feature list. You create a project, write or generate a script, extract characters, scenes and props as separate entities, generate an image for each of them, split the script into shots, write a prompt per shot, generate a still and then a clip per shot, and finally merge the clips. Each step consumes the output of the previous one, which is the part that makes this different from calling an image API directly.

Character consistency is the reason to care about that structure. If every shot prompt is written from scratch, the person in frame nine will not look like the person in frame three. By extracting characters and props once and reusing their generated images as references downstream, the project gives you a place to hold identity steady across a whole production. The same logic applies to locations. That is a production workflow rather than a demo, and it is the strongest argument in the README.

Merging is done with FFmpeg, which the docs require you to install separately and put on `PATH`. The README asks for FFmpeg 4.0 or newer and shows the install command per platform:

```bash
brew install ffmpeg
```

FFmpeg 4.0 is a floor set two major versions ago. It is enough for concat and probing, and the repo does not promise more, but a project that shells out to a system binary inherits whatever codecs that build carries.

## Asynq and Redis keep the slow generation off the request path

Image and video generation takes seconds to minutes per shot. A hundred-shot drama would take hours if the HTTP handler waited on it, so the project uses Asynq, a Redis backed task queue, and splits into two processes: the API server and a worker. The `.env.example` reserves three separate Redis databases, `REDIS_MAIN_DB=1`, `REDIS_CACHE_DB=2` and `REDIS_ASYNC_DB=0`, which keeps queue traffic, cache entries and business data from colliding on key prefixes.

Both processes are Cobra subcommands of the same binary:

```bash
cd server
go mod download
go run main.go serve
```

and the worker separately:

```bash
cd server
go run main.go worker
```

That split is operationally meaningful. It means you can scale workers independently of the API, and it means a backlog is visible: `docker compose logs -f worker` is how you find out that 140 of your 180 shots are queued rather than failed. The README's contribution guidance names task state observability as a gap it wants help with, which is an honest signal that the retry and failure story is thinner than the happy path. Asynq has its own retry and priority model underneath, but the README does not document how this project configures either.

Database setup for a non-compose run is a single statement, and it carries the same utf8mb4 choice the compose file makes:

```sql
CREATE DATABASE spirit_fruit CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
```

## Default credentials and a missing licence file both need a second look

The README publishes the default administrator account in plain text, and it is `admin` / `123456`. On a laptop behind a firewall that is a reasonable convenience. Anywhere else it is a six character password guarding a database full of paid generation output and a set of API keys. The README does list changing it under its security notes, along with rotating `APP_KEY`, the database password and the Redis password before production.

The second thing worth reading twice is licensing. The repository metadata reports no licence identifier, while the README ends with a License section that says MIT. Those two facts do not agree. The text is short and points at no LICENSE file, and the tree confirms there is none at the root: just `.env.example`, `.gitignore`, `README.md`, `docker-compose.yml`, `docs/`, `server/` and `web/`. So you have a claim of MIT in prose and no license text to check it against. If you intend to run this inside a product, that difference matters enough to raise with the authors rather than assume the prose wins.

Both of these are easy to fix on your side and worth fixing early. Rotate the admin password, set a real `APP_KEY`, and keep API keys in the untracked `.env` the gitignore is there to protect.

## Provider keys decide which model you actually get

This project does not ship a model. It is a pipeline that calls someone else's. The env file names two sets of provider variables: an `AI_PROVIDER=openai` group with `OPENAI_BASE_URL`, `OPENAI_API_KEY`, `OPENAI_MODEL=gpt-4o` and `OPENAI_IMAGE_MODEL=dall-e-3`, and a `GETGOAPI_*` group pointing at `https://api.lingguoai.com/v1` with its own model and image model names. Video is a third axis, with `VIDEO_PROVIDER=getgoapi` and separate keys for `VOLCES_API_KEY`, `MINIMAX_API_KEY`, `RUNWAY_API_KEY`, `PIKA_API_KEY` and `VERTEX_API_KEY` alongside a `VERTEX_PROJECT_ID`.

The shape of that list tells you how extensible the backend is: several video vendors behind one variable, each with its own key, which implies a provider adapter layer rather than one hardcoded integration. It also tells you what it costs to run. Video generation is billed per second by every one of those vendors, and a hundred-shot production multiplied by retries is not a small number. There is no token budget, no spend cap and no cost accounting anywhere in the README.

The consequence is that the interesting engineering question is not which model is best but how much you are willing to spend when a batch re-runs. Because retries are invisible in the UI, the practical habit is to run the storyboard and image stages first, look at the frames, and only then pay for the video pass.

## Where the README stops and the docs folder starts

This README is unusually complete for the deployment path and unusually quiet about everything else. It covers compose startup, local development, per-platform FFmpeg install, version checks, backend and frontend commands, the environment variable table, the seven step creative chain and a security checklist. What it does not cover: backup and restore procedure, upgrade steps, how to migrate between AI providers once you have projects in the database, how task failures surface in the UI, or the API contract.

Most of those are one link away. Deployment, backup, update and troubleshooting commands live in `docs/deployment.md`, and a walk through the production chain with improvement notes lives in `docs/process-improvements.md`. The tree lists a `docs/` directory but the file set the repository exposes stops at the two root config files, so the API reference at `/docs/index.html` is likely a Swagger-style bundle generated by the Go server at runtime rather than a checked-in document. Worth confirming on your own instance.

For the front end, the dev server listens on 3002 and points at the backend through two variables:

```ini
VITE_API_URL=http://localhost:8080
VITE_API_URL_PREFIX=/admin/v1
```

The `/admin/v1` prefix and the presence of a separate admin app suggest the API is versioned and that an end-user facing client would be a different surface, but the README does not describe one. Stack-wise this is Go with Gin, GORM and Cobra behind Vue 3, Vite, TDesign and Pinia, with MySQL 8, Redis 6, FFmpeg 4 and Nginx for the edge. The last push was on 2026-08-21 and the repository has no GitHub releases, so there is no version to pin and no upgrade notes to read. For a project you intend to deploy, that is the gap to watch.

## Conclusion

LingGuo-Drama is worth a look if your real problem is orchestration rather than generation: keeping characters visually consistent across shots, tracking which of two hundred storyboard frames are still rendering, and joining the results into a file a person can watch. The pieces it does not supply are the ones most buyers assume they get: no model of your own, no licence file at the repository root, and a default admin password of 123456 that has to change before anyone else can reach the instance. Read the Docker deployment guide under docs/ before the first production deploy, because the README only covers the happy path, and decide which VIDEO_PROVIDER key you will actually fund before you generate anything, since the generated bill lands on that account and nothing else in the project holds the money.

## FAQ

### What is LingGuo-Drama and who is it for?

It is a Go and Vue 3 back office for producing AI generated short drama and motion comics, built for teams that want a second-development foundation for an AIGC video pipeline rather than a one-off generation script. It expects you to bring your own model API keys and your own FFmpeg install.

### How do you start LingGuo-Drama locally?

Copy `.env.example` to `.env` and run `docker compose up -d --build`, which brings up MySQL, Redis, the Go backend on port 8080 and the web front end on port 80. GORM AutoMigrate runs on first boot and seeds the default admin account, with health and readiness endpoints at `/healthz` and `/readyz`.

### What license does LingGuo-Drama use?

The README states MIT in its License section. The repository metadata reports no license identifier and there is no LICENSE file at the repository root, so the prose claim and the repository itself disagree. Confirm the intended terms with the authors before shipping it inside a product.

## Sources

- [Issues](https://github.com/LingGuoAI/LingGuo-Drama/issues)
- [LingGuoAI/LingGuo-Drama on GitHub](https://github.com/LingGuoAI/LingGuo-Drama)
- [Project website](http://www.lingguoai.com)
- [README](https://github.com/LingGuoAI/LingGuo-Drama/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/lingguoai-lingguo-drama