AID Studio: self-hosted AI drama and motion comic creation

What AID Studio actually organises

The problem AID Studio addresses is asset sprawl. A short AI drama needs a script, a cast of characters with consistent faces, scene references, a storyboard, per-shot image and video prompts, and voice tracks. Most teams assemble that from a chat window, an image generator, a video generator and a TTS service, then keep track of which output belongs to which shot in a spreadsheet. AID Studio puts those steps in one project record. The README describes the core as AI drama and short drama creation, with film-style shorts and static comics as the other two directions, and states that scripts, episodes, assets and generated results are managed in the same project.

The intended user is a small studio or an individual creator with server access. The README says teams and developers can deploy it themselves and configure models. That is the audience: someone who will run a Linux box, hold API credentials for several model vendors, and accept that generation quality depends on the models they pick, not on the platform. The repository is Java, split into aid-admin, aid-business, aid-common, aid-consumer and aid-interface modules, so a Java team can read and extend the backend rather than treat it as a black box. The README also notes two separate entry points, a flow-based creation path and a flow canvas, so the same project can be driven by a linear wizard or by a visual graph. The canvas is the one shown in the repository's product screenshot.

How the provider layer, task queue and asset model fit together

The architecture visible in the README is a provider abstraction plus a task system. Text, image, video and speech models are reached through what the README calls a unified Provider, and the capability set is configurable per model: resolution, duration, aspect ratio, and the number of reference images a model accepts are all validated against the model's declared ability rather than assumed. That matters for a storyboard tool. If a shot asks for a 10-second clip at a ratio the selected video model does not support, the platform checks the request against the model's capability before dispatch. The README also mentions an API gateway configuration, where a model's access address and credentials can be set per compatible protocol, with per-model exceptions allowed.

The second mechanism is the task system. Generation work is queued, dispatched with a concurrency policy, pushed as progress, retried on failure, compensated when something goes wrong, and the result is collected back. This is the part that decides whether the tool is usable at scale: image and video generation are slow and rate-limited, so a queue with retries is the difference between a batch of twenty shots finishing overnight and failing halfway. The README lists failure retry and compensation as separate items, which implies the platform distinguishes a transient provider error from a task that needs to be reconciled.

The third piece is visual consistency. Characters, props and scenes are stored as reusable assets, and a project can hold a style snapshot. Reference images are then arranged according to each model's capability, which is the README's phrase for the reference image placeholder protocol that image generation uses. In practice that is how a character keeps the same face across shots: the asset is reused as a reference rather than re-described in every prompt. The README does not document how the style snapshot is versioned or what happens when a character asset is edited after shots have been generated, and that gap is worth knowing about before you build a long episode.

Installing AID Studio on a fresh Linux server

The README targets production deployment on a new 64-bit Linux server. Its stated floor is 2 cores, 4 GB of memory and 40 GB of disk when RocketMQ is not enabled and middleware runs on the same machine. The install path is a shell script downloaded to /root/aid-install.sh, preferring Gitee and falling back to GitHub. This is the command from the README, reproduced as given:

cd /root && if command -v curl >/dev/null 2>&1; then curl -fL --retry 3 --connect-timeout 15 -o /root/aid-install.sh https://gitee.com/gzxx-2025/aid-studio/raw/master/deploy/aid.sh || curl -fL --retry 3 --connect-timeout 15 -o /root/aid-install.sh https://raw.githubusercontent.com/gzxx-2025/aid-studio/master/deploy/aid.sh; elif command -v wget >/dev/null 2>&1; then wget -O /root/aid-install.sh https://gitee.com/gzxx-2025/aid-studio/raw/master/deploy/aid.sh || wget -O /root/aid-install.sh https://raw.githubusercontent.com/gzxx-2025/aid-studio/master/deploy/aid.sh; else echo '请先安装 curl 或 wget'; exit 1; fi && sudo env AID_REMOTE_BOOTSTRAP=1 AID_RELEASE_CHANNEL=auto bash /root/aid-install.sh install

The two environment variables decide how the installer bootstraps itself. AID_REMOTE_BOOTSTRAP=1 tells it to fetch from the remote release channel, and AID_RELEASE_CHANNEL=auto prefers a stable release and falls back to beta only when no stable build is installable. The README says to use stable to pin the stable channel, and beta only when you deliberately want a prerelease. The install subcommand is described as a smart entry: on an undeployed machine it runs the Docker first-time install, and on an already deployed machine it switches to an update check. To be explicit about the method, install-docker and install-manual are separate subcommands.

The first run generates configuration and stops. The README is direct about this: it will not pull the unified source, build, initialise the database or start services until the configuration is confirmed. Docker deployments keep their configuration in /data/aid/config/docker.env; manual deployments use /data/aid/aid-deploy.conf. After the install, one command shows where the app is:

sudo aid default

That prints the public and internal user-facing and admin addresses plus the initial account notes. The README instructs you to change the administrator password immediately on first login, then configure and enable the models you need in the admin area. Only then does the first-project walkthrough apply: prepare a short script, create an episode, organise characters and scenes, generate or upload reference images you have the rights to use, complete one storyboard with its script and image, generate a clip with a configured video model, and add voiceover if you want it. The README notes that a static comic skips the video and voiceover steps entirely. Day-to-day management goes through one command, sudo aid, with subcommands for status, logs, config, restart, update, progress, rollback, backup, mysql and uninstall.

