# OpenPrinting CUPS for IPP Printers, Queues, and Docker

> OpenPrinting CUPS is a C-based print server for Linux and Unix-like systems, with support for IPP Everywhere, AirPrint, legacy PPD drivers, command-line queues, a web interface, and a container deployment path. It fits administrators and applications that need centralized printing, but the documented Docker setup carries important administrative and persistence constraints.

**OpenPrinting/cups** — OpenPrinting CUPS Sources

- Repository: https://github.com/OpenPrinting/cups
- Website: https://openprinting.github.io/cups
- Stars: 1,779 · Forks: 353
- Language: C
- License: Apache-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/openprinting-cups

## OpenPrinting CUPS print queues and IPP scope

OpenPrinting CUPS solves the problem of accepting print jobs on a Unix-like system, associating those jobs with queues, selecting device communication, and converting input when the chosen workflow requires filtering. Its intended users include system administrators, desktop users who print through a shared server, developers integrating printing through the C API, and organizations that need printer management beyond a single workstation. The documented interfaces include the System V lp and Berkeley lpr commands, a configurable web interface, and CUPS itself as a C library and daemon.

CUPS supports several printer categories. IPP Everywhere and AirPrint devices use standards-based IPP. Network and USB printers can also use Printer Applications. For older equipment, CUPS can use PPD-based printer drivers. That range is useful in mixed environments, but it should not be confused with universal driver quality. The README says the bundled sample PPD drivers offer basic printing and generally do not exercise a printer's full capabilities. Better matching drivers may be required for advanced options.

The repository layout reflects a full print server rather than a single printing utility. It includes a scheduler, filters, backends, configuration, command-line components, monitoring and notification code, documentation, tests, packaging material, and Docker files. The examples directory also contains IPP-oriented test cases for creating jobs, retrieving jobs, querying devices, subscribing to printer events, and imposing job constraints. Based on those paths, CUPS is intended to participate in the operating system's print stack and in application-level IPP workflows.

The default branch requires particular care. The README identifies it as tracking a future CUPS 2.5.x feature release and directs users who want CUPS 2.4.x to check out the 2.4.x branch. The listed releases are from the 2.4.x line. An evaluation should therefore treat the default branch as a development target rather than assume that it matches the latest stable release page.

## CUPS job routing from lp and lpr to a printer

A CUPS queue is created with a printer name, enabled state, device URI, and model. The device URI tells CUPS how to reach the printer. For an IPP Everywhere device at 11.22.33.44, the documented URI targets its /ipp/print endpoint. The model selects the driver path, and the README associates everywhere with IPP Everywhere, AirPrint, IPP shared printers, and printers supported through Printer Applications.

After queue setup, lp and lpr provide the normal user-facing submission path. CUPS recognizes PDF, PostScript, text, and many image formats, so common files can be submitted directly. Options can alter job processing, such as media and resolution. Applications that already generate printer-specific output are different: the README directs users to raw submission with lp -o raw or lpr -l so that the standard filters do not misinterpret the file.

This division creates a clear operational boundary. Normal documents enter a filter-oriented workflow, while printer-specific streams bypass some of that interpretation. Choosing the wrong path can produce incorrect processing, which is why raw mode is reserved for output already formatted for its target printer. The repository's backend, filter, scheduler, and cups directories support that architecture, while monitor and notifier cover event-related components.

CUPS also exposes administrative discovery commands. lpinfo -v lists discovered printers and their device URIs, while lpinfo -m lists available drivers. Discovery matters because manually guessing a device URI can make a queue unusable. The command output is also platform and network dependent, and the README does not claim that every printer will appear automatically. A missing printer in discovery is therefore an operational condition to investigate, not proof that CUPS lacks support for its protocol.

## Building CUPS and configuring the first IPP queue

The README directs developers to INSTALL.md for complete build guidance. The repository Dockerfile also records a source-build configuration that installs into an Ubuntu build root. This sequence is suitable as a concrete build example because the flags come directly from that file:

```bash
./configure \
    --prefix=/usr \
    --libdir=/usr/lib \
    --sysconfdir=/etc \
    --localstatedir=/var
```

After a successful build and installation according to INSTALL.md, the documented local documentation endpoint is http://localhost:631/. The administrator interface is at http://localhost:631/admin/. Administrative actions require the administration password, and the README lists root or members of the local sys, system, root, admin, or lpadmin group as eligible users.

For a first real queue, discover the printer and driver rather than inventing values. These commands should print the available device URIs and models respectively:

```bash
lpinfo -v
lpinfo -m
```

The README's concrete IPP Everywhere example creates and enables a queue named myprinter. Replace the example address only with the actual address shown by discovery:

```bash
lpadmin -p myprinter -E -v "ipp://11.22.33.44/ipp/print" -m everywhere
```

A normal document can then be submitted with an explicit media size and resolution:

```bash
lp -o media=A4 -o resolution=600dpi FILENAME
```

