title: "Daemonless Appliances: Zero-Config Drop-In Utilities" description: "What makes an image a Daemonless Appliance, the five design principles behind the standard, and how to mark an image with type: appliance."

Daemonless Appliances

The Vision

Unlike traditional applications (like Plex or Nextcloud) which require setup, databases, and user management, Daemonless Appliances are drop-in infrastructure utilities. They are the software equivalent of plugging an ethernet switch into the wall: they just work.

Design Principles

1. Utilitarian Naming — Names reflect exactly what the appliance does (e.g. pkg-cache, not a project codename).
2. Zero-Configuration — Sane defaults allow the appliance to run immediately with a basic podman run command. Advanced tuning is available via environment variables, but never strictly required.
3. Pre-configured Stacks — An appliance bundles everything it needs. No side-car databases or complex compose files required.
4. Disposable State — Containers are ephemeral. All cache or data is designed to live on a mapped volume or be safely destroyed.
5. Instant Observability — Appliances should feature lightweight, built-in ways to verify they are working (e.g. lightweight web dashboards or highly verbose standard output).

Marking an Image as an Appliance

Set type: appliance under x-daemonless in compose.yaml:

1
2
3
4
5

x-daemonless:
  title: "Daemonless pkg cache"
  type: appliance
  category: "Infrastructure"
  # ...

dbuild lint validates type against a fixed list (app, base, stack, appliance) and rejects anything else — see the Configuration Reference.

Today appliance is classification only: it builds and versions exactly like type: app, with no additional lint enforcement. It exists so an image can declare "I follow the appliance principles above" in a way that's discoverable and typo-checked, rather than only asserted in prose.

The Appliance Fleet