jina-ai/discoart: one-line Disco Diffusion artwork generation

The Colab notebook problem DiscoArt is built to remove

Disco Diffusion as originally distributed is a Google Colab notebook, and the README says so directly: it is "a Google Colab Notebook that leverages CLIP-Guided Diffusion to allow one to create compelling and beautiful images from text prompts." Notebooks are fine for one run. They are poor infrastructure. Parameters live in cells, results live in the runtime filesystem, and a session timeout takes the whole run with it.

DiscoArt is aimed at three overlapping groups. Generative artists who want to script batches instead of clicking Run All. AI engineers who need image generation inside a larger pipeline. And developers who want the model behind an HTTP or gRPC endpoint rather than in a browser tab. The project describes itself as "developer-centric and API-first" and states that improving consumer-facing experience is out of scope, which is an unusually honest boundary to draw in a README.

The concrete deliverable is a Python package named discoart, imported as a library, callable as a module, and deployable as a service. The README lists result recovery and persistence, gRPC/HTTP serving without TLS, and post-analysis as the features it adds over the notebook.

What create() actually returns and where the images land

The mechanism is a thin orchestration layer over the diffusion loop. You call create(), it merges your keyword arguments with the defaults in discoart/resources/default.yml, runs the generation, and hands back a DocumentArray. That return value is the part worth understanding: it holds the arguments passed to create(), including seed, text prompts and model parameters, plus the generated images and their intermediate steps. Reproducing a run means keeping that object or the saved protobuf, not re-typing prompts.

The filesystem layout is explicit in the README. Everything is written under the current working directory into a folder named after the run:

./{name-docarray}/{i}-done.png
./{name-docarray}/{i}-step-{j}.png
./{name-docarray}/{i}-progress.png
./{name-docarray}/{i}-progress.gif
./{name-docarray}/da.protobuf.lz4

Here i runs up to n_batches, the step files are intermediate frames updated in real time, and da.protobuf.lz4 is a compressed protobuf of all intermediate results so far. The write frequency is governed by save_rate, which is the knob you turn when disk churn matters more than crash recovery.

The dependency list in setup.py tells you what this orchestration costs. It pulls docarray[common] pinned to >=0.14.6,<0.30.0, jina>=3.7.3, open_clip_torch, guided-diffusion-sdk, resize-right-sdk, openai-clip, lpips, wandb and pyspellchecker. That is a wide surface for a tool whose public interface is one function.

Installing DiscoArt and running a first prompt

The README states the prerequisites plainly: Python 3.7+ and CUDA-enabled PyTorch. The package itself installs from PyPI.

pip install discoart

That single command is stated to cover self-hosting, Google Colab, system integration and non-GUI environments. It does not install PyTorch for you, so a machine without a CUDA build already present will not have a working diffusion backend after this step.

For a Jupyter session on your own GPU box, the README points at the prebuilt Docker image instead. The Dockerfile in the repository is based on nvidia/cuda:11.6.2-cudnn8-devel-ubuntu20.04, installs torch with the cu116 index, copies the source into /discoart, runs pip install --compile ., and starts Jupyter on port 8888.

FROM nvidia/cuda:11.6.2-cudnn8-devel-ubuntu20.04
WORKDIR /app/
RUN pip install numpy torch torchvision torchaudio --extra-index-url https://download.pytorch.org/whl/cu116
COPY . /discoart/
RUN cd /discoart && pip install --compile .
CMD ["jupyter", "notebook", "--ip=0.0.0.0", "--port=8888", "--allow-root", "--no-browser"]
EXPOSE 8888

A first run is two lines. The default text prompts and parameters come from the bundled YAML, so you get output without configuring anything.

from discoart import create

da = create()

To steer it, pass supported parameters as keyword arguments. The README gives this example with a prompt, an init_image URL and skip_steps.

from discoart import create

da = create(
    text_prompts='A painting of sea cliffs in a tumultuous storm, Trending on ArtStation.',
    init_image='https://d2vyhzeko0lke5.cloudfront.net/2f4f6dfa5a05e078469ebe57e77b72f0.png',
    skip_steps=100,
)

If you cannot remember a parameter name, the package ships a cheatsheet function. Calling cheatsheet() prints the available options, which is faster than reading default.yml.

from discoart import cheatsheet

cheatsheet()