The file should be visible through the configured CUPS workflow after CUPS processes it. The README does not document a queue-verification command, so this tutorial does not invent one. For troubleshooting, the README points to REPORTING_ISSUES.md and states that issue reports require specific information.

## OpenPrinting CUPS Docker deployment boundaries

The repository includes a Dockerfile and docker-compose.yaml for running cupsd in a container. The Compose file builds from the local Dockerfile, names the container cups, restarts it unless stopped, runs /usr/sbin/cupsd -f, maps host port 631 to container port 631, and mounts ./container-config for /etc/cups plus ./container-config/logs for /var/log/cups.

The sample container should be read as a deployment starting point, not a production security template. The Dockerfile uses ubuntu:latest rather than a fixed image digest. It creates an admin user, assigns an admin password during image construction, adds that user to lpadmin, and grants sudo through /etc/sudoers. It also changes SystemGroup to lpadmin and runs cupsctl with remote administration options. Those are significant access-control choices. The README does not document a process for replacing the password or restricting the published interface, so operators must inspect those files before deploying the container on an untrusted network.

Persistence is limited to what the Compose volumes cover. Configuration and logs are mapped into ./container-config, but the shown Compose file does not mount a spool directory or other state. The supplied files do not establish whether completed jobs, queue metadata, certificates, or other runtime state persist after container replacement. Do not infer persistence from the existence of the two mounts.

The two-stage Dockerfile separates compilation from runtime. The builder installs development dependencies, configures the sources, builds, and installs with DESTDIR=/buildroot. The runtime stage installs libraries and service dependencies, copies /buildroot/usr to /usr, copies /buildroot/etc/cups to /etc/cups, and updates the dynamic linker cache. This arrangement can produce a smaller runtime image, but it also means changes to system libraries or build assumptions can affect compatibility. DOCKER.md is present for additional container documentation.

## CUPS licensing, releases, and maintenance scope

The repository declares the Apache License Version 2.0 with an exception intended to allow linking against GNU GPL2-only software. The README directs readers to LICENSE and NOTICE for the actual terms and exceptions. This review does not interpret those legal provisions. A downstream packager or integrator should read both files and account for the licenses of additional components, especially drivers and filters.

The repository is not archived, and the last push was on 2026-10-16. Recent listed releases include v2.4.20 on 2026-10-05, v2.4.19 on 2026-04-27, and v2.4.18 on 2026-04-22. That release cadence supports an active maintenance signal, but it does not remove upgrade work. CUPS is a print server with system integration, configuration, device behavior, filters, and security-sensitive administrative interfaces. An upgrade can therefore affect more than the daemon binary.

The branch distinction matters more than the release badge alone. The README calls the default branch future CUPS 2.5.x work and points stable 2.4.x users to another branch. Build dependencies, behavior, and compatibility can differ between those lines. CHANGES.md is the documented record of changes in the current major release, while DEVELOPING.md covers code development and INSTALL.md covers building and installation. Those files are the appropriate first checks when deciding whether an existing configuration can move to another branch.

Apple maintains a separate CUPS repository for the version shipped with macOS and iOS. OpenPrinting CUPS should not be treated as a drop-in source for those operating systems merely because both projects use the CUPS name and lineage.

## Conclusion

Adopt OpenPrinting CUPS when a Linux or Unix-like host needs a shared print service, IPP Everywhere support, conventional lp and lpr commands, or a documented CUPS daemon container. Do not adopt the sample Docker deployment unchanged for sensitive networks, because it publishes port 631, starts cupsd in the foreground, persists only selected directories, and creates an admin account with a documented password. Verify the 2.4.x or future 2.5.x branch that matches your deployment first, then inspect cups-files.conf, the mounted configuration and logs, printer discovery, and the privileges assigned to the container before adding a real queue.

## FAQ

### How do I install OpenPrinting CUPS?

The README points to INSTALL.md for build and installation instructions. It also documents accessing the local web interface at http://localhost:631/ after installation, with administration available at http://localhost:631/admin/.

### How do I add an IPP Everywhere printer to OpenPrinting CUPS?

Use lpinfo -v to find the device URI and lpinfo -m to inspect available models. The README's example uses lpadmin with -p, -E, -v, and -m everywhere, with the printer name and address changed to match the discovered device.

### Can I run OpenPrinting CUPS with Docker Compose?

The repository provides Dockerfile and docker-compose.yaml files. The Compose configuration builds the local image, runs /usr/sbin/cupsd -f, publishes port 631, and mounts configuration and log directories.

### Which OpenPrinting CUPS branch should I use for CUPS 2.4.x?

The README says the default branch tracks a future CUPS 2.5.x feature release and directs users who want CUPS 2.4.x to check out the 2.4.x branch.

## Sources

- [License: Apache-2.0](https://github.com/OpenPrinting/cups/blob/master/LICENSE)
- [OpenPrinting/cups on GitHub](https://github.com/OpenPrinting/cups)
- [Project website](https://openprinting.github.io/cups)
- [README](https://github.com/OpenPrinting/cups/blob/master/README.md)
- [Releases](https://github.com/OpenPrinting/cups/releases)

---

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