waoowaoo: a self-hosted AI film workspace that ships as Docker images, not an npm package

The gap waoowaoo is trying to fill: a project canvas instead of a prompt box

Most generative video tools give you a text field and a result. The iteration loop lives outside the tool, in a folder of downloads and a chat window. waoowaoo's README describes something different: an AI creative workspace where you develop an idea with a right-hand Assistant, upload reference material, and then organise and refine the output on a canvas. The unit of work is an ongoing project, not a single generation. That distinction matters for anyone producing short drama or storyboard-driven content, where the same character or location has to recur across many shots. The repository topics list short-drama and storyboard alongside video-generation, which fits that reading. It is also the reason the install is heavy. A canvas that keeps versions, references and generated media in one place needs durable execution and object storage behind it, and the stack reflects that: Temporal for durable execution, Redis for transport and cache, MySQL through Prisma, and private MinIO over S3. The intended user is someone who wants the whole production surface on their own hardware rather than a per-seat SaaS account.

How the canvas, the Assistant and the model layer fit together

The README splits the product into five capabilities. You work with the Assistant to develop a brief and create assets inside an ongoing project. You upload reference material, organise files, and inspect generated images and videos on the canvas. Generation is model-aware: aspect ratios, durations, resolutions and reference roles change with the selected model. Modes include first-frame, first/last-frame, and reference-image, and availability depends on the model you picked. Finally, you can refine an existing result into a new version while retaining the original, so the canvas accumulates lineage rather than overwriting. The model layer is OpenRouter. The preview names GPT Image 2, Nano Banana variants, Seedance variants, and MiniMax H3 and H3 Max. Two constraints are stated plainly. H3 Max accepts a single first frame in this application, not a first/last-frame pair, so the model's own capability is wider than what waoowaoo exposes. And music and voiceover controls are not included in this preview at all. Data flow runs through your own infrastructure: project data and media sit in a local database and private MinIO storage, while prompts and references are sent to the provider for the tasks you request. Inline image references do not require a public media URL, which removes the need to expose your MinIO bucket to the internet just to pass a reference into a generation.

Installing the preview: a Docker Compose release with Caddy in front

The recommended path is prebuilt Docker images. The README states you do not need Node.js, MySQL, Redis, Temporal or FFmpeg on the host for this route, because application dependencies run in containers. The quick start is not a shell script; it is a block of text you paste into a local coding assistant with terminal access. That block instructs the assistant to read the repository README, docs/INSTALL.md and the selected GitHub Release, then pin both the application and the Codex runtime to the release's immutable image digests. It also names concrete configuration. The default Compose HTTPS entry is SELF_HOSTED_HOST=localhost with SELF_HOSTED_HTTPS_PORT=1443, and APP_HOST_PORT=13000 only redirects HTTP. The overlay derives NEXTAUTH_URL, and Caddy's /data and /config named volumes must be preserved. docker/caddy/Caddyfile comes from the same release. After launch you open your profile's API configuration and add your OpenRouter API key there; the README explicitly says not to put the key in chat or support logs, and provider calls are billed to your own account. Source development is separate and stays at http://localhost:3001 via npm run dev. If you prefer to do it by hand, docs/INSTALL.md is the reference for manual setup, source builds, backups and upgrades.

The local certificate is the part that will stop you

The install block is unusually blunt about TLS, and that is a fair signal of where first attempts fail. It tells the assistant to export only root.crt, explain the trust implications, and get explicit approval before helping you trust it on the browser's host OS, noting that Windows trust is separate from WSL. It forbids exporting root.key and forbids bypassing TLS checks. It then asks you to verify that https://localhost:1443 shows no certificate warning and that the browser actually uses h2, including event streams across multiple tabs. That last check exists because the app uses server-sent events, and the block adds a warning that SSE tab concurrency is not the AI task concurrency limit. In other words, opening many tabs can exhaust browser-level connection limits before it touches your generation queue. If you skip the trust step, the browser will refuse the connection or fall back in ways that break the event stream, and the app will look broken when the problem is a certificate. A second, quieter failure mode is platform support: the block instructs the assistant to explain the blocker rather than claim success if the release lacks a required image or your CPU architecture is unsupported. That is a realistic outcome for arm64 machines if a release publishes only one architecture.

Elastic License 2.0 changes who can use this

Starting with v0.5.0-beta.1 the distribution is licensed under Elastic License 2.0, and the README states this directly: personal use, internal business use, modification and redistribution are permitted subject to its terms, while providing third parties with hosted or managed access to a substantial set of the software's features requires separate permission. Earlier releases retain their original licenses, and third-party components keep theirs. The README also says in plain terms that this is source-available software, not OSI-approved open source. For a team evaluating waoowaoo as the base of a commercial hosted product, that clause is the whole decision. Internal use inside a company is covered; running it as a service for customers is not, without separate permission. The repository's licence field reads NOASSERTION, which is consistent with a licence that GitHub does not auto-detect. This is a description of what the README states, not legal advice; if your use sits near the hosted-access boundary, read the LICENSE file in the release you pin.

Maintenance cost and the upgrade path you are signing up for

The release history shows v0.4.0 and v0.4.1 in April 2026, then a jump to v0.5.0-beta.1 in September 2026 with the label Self-hosted preview. The README carries a preview warning: the team is iterating rapidly and some bugs and rough edges remain. Combined with the pinned-digest instruction, that shapes the maintenance model. You are not tracking a rolling latest tag; you pin a release, its image digests and its Caddyfile together, and you move when a new release appears. Because MySQL, Redis, Temporal and MinIO all run in containers, upgrades touch stateful services, which is why the README points at docs/INSTALL.md for backups and upgrades rather than describing them inline. The contribution policy adds a second kind of cost: the project is maintained by the core team, issues for bugs and feature suggestions are welcome, and pull requests are accepted for reference only, since the team implements changes internally rather than merging external PRs. If your workflow depends on patching the source yourself, you will be maintaining a fork against a moving upstream.

Where waoowaoo is the wrong tool, and what to compare it against

Two cases should send you elsewhere. If you want a library you can call from your own pipeline, waoowaoo is the wrong shape: it is a deployed web application with a database, a queue and an object store, not an SDK. If you need OSI-approved open source or plan to offer hosted access to its features, Elastic License 2.0 rules the current release out without separate permission. For a concrete alternative, consider ComfyUI, the node-graph interface built on a local Python runtime. The difference in approach is structural. ComfyUI gives you a graph of nodes you wire yourself, running against local model weights, with no database, no Temporal worker and no Caddy certificate to trust; you install Python packages and load models from disk. waoowaoo gives you a fixed project canvas with an Assistant, a managed model list routed through OpenRouter, and durable execution so long generations survive a page reload. ComfyUI asks you to design the pipeline and own the model files. waoowaoo asks you to run five stateful services and pay per call through your own OpenRouter account. Neither is a superset of the other, and the choice is really about whether you want to author the workflow or operate a product.

Editorial conclusion

Adopt it if you want a private, self-hosted canvas for AI image and video work and you are willing to accept a beta with a Chinese and English UI, no music or voiceover controls, and paid OpenRouter calls on your own key. Do not adopt it if you need OSI-approved open source, if you intend to resell hosted access to its feature set, or if you cannot run Docker Compose v2 and trust a locally generated root certificate. Before committing, read docs/INSTALL.md against the release you pin, confirm the immutable image digests exist for your CPU architecture, and verify that https://localhost:1443 negotiates h2 across several open tabs before you start any paid generation.

Official sources

1. Issues
2. README
3. Releases
4. waooAI/waoowaoo on GitHub