Cobbler: a Linux deployment server that ties PXE, DHCP, TFTP and DNS into one place

What Cobbler actually removes from a bare-metal rollout

Provisioning a physical machine over the network means coordinating several daemons that have no shared idea of what a host is. A DHCP server hands out an address and points the client at a boot loader. A TFTP server serves that boot loader. A DNS server resolves the host's name. The installer tree itself sits on an HTTP or FTP server. Each of those has its own configuration format, and each format has to be edited by hand every time a new machine or a new distribution version appears.

Cobbler's stated purpose is to glue those tasks together. The README describes it as a Linux installation server that automates the associated tasks "so you do not have to hop between lots of various commands and applications when rolling out new systems". It also lists DNS, DHCP, package updates, power management and configuration management orchestration as things it can help with.

The audience is narrow and technical: people who rack hardware and need an operating system on it without a console. If you only ever provision virtual machines through a cloud API, Cobbler solves a problem you do not have.

The object model and the daemon behind it

Cobbler's mechanism is a store of named objects plus a daemon that renders that store into other services' native configuration. The object types visible in the documentation are distros, profiles and systems: a distro is an imported installer tree, a profile is a distro plus kickstart and settings, and a system is one machine bound to a profile. That hierarchy is the whole design. When you change something, you change an object and let Cobbler regenerate the DHCP, DNS and TFTP files that depend on it.

The daemon is cobblerd, and it is the process the API talks to. In the production Compose stack it is started with the command cobblerd -F, and its XMLRPC server is bound by the environment variable COBBLER_XMLRPC_BIND_ADDRESS, set to 0.0.0.0 in the compose.yml example. Traefik routes a PathPrefix rule for /cobbler_api to that server.

The same file shows that the rendered artefacts are not written into the container's own filesystem. Named volumes carry /etc/cobbler, /var/lib/cobbler, /srv/www/cobbler, /srv/tftpboot, /etc/cobbler-dhcp, /etc/cobbler-dns and /var/lib/named. That is worth reading closely: Cobbler expects to write into directories that other services read, which is exactly why running it in containers needs those mounts rather than a single data volume.

Installing Cobbler and importing your first distribution

The README does not give install steps. It points to the RPM path: build the package with make rpms, then read the manual pages with man cobbler, or run perldoc cobbler.pod from a source checkout. The package itself is published on PyPI under the name cobbler, and setup.py describes it as a "Network Boot and Update Server". The repository also carries debian/ and cobbler.spec, so both deb and RPM packaging exist in the tree.

If you want to try it without touching a host, the repository ships a container path. compose.yml is the production stack and pulls published images; compose.dev.yml is the variant that builds from source. The header comment gives the entry points directly.

docker compose -f compose.yml up -d
curl http://localhost/cobbler_api
curl http://localhost/httpboot/

The first URL is routed to cobblerd's XMLRPC server, the second to the http-api Gunicorn application, and the third to the web UI if it is enabled. Note that the DHCP, DNS and dnsmasq include files in compose.yml are commented out by default, so a plain up -d gives you the API and boot file serving without Cobbler managing your network services.

Once you have a working server, the first real task is importing an installer tree so Cobbler has a distro object to work from. The compose.yml bind mount points at ${COBBLER_DISTRO_SOURCE_DIR:-./distro-sources} on the host, mounted read-only at /srv/distro-sources in the container:

volumes:
  - type: bind
    source: ${COBBLER_DISTRO_SOURCE_DIR:-./distro-sources}
    target: /srv/distro-sources
    read_only: true
    bind:
      create_host_path: true

That read-only mount is the intended place to drop extracted ISO contents before running an import. The README does not document the import command itself, so read the man page or the Read the Docs manual before you start.

Where Cobbler gets in your way

The most obvious gap is that Cobbler wants to own services you may already run. If you have a mature DHCP setup with reservations managed elsewhere, enabling the DHCP include file means two systems writing the same configuration. The compose.yml default of leaving dhcp.yml and dns.yml commented out is a sensible acknowledgement of that, but it also means the out-of-the-box container stack does not do the thing the README advertises first.

The README also does not document rollback. There is no described procedure for undoing a change that Cobbler has already pushed into your DHCP or DNS configuration, and no described dry-run mode. For a tool whose job is rewriting other daemons' config files, that is the limitation to weigh hardest before pointing it at production network services.

Finally, the project is mid-transition between release lines. The recent releases include v3.3.10 and v3.3.9 alongside v4.0.0b6, and setup.py carries a fallback_version of 4.0.0. The b6 suffix means the 4.x line is still a beta at the time of those tags. If you need a stable target, the 3.3.x tags are the ones without a beta suffix, and the documentation does not promise API compatibility across the two lines.

Cobbler against a general configuration management tool

The natural comparison is with a configuration management system such as Ansible, Puppet or Chef. The difference is where each one starts. Configuration management assumes a machine already has an operating system and an agent or a reachable SSH port. Cobbler's job ends roughly where theirs begins: it gets the operating system onto the disk over the network, and the README lists configuration management orchestration as something it can hand off to rather than something it replaces.

That distinction matters when you pick a tool. If your machines already boot from an image and you are configuring software on top, Cobbler adds a daemon and a second source of truth for hostnames and addresses for no benefit. If your problem is that a new rack arrives with empty disks and no console, configuration management cannot help you until something has installed a base system, and that something is what Cobbler is.

A narrower alternative is to write the DHCP, TFTP and DNS configuration yourself with a templating script. That works, and it avoids a daemon, but you then own the mapping from a distribution tree to a boot entry for every architecture and every installer version you support. Cobbler's value is that this mapping is already written.

Maintenance, licensing and what the repository tells you about upgrade cost

The last push to the default branch was on 2026-09-23, and the most recent release tag is v3.3.10 from 2026-09-18, so the project is being changed. That is not the same as being easy to upgrade. The presence of both a 3.3.x line and a 4.0.0 beta line means you should decide which one you are tracking before you build anything on top of it, because the repository does not describe a migration path between them.

Upgrade cost also depends on how you deployed. The container path pins nothing in the quick-start example: compose.yml pulls ghcr.io/cobbler/cobblerd:latest, so a restart can move you to a new build. If you need reproducible deployments, pin the image tag yourself rather than relying on latest.

The licence is GPL-2.0, and setup.py declares it as "GPLv2+". That is a copyleft licence. If you modify Cobbler and distribute it, or distribute a product that links to it, the licence terms apply to your distribution. Whether your specific use counts as distribution is a question for your own legal review; the repository's COPYING file is the authoritative text, not this paragraph.

Editorial conclusion

Adopt Cobbler if you provision Linux machines over the network and want PXE, DHCP, TFTP and DNS driven from one store of distros, profiles and systems, and if you are willing to read the Read the Docs manual rather than the README. Do not adopt it if you need a documented rollback path or a supported Windows deployment workflow, because the repository does not document either. Before committing, check the man page from an installed RPM, confirm which of the compose.yml include files you actually need, and read the licensing note in COPYING against your distribution policy.

Frequently asked questions

Official sources

1. cobbler/cobbler on GitHub
2. License: GPL-2.0
3. Project website
4. README
5. Releases