After a run, the current directory contains the run folder described above. You should see a done PNG per batch item plus the progress sprite and gif, refreshed as generation proceeds. Two other entry points exist without writing Python: python -m discoart create and python -m discoart config for the CLI, and python -m discoart serve to expose the whole thing as a gRPC/HTTP/websockets service. The README claims the service supports TLS and that scaling and cloud-native wiring for Kubernetes, Prometheus and Grafana are one-line, courtesy of Jina.

The dependency pin is the real adoption risk

The most consequential detail in setup.py is docarray[common]>=0.14.6,<0.30.0. An upper bound that tight means the project was written against a specific docarray generation, and installing it into an environment that already has a newer docarray will force a downgrade or fail resolution outright. Jina is pinned only at the lower end, jina>=3.7.3, which is the opposite problem: no ceiling, so a future Jina release can break the service path without any change on your side.

Version drift is visible in the release history. v0.12.0 landed on 2022-08-09, v0.11.7 the day before, and v0.12.1 on 2023-04-20. The last push to the repository was on 2023-04-20, the same date as v0.12.1. Anyone evaluating this in 2026 is looking at a codebase that has not moved in roughly three years, and the README's own framing of DiscoArt as the infrastructure layer rather than the product suggests that was intentional.

The second limitation is scope. DiscoArt is not a GUI and the README says improving consumer-facing experience is out of scope. It also notes that the built-in Jupyter support does not offer an intuitive interface for prompt scheduling. If your workflow is a person typing prompts and judging images, DiscoArt is the wrong layer; the README itself points to third-party services for that, and states those platforms are not affiliated with Jina AI and define their own terms, paywall and data policies outside the scope of the DiscoArt MIT License.

Third, the CUDA requirement is not negotiable. The README asks for CUDA-enabled PyTorch and the Docker image targets CUDA 11.6. CPU-only inference is not a documented path.

DiscoArt against running the original notebook or a hosted endpoint

The honest alternative is the original Disco Diffusion Colab notebook itself. The difference is not image quality; it is where state lives. In the notebook, parameters and results live in the Colab runtime, and the README's own pitch mentions session timeout as the thing DiscoArt removes. DiscoArt writes step images, progress sprites, a gif and a compressed protobuf to your working directory as generation proceeds, and returns a DocumentArray carrying the arguments and seeds. You can kill the process and still have the frames.

A second alternative is a hosted endpoint that already wraps DiscoArt. The README lists Fever Dreams as a free community service with a gallery, Replicate as a free form-based GUI, RunPod as a paid GPU cloud running the DiscoArt container, and Renderflux as a paid creative platform. The trade-off is control: you get a GUI and someone else's GPU bill, and you accept their terms of service, paywall and privacy policy, which the README explicitly places outside the DiscoArt licence. If your goal is a pipeline that calls a function and stores a DocumentArray, none of these replace the library.

A third comparison is the Jina stack itself. DiscoArt's serving mode is not a bespoke server; it is Jina underneath. If you already run Jina for other cross-modal work, python -m discoart serve slots in without new operational concepts. If you do not, adopting DiscoArt as a service means adopting Jina, docarray and their release cadence as well.

Licence, maintenance and what an upgrade would cost

setup.py declares license='MIT' and the repository carries a LICENSE file, but the repository metadata classifies the licence as NOASSERTION. That mismatch is worth resolving with your own legal review before shipping anything commercial; this is a description of the files, not legal advice.

Maintenance is the harder question. The last push was on 2023-04-20. There is no archived flag, so the repository is not formally retired, but a three-year gap between the last push and any current evaluation means you should treat the dependency pins as frozen. Any upgrade path you build runs through docarray 0.30.0 or later, and nothing in the repository indicates that migration has been done.

The practical upgrade cost is therefore front-loaded: pin your docarray and jina versions explicitly in your own environment file rather than letting pip resolve them, and expect the guided-diffusion-sdk and resize-right-sdk wheels to be the first thing that breaks on a newer CUDA or Python. The upside of a frozen tool is that behaviour does not shift under you. The downside is that security and compatibility fixes for the transitive dependencies become your responsibility, not the maintainer's.

Editorial conclusion

Adopt DiscoArt if you already have a CUDA GPU, want reproducible Disco Diffusion runs with per-step image dumps and a DocumentArray result, and are willing to pin docarray below 0.30.0. Skip it if you need a maintained dependency graph, a consumer GUI, or CPU-only inference. Before committing, check whether pip resolves the docarray and jina pins on your Python version, and confirm the guided-diffusion-sdk and resize-right-sdk wheels exist for your CUDA build.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes