VOZEB PRO: a self-hosted AI creation workbench for agents, canvas and short-drama pipelines

What VOZEB PRO actually replaces

Most AI media stacks end up as three disconnected tools: a chat UI for prompting, a node editor for image work, and a folder of scripts for video assembly. VOZEB PRO's README describes one Next.js full-stack application that holds all of them, plus the accounts, credits and admin screens that usually get bolted on later. The stated scope is a unified creation agent that handles text, image, video and audio in the same session, a canvas with text, image, video, audio and generation nodes, a short-drama production line covering script, review, storyboard, shot generation, voice-over, subtitles and FFmpeg composition, and a commercial backend with users, plans, coupons, credits, CDK codes, orders, refunds and audit logs.

The intended user is not an individual hobbyist. The README lists enterprise production deployment, commercial operation, SaaS service, private deployment and resale as activities that require a commercial licence, which tells you the assumed operator is a team running this as a product or an internal studio tool. If you only need one endpoint that turns a prompt into an image, this is far more surface area than the problem requires.

How the agent, worker and provider routing fit together

The flow diagrams in the README make the generation path explicit. A user submits text or reference material to /create, picks a Skill, intelligent planning or a logical model, sets image, video or audio preferences, and the server validates capability, assets, parameters and credits. A logical model router then picks the upstream provider and creates an idempotent generation task. The app calls the upstream, polls that same upstream task, and on success downloads and normalises the media before registering ownership and a stable address and returning the result to the session.

Two design choices stand out. First, the router sits between the user's chosen logical model and the real model, so administrators maintain channels, protocols, real models, logical models, capabilities, priorities and defaults from the backend. The README names OpenAI, Gemini, Seedance 2.0, Stable Diffusion, A1111/Forge and declarative custom protocols as covered. Second, persistence lives in a separate Worker. The README states the Worker continues to query the original upstream task after the page is closed or the instance switches, and that failed tasks are reviewed in generation operations. That is the right split for long video jobs, but it also means the app container alone is not a complete deployment.

Installing VOZEB PRO with Docker Compose

The repository root ships several Compose files: docker-compose.yml, docker-compose.local.yml, docker-compose.lowmem.yml, docker-compose.external-db.yml and docker-compose.baota.yml. The default file pins the app image to ghcr.io/csyqlz/vozeb-pro:v0.0.7 and brings up PostgreSQL 16.6-alpine alongside it. The .env.example instructs you to copy it to .env in the repository root for Docker, or to web/.env.local for source development with the database host changed to localhost.

Four secrets are mandatory before the stack will start. Compose marks POSTGRES_PASSWORD, VOZEB_PRO_ENCRYPTION_KEY, VOZEB_PRO_INSTALL_TOKEN and VOZEB_PRO_MAINTENANCE_TOKEN as required, and VOZEB_PRO_WORKER_TOKEN as a separate token. The comment in .env.example says the encryption key must be 64 hexadecimal characters or exact 32-byte Base64, generated once with openssl rand -hex 32 and kept stable.

cp .env.example .env
openssl rand -hex 32   # VOZEB_PRO_ENCRYPTION_KEY
openssl rand -hex 32   # VOZEB_PRO_INSTALL_TOKEN
openssl rand -hex 32   # VOZEB_PRO_MAINTENANCE_TOKEN
openssl rand -hex 32   # VOZEB_PRO_WORKER_TOKEN
docker compose up -d

The app container binds 127.0.0.1:3000 by default, so it is not exposed to the network until you put a reverse proxy in front of it. Its healthcheck calls http://127.0.0.1:3000/api/health/live.

First-run setup happens at /install. The README's flow diagram shows the wizard checking the runtime environment and PostgreSQL, initialising the database schema, then creating the first administrator. The .env.example notes the install token is required only until the first administrator exists and should be removed afterwards.

# open in a browser, complete the wizard, then remove the token
# http://localhost:3000/install

After installation you land in the commercial admin backend, where model channels and protocols are configured before any generation will succeed.

Where VOZEB PRO gets in your way

