# OpenCue: an open source render manager for VFX pipelines

> OpenCue is an Apache-2.0 render management system from the Academy Software Foundation that breaks production work into tasks and dispatches them to a render farm. It now runs as a set of Docker Compose services, with a Rust worker, a Flyway-migrated database and optional monitoring and event streaming stacks.

**AcademySoftwareFoundation/OpenCue** — A render management system you can deploy for visual effects and animation productions.

- Repository: https://github.com/AcademySoftwareFoundation/OpenCue
- Website: https://docs.opencue.io
- Stars: 1,006 · Forks: 271
- Language: Python
- License: Apache-2.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/academysoftwarefoundation-opencue

## What a render manager does for a studio

OpenCue is a render management system for visual effects and animation production. The README describes the core job: breaking complex jobs down into individual tasks and submitting them to a configurable dispatch queue that allocates the necessary computational resources.

The features list gives the shape of the system. Rendering happens on a central farm rather than on the artist's workstation, so a laptop that cannot render a shot still takes part in the work. A tagging system lets specific jobs be routed to specific machine types, which matters as soon as a frame needs a GPU, a large memory footprint or a specific renderer. Hosts can be split into a large number of procs, each with its own reserved core and memory requirement, and there is no limit on the number of procs a single job can hold. Integrated automated booking removes the manual step of reserving capacity, and native multi-threading supports Katana, Prman and Arnold.

Deployment is not tied to one data centre. The README lists support for multi facility, on-premises, cloud and hybrid deployments, and the first item in the feature list is a case study on the Sony Pictures Imageworks in-house render manager being used on hundreds of films.

The project is Apache-2.0 licensed, hosted by the Academy Software Foundation, and carries CII best practices and VFX Platform 2021 to 2024 badges. The last push to the repository was on 2026-10-19.

## The service map: cuebot, rqd, flyway and the database

The compose file in the repository root documents the architecture better than any diagram, because it lists every service and groups them into profiles.

The default profile is the core: db, flyway, cuebot and rqd, with the file noting that rqd is written in Rust. Flyway handles the database schema migrations, cuebot is the core service, and rqd is the process that actually runs work on a render host. The repository tree confirms the split, with a rust/ directory for the worker and separate cuebot/, rqd/, cueadmin/, cuecmd/, cuegui/, cueman/, cuenimby/ and cuesubmit/ directories for the server side and the command line and graphical clients.

The next profile, cueweb, adds rest-gateway and cueweb, described in the compose header as the web-based interface for monitoring and managing OpenCue. The gateway exists as a separate service rather than as part of the web interface, which is what allows the browser client to talk to it over a stable internal address.

That separation shows up in practice. The compose header documents a troubleshooting note for CueWeb returning an ECONNREFUSED error on the job API, caused by CueWeb having localhost:8448 baked in instead of the rest-gateway address, so the gateway address is a configuration value rather than a constant.

## Procs, tags and the dispatch queue

The unit of scheduling in OpenCue is the proc, a share of a render host with its own reserved core and memory requirement. Splitting hosts into many procs is what makes a heterogeneous farm schedulable: a host with a large GPU can be cut into pieces that suit different kinds of shot work rather than being reserved whole.

Tagging is the other half. Because jobs carry tags, the dispatch queue can match them to machine types, so a task that needs a particular renderer, a particular memory size or a particular licence ends up on a host that can actually run it.

The queue is configurable, and there is no ceiling on how many procs one job can occupy, which is what makes it possible to model a very large scene as a single logical job that fans out across the farm.

The samples directory ships worked examples for each client library and for rqd, and the sandbox documentation describes an environment where every component runs in a separate Docker container or Python virtual environment. That sandbox is the recommended path for anyone evaluating the system, since it avoids building a full deployment to find out how the pieces fit.

## Running a local instance with Docker Compose

The quick start in the README is short enough to run before reading anything else. It asks for two directories to exist, then starts the core services and checks their state:

```bash
# Prerequisites
mkdir -p /tmp/rqd/logs /tmp/rqd/shots

# Start core services (db, flyway, cuebot, rqd)
docker compose up -d

# Check status
docker compose ps
```

The two directories are not incidental. They are where the render worker writes its logs and its thumbnail shots, and they sit under the temporary directory because the quick start is meant to be disposable.

The optional components are selected by profile, and the compose header recommends stopping everything with the all profile rather than the default one, so that nothing is left running:

```bash
# Enable Web UI and monitoring
docker compose --profile cueweb --profile monitoring up -d

# Enable all services
docker compose --profile all up -d

# Stop all profiles (recommended to ensure everything is brought down)
docker compose --profile all down
```

Before starting, the compose file suggests validating the configuration with docker compose --profile all config, which is the same command that catches a malformed profile or an unset port before anything is created.

## Monitoring and event streaming are opt-in profiles

Two profiles cover observability, and the difference between them is worth understanding before you pick one.

The monitoring profile adds db-exporter, prometheus, grafana and loki. That is metrics scraping plus dashboards plus log aggregation, which is enough to see how much work the farm is doing and whether anything is failing.