Where AID Studio will cost you time

The platform does not generate anything by itself. The README states plainly that AI generation requires API credentials from the relevant providers, and that model calls, servers and storage may incur costs. So the first real constraint is that a working AID Studio install is a shell until you have contracts or accounts with a text model, an image model, and, for drama rather than comics, video and speech models. The README also says capability follows the selected model, which is a polite way of saying that if your chosen image model accepts one reference image, the visual consistency features are limited by that.

RocketMQ is the second constraint. It is optional, but the resource table shows the difference: 2 cores and 4 GB without it, 4 cores and 4 GB with it on a local Docker stack, and the README recommends 6 cores and 12 GB for higher message volume. The 4-core 4-GB RocketMQ minimum is described as suitable only for local setup and functional validation, with tightened JVM and MQ parameters. If you enable the message queue on a small box expecting production throughput, that is a misconfiguration the README warns about rather than a bug.

Storage is the third. The README strongly recommends object storage such as OSS or COS for media files, with local disk as a fallback only. Video generation produces large files, and a 40 GB disk will fill quickly once you are iterating on shots. HTTPS is the fourth: enabling it requires a user domain, an admin domain, port 443, and a full certificate chain with private key, kept by default in /data/aid/config/ssl/. The README explicitly notes that setting HTTP_PORT=443 alone does not turn on TLS, which is the kind of detail people discover after a failed deploy.

Finally, the README documents rollback as a command, sudo aid rollback, which selects from historical versions the project allows returning to. It does not document what happens to data written by a newer schema version when you roll back, so treat rollback as a program-version operation and verify your own backup before relying on it. The README does document sudo aid backup for creating a deployment backup, and uninstall --keep versus uninstall --purge for preserving or clearing data.

How AID Studio differs from calling model APIs directly

The obvious alternative is not a competing product but the underlying services. If you need one image, you call an image API. If you need one clip, you call a video API. That path has no server, no queue and no deployment, and for a single asset it is less work than AID Studio by a wide margin. The difference in approach is state. Direct API calls leave no project record: the prompt for shot seven lives in your notes, the reference image lives in your downloads folder, and the voice track lives in a TTS dashboard. AID Studio's contribution is the record and the queue, not the generation.

A second comparison point is the two entry paths inside AID Studio itself. The README describes flow-based creation and the flow canvas as independent entries, chosen by habit. A linear wizard suits an episode where the order is fixed: script, then characters, then storyboard, then shots. The canvas suits work where you want to branch and reorder, which is closer to how a director plans coverage. Neither is documented as strictly better, and the README does not state that the two share the same underlying project state, so if you plan to switch between them mid-episode, confirm that before you build a workflow around it.

A third alternative is a general workflow automation tool wired to the same model APIs. That gives you arbitrary orchestration, and it is genuinely more flexible for unusual pipelines. What it does not give you is the domain model: a character asset with bound voice, a storyboard workbench that splits shot groups and emits video prompts, or a billing layer with balance freezing and settlement. The README lists those as platform capabilities, and they are the reason to pick this over a generic graph tool. The trade-off is that you inherit the project's opinions about how a drama is structured.

Licence, upgrade path and what maintenance looks like

The source is provided under the MIT licence, per the README and the LICENSE file in the repository root. MIT is permissive: you can use, modify and redistribute the code, including commercially, provided the copyright notice and permission notice are preserved. The NOTICE file in the root suggests there may be additional attribution requirements, and the README's own disclaimer is that AI generation needs provider credentials and that model calls, servers and storage may cost money. None of that is legal advice; if you are embedding AID Studio in a product, read LICENSE and NOTICE yourself.

Upgrades are handled by the platform rather than by hand. The README describes an independent updater, aid-updater, with page-level and command-line update checks, live progress, and rollback, plus sudo aid progress for real-time status and sudo aid update for checking and applying the current channel update. Releases are frequent: v2.1.5, v2.1.6 and v2.1.7 all landed on 2026-09-15 and 2026-09-16. Frequent releases mean the upgrade path is exercised, but they also mean you should read release notes before jumping, and the README's rollback command exists precisely because an update can go wrong.

The maintenance picture from the repository facts is straightforward. The repository is not archived, and the last push was on 2026-09-16, the day before this article. That is a project under current development. The cost side is what the README does not remove: you own the server, the middleware, the object storage, the certificates, and the model bills. The installer can reuse existing dependencies of a matching version and writes full logs to /data/aid/logs/, which is where you will look when something fails. The README does not document a managed hosting option, so the operational burden stays with you.

Editorial conclusion

Adopt AID Studio if you already run Linux servers and want script, storyboard, image, video and voiceover assets to live in one project rather than across four SaaS accounts, and if you accept that model API spend, storage and the 2 core / 4 GB floor are yours to cover. Do not adopt it if you want a hosted tool with no server, or if you only need one-off image generation, where a single model API is less work. Before committing, verify three things on your own machine: that the deployment configuration at /data/aid/config/docker.env is confirmed before the installer starts services, that your chosen text, image, video and speech models are actually selectable in the admin model list, and that sudo aid rollback lists a version you are willing to return to.

Frequently asked questions

Official sources

1. gzxx-2025/aid-studio on GitHub
2. License: MIT
3. Project website
4. README
5. Releases