The licence is the first constraint, and it is not a formality. The README states the project uses Business Source License 1.1 and that enterprise production deployment, commercial operation, SaaS service, private deployment, providing services to third parties, resale, or integration into a paid platform all require prior commercial authorisation. Permitted uses are personal study, non-commercial research, development testing, evaluation, code review and community contribution. The repository metadata also reports the licence as NOASSERTION, which means automated licence tooling may not classify it cleanly; read LICENSE and COMMERCIAL_LICENSE.md rather than trusting a scanner.

A second constraint is operational weight. The Dockerfile installs ffmpeg, fonts-noto-cjk and postgresql-client into the runtime image, and the runtime sets NODE_OPTIONS=--max-old-space-size=384 with UV_THREADPOOL_SIZE=2. That is a deliberately small memory budget, and the existence of docker-compose.lowmem.yml suggests the default configuration is not the only tuning path. Short-drama composition through FFmpeg is CPU-bound and will compete with the web process on a single small host.

The wrong-tool cases are clear. If you want a library to call from your own code, this is an application, not an SDK. If you need a managed service with no server to run, this is the opposite of that. And if your workflow is a single model with a single prompt template, the routing layer, credit ledger and moderation screens are overhead you will maintain without using.

How it differs from wiring ComfyUI and a chat UI together

The obvious comparison is a stack of ComfyUI for node-based generation plus a separate chat front end plus a folder of FFmpeg scripts. The difference is where state lives. ComfyUI graphs are files on disk and its API surface is a queue; VOZEB PRO keeps canvas projects, generation tasks, assets, credits and audit records in PostgreSQL, with media in a local directory or S3-compatible object storage as the README describes.

That changes what survives a restart. With a file-based graph tool, a long video job that outlives the browser session is your problem. VOZEB PRO's README states the independent Worker re-queries the original upstream task after the page closes or the instance switches, and that abnormal tasks are handled in generation operations. The trade is that you now operate a database and a second process, and your provider credentials are managed through an admin UI rather than a local config file.

The canvas is also narrower than a general node editor. The README lists text, image, video, audio and generation nodes with drag, connect, zoom, undo/redo, import/export and Canvas Agent Run. It does not claim the breadth of custom node ecosystems that ComfyUI users expect. If your pipeline depends on community nodes, this is not a drop-in replacement.

Maintenance, upgrades and the licence boundary

The last push to the default branch was on 2026-09-15, and the most recent release in the repository is v0.0.7 from 2026-08-22, following v0.0.6 on 2026-08-15 and v0.0.5 on 2026-08-04. The repository is not archived. That release cadence is worth noting when you plan upgrades: three tagged releases inside three weeks means the surface is still moving, and pinning VOZEB_PRO_IMAGE to a specific tag rather than tracking a moving reference is the safer default, which is also what the Compose file does.

The Dockerfile copies VERSION and CHANGELOG.md into the image, and package.json exposes two scripts, licenses:generate and licenses:check, which regenerate and verify THIRD_PARTY_LICENSES.md. If you redistribute anything built from this repository, run the check script rather than assuming the file is current.

On licence cost: the README's table lists an annual closed-source enterprise licence for one entity and one self-operated product covering that entity's development, test and production environments for one year, a perpetual variant for a named version, and a separate written agreement for OEM, white-label or third-party delivery. It states explicitly that the commercial licence covers software use only and excludes technical support, deployment, custom development, operations, maintenance and SLA services. That is a real budget line if you expect vendor help. I am not a lawyer and this is not legal advice; the binding terms are in LICENSE and COMMERCIAL_LICENSE.md.

Editorial conclusion

Adopt VOZEB PRO if you need a single self-hosted surface that covers agent chat, a node canvas, a short-drama pipeline and the billing and moderation screens around them, and you are prepared to pay for a commercial licence before any production deployment. Do not adopt it if you only want a thin image-generation API wrapper, if your team cannot operate PostgreSQL 16 plus a separate worker process, or if you need to fork and resell the code without a written OEM agreement. Before committing, verify three things: the exact BUSL-1.1 terms in LICENSE and COMMERCIAL_LICENSE.md against your deployment model, that your model providers are reachable from the server because the README states model, payment and storage keys are used server-side only, and that the worker process is running, since the README states a separate Worker picks up image, video, audio and agent tasks after the page is closed.

Frequently asked questions

Official sources

1. csyqlz/VOZEB-PRO on GitHub
2. Issues
3. README
4. Releases