The monitoring-full profile adds zookeeper, kafka, kafka-ui, elasticsearch, kibana and a monitoring-indexer on top of that stack, which the compose header labels event streaming and historical data. That is a much heavier deployment: a message broker, a search cluster and an indexer, in addition to everything the monitoring profile already pulls in.

The pragmatic advice is to run the monitoring profile while you evaluate the system and to add monitoring-full only when you have a question that needs historical event data answered. The all profile exists for convenience, but it starts a Kafka cluster and an Elasticsearch cluster on a laptop, which is where first contact with a system like this usually goes wrong.

The compose header also names the individual pieces in plain terms, which is a rare and useful courtesy in a compose file: the web UI for monitoring and managing OpenCue, monitoring for metrics and logging, and event streaming for event streaming and historical data.

## Client libraries and the wider tree

OpenCue is a server plus a family of clients, and the tree shows both the Python and the native parts.

pycue and pyoutline are the Python client libraries, with samples for each under samples/. pycue is the API client, pyoutline is the outline format that describes a shot as a tree of tasks and layers, and between them they cover the pattern of building work and submitting it to the queue. A proto/ directory suggests a protobuf-based interface as well, and samples/licensing/ points at the licence management area that a commercial studio needs.

The command line tools are separate directories: cueadmin for administration, cuecmd for the command line, cuegui for the graphical client, cueman for managing hosts and procs, cuenimby for the cost and usage accounting side, and cuesubmit for submitting work. Splitting them out means a farm can deploy only the binaries it needs on a render host.

The repository also carries api_docs/, a ci/ directory and sonar-project.properties, plus tsc/ for the technical steering committee, whose meeting notes moved to the ASWF Confluence page in May 2024, with earlier notes kept in the opencue/tsc/meetings folder in the repository.

## Documentation, releases and how the project is run

Documentation is built with Jekyll and hosted on GitHub Pages at docs.opencue.io, covering installation, user guides, API references and tutorials. Contributors are asked to update the documentation along with any feature change, and the docs build is verified before a pull request is submitted:

```bash
./docs/build.sh
```

For local preview, the docs directory is a standard Jekyll project with bundler binstubs:

```bash
cd docs/
bundle exec jekyll serve --livereload
```

Once a pull request lands on master, the documentation is deployed automatically through a GitHub Actions workflow, so the published site tracks the repository rather than lagging behind it.

The release history shows an active project with a wide version range. The recent tags are v1.34.22 from 2026-10-07, v1.19.1 from 2026-04-08 and v1.13.8 from 2025-10-08, so patch releases are frequent and the minor version moves quickly.

Day to day, the project runs on the ASWF Slack in the #opencue channel, with the working group meeting every two weeks on Zoom and a user mailing list for questions from admins and users.

## Conclusion

OpenCue suits a studio that wants a render manager it can read, change and run itself, especially one with mixed on-premises and cloud capacity, since it is Apache-2.0 licensed under the Academy Software Foundation and ships as Docker Compose services you can bring up in one command. It is the wrong choice if you need a finished product with a support contract, since this is infrastructure you operate yourself, and the wrong choice if the all profile is what you need on day one, because that starts Kafka and Elasticsearch before you have any data. Verify first that the default profile of db, flyway, cuebot and rqd comes up cleanly on your host, that the rest-gateway address baked into CueWeb matches your deployment, and that your outline format fits pyoutline before you plan a migration.

## FAQ

### How do I run OpenCue locally for a first test?

Create /tmp/rqd/logs and /tmp/rqd/shots, then run docker compose up -d and check the state with docker compose ps. That starts the default profile, which is the database, Flyway, cuebot and the Rust worker rqd. The web interface and monitoring are added with the cueweb and monitoring profiles.

### What are procs and tags in OpenCue?

A proc is a share of a render host with its own reserved core and memory requirement, and hosts can be split into many procs. Tags let you allocate specific jobs to specific machine types, and there is no limit on how many procs a single job can hold.

### Which Python libraries does OpenCue ship?

pycue, the API client, and pyoutline, the outline format for describing a shot as a tree of tasks and layers. The repository includes samples for both, along with samples for rqd and a licensing folder.

### Which renderers and deployment models does OpenCue support?

The README states native multi-threading support for Katana, Prman and Arnold, and support for multi facility, on-premises, cloud and hybrid deployments. The project is Apache-2.0 licensed under the Academy Software Foundation.

## Sources

- [AcademySoftwareFoundation/OpenCue on GitHub](https://github.com/AcademySoftwareFoundation/OpenCue)
- [License: Apache-2.0](https://github.com/AcademySoftwareFoundation/OpenCue/blob/master/LICENSE)
- [Project website](https://docs.opencue.io)
- [README](https://github.com/AcademySoftwareFoundation/OpenCue/blob/master/README.md)
- [Releases](https://github.com/AcademySoftwareFoundation/OpenCue/releases)

---

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