# Open Build Service: one build system for every distribution you ship to > The Open Build Service is a build and distribution platform that compiles source packages once and emits binaries for many operating systems and architectures, with a Ruby on Rails front end, a Perl backend and an XML API. It suits a vendor whose product ships as packages for several distributions, and the operational weight of running it is substantial. **openSUSE/open-build-service** — Build and distribute Linux packages from sources in an automatic, consistent and reproducible way #obs - Repository: https://github.com/openSUSE/open-build-service - Website: https://openbuildservice.org - Stars: 1,085 · Forks: 500 - Language: Ruby - License: GPL-2.0 - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/opensuse-open-build-service ## One source definition, many binary outputs The Open Build Service is a generic system to build and distribute binary packages from sources in an automatic, consistent and reproducible way. You can release packages as well as updates, add-ons, appliances, and entire distributions for a wide range of operating systems and hardware architectures. That sentence is the whole proposition, and it is easier to feel than to state. The traditional alternative is a build matrix: a CI configuration per distribution per architecture, each with its own package spec, its own chroot, its own quirks, and its own failure modes. The OBS model is to describe the package once and let the service work out how to build it for each target. The reproducibility part is not decoration in a world where the same source produces different binaries on different build hosts. If a service says a build is consistent and reproducible, that is a claim about the whole path from source to artefact, not just about the compiler invocation. The scope is wide. Packages, updates, add-ons, appliances and whole distributions, across a wide range of operating systems and hardware architectures. The repository topics confirm the spread in practice, listing appimage, archlinux, centos, deb, debian, docker, fedora, kiwi, pkgbuild, rpm and ubuntu, which is a list of the target formats and the ecosystems involved. The platform is at openbuildservice.org, and the project is a Ruby on Rails application, which the topics list as rails-application. The primary language of the repository is Ruby, though that only describes the front end. The licence is GPL-2.0, with the important qualification that the service is Free Software released under the terms of the GPL except where noted, and that third party content, like but not exclusively the webui icon theme, may be released under a different licence, so you need to check the respective files. ## A Rails front end over a Perl backend, with an XML API between The OBS consists of a backend and a frontend, and the split is not a matter of taste. The backend implements all the core functionality, that is, building packages. The frontend provides a web application and XML API for interacting with the backend. Additionally, there is a command line client, `osc`, for the API, which is developed in a separate repository. So the core of the system, the part that knows how to unpack a source, resolve dependencies, set up a build root and run the compiler, is Perl, and the part people interact with, the web interface and the API, is Ruby on Rails. The API is XML rather than JSON, which is a deliberate choice for a system that predates the JSON era and that has to be consumed by clients across many languages and by older tooling. The repository layout follows the same split: ``` dist Files relevant for our distribution packages docs Documentation, examples and schema files src/api Rails app (Ruby on Rails) src/backend Backend code (Perl) ``` The `docs` directory holding schema files is the tell that the API is schema driven, and the Makefile has a target called `resolve_swagger_yaml` that runs a Ruby script over an `OBS-v2.10.50.yaml` in the API's public apidocs directory. So the API contract is a Swagger document, and there is a build step that resolves it into a form the front end can consume. The version in the filename, 2.10.50, gives you a sense of the API's granularity. The top level of the repository has grown a lot of tooling around those three directories. There is a `Rakefile`, a `Makefile` with `Makefile.include` and `Makefile.targets`, a `KankuFile` and a `KankuFile.fedora` for the CI system, a `.rubocop.yml` with a `.rubocop_todo.yml` beside it, a `.ruby-version` file, a `docker-compose.yml` with a `docker-files/` directory, a `contrib/` directory, a `dist/` directory for the distribution packages, and a `.obs/` directory. There is also an `AGENTS.md`, a `SECURITY.md`, a `SUPPORT.md`, an `AUTHORS` file and a `ReleaseNotes-2.11`. And a `gitleaks.toml` with a `.gitleaksignore`. That is a secret scanning configuration, which in a repository that handles credentials for a build service is not a nicety. ## Installing it, and why the appliance comes first The installation section is organised around a recommendation rather than a set of options, and the recommendation is the appliance. To run the OBS in production, the documentation recommends using the appliance, which is the whole package: a recent and stable Linux operating system, openSUSE, bundled and pre-configured with all the server and OBS components you need to get going. And then the reason to do it yourself is given with examples, such as a different partition schema or SLES as the base system, in which case you can install the packages and run a setup wizard. The docker compose setup is meant only for development, and that sentence is a warning rather than a footnote, because a development compose file with a mounted source tree is not a production deployment. The package path is three commands, and the first one has a detail that catches people, because the URL depends on the base operating system. The example uses openSUSE Leap 15.4: ```shell zypper ar -f https://download.opensuse.org/repositories/OBS:/Server:/2.10/15.4/OBS:Server:2.10.repo ``` Then install the package with the pattern: ```shell zypper in -t pattern OBS_Server ``` And run the setup wizard: ```shell /usr/lib/obs/server/setup-appliance.sh --force ``` The use of a pattern rather than a list of packages is how openSUSE ships a set of things that belong together, and the `--force` flag on the wizard is what lets it re-run over an existing installation. For a more complex setup, such as a distributed backend, the documentation recommends reading the high level overview chapter in the administrator guide, which confirms that the distributed topology is a supported and documented shape rather than an accident. The community channels are an IRC channel on Libera Chat and a mailing list, and the contribution route is a contributing readme. ## The development compose file shows the real architecture The docker-compose.yml is the most informative document in the repository, because it names the processes the system is actually made of. There are five services, and each one is a component of the running system rather than a convenience. `db` is MariaDB, with the command `/usr/libexec/mysql/mysql-systemd-helper start` and port 3306 exposed. `cache` is memcached, with `/usr/bin/memcached -u memcached` and port 11211 exposed. `backend` and `worker` are the same image, the openbuildservice backend, but they do different jobs, with the backend running `/obs/contrib/start_development_backend -d /obs` and the worker running `/obs/contrib/start_development_worker`. The worker is marked `privileged: true` and depends on the backend. That split is the architecture of a build system in one file. The backend is the service that receives requests and records state, and the worker is the service that actually executes builds, and a build needs privileges the request handler does not. Separating them is what lets you run many workers, add them to a different host, or let one of them restart without dropping the API. The `frontend` service is the Rails application, built from a Dockerfile in `docker-files/` with a build argument for the container user id, and it runs `foreman start -p 3000` with ports 3000 and 1080 exposed. It depends on the database, the cache, the backend and the worker, so the compose file encodes the startup order. The images come from the project's own registry at registry.opensuse.org under the obs/server/unstable/containers path, except the frontend, which is built from `src/api` and tagged as `openbuildservice/frontend`. The backend and worker mount the source tree at `/obs` with the `z` flag, so the container runs the code you are editing rather than the code in the image. The presence of memcached in the diagram is worth noting. A build service that fans out to workers needs to share state cheaply, and the cache sits between the Rails app and the backend for exactly that. ## Where Open Build Service is the wrong investment The honest case against is about scale, and it cuts in an interesting direction. The first case is a single distribution and a single architecture. The service is a general system, and a general system is a lot of machinery for one target. A hosted CI service with a container per job will build for one distro and one architecture with a fraction of the setup, and a project that only needs an rpm for one release series should not run a build and distribution platform to get it. The second case is a project with no packaging to speak of. OBS is built around package formats, chroots, dependency resolution across distributions and appliance images. A project that ships a container image, or a static binary, or a language package manager artefact, has none of that and would be modelling its workflow onto a system whose entire value is in the part it does not need. The third is operational ownership. The recommended path is an appliance you administer yourself, with a database, a cache, a backend, workers and a Rails front end, plus the build hosts on which the actual compilation happens. That is a platform to run, not a tool to call. The docker compose path is explicitly for development, so a team that wants the development setup in production is going against the documentation. The alternative approach for most teams is a hosted CI matrix with per distribution packaging recipes, which is more configuration work but no infrastructure. The difference in approach is where the knowledge lives. OBS centralises it in the service, where the definition of a package is a first class object with its own metadata and its own history, and the build result is an artefact the service tracks. A CI matrix keeps it in your configuration files and in the recipes of each distro's packaging community. There is also a middle path worth knowing, which is the public build.opensuse.org instance. Using a public instance rather than running your own gets the platform without the platform operations, which is the sensible default unless you have a reason to keep the build infrastructure private. On maintenance, the repository is not archived and the last push was on 2026-10-15. The recent release list shows 1.7.1 and 2.1.12 and 2.1.11 all tagged on the same day in 2022, which is the shape of a project that ships frequently under a version scheme that moves per component rather than one global number, since the backend and the API version on different lines. ## Conclusion Open Build Service fits a vendor who publishes packages or appliances across several distributions and architectures and wants one reproducible build pipeline rather than a matrix of per distro CI, because the same source definition produces the rpm, the deb and the appliance images. Skip it if you publish for one distribution and one architecture, since a hosted CI service will do that with far less to run, and note the licence split, where the service itself is GPL-2.0 but third party content such as the web UI icon theme may be under different terms. Before you deploy, read the high level overview in the administrator guide if your setup is distributed, and take the appliance path rather than the Docker Compose one, since the documentation says Compose is meant only for development. The last push was on 2026-10-15. ## FAQ ### What is the Open Build Service? It is a generic system to build and distribute binary packages from sources in an automatic, consistent and reproducible way, and it can release packages, updates, add-ons, appliances and entire distributions across many operating systems and hardware architectures. ### What is the architecture of the Open Build Service? A backend in Perl that implements all the core functionality including building packages, a frontend that is a Ruby on Rails app providing a web interface and an XML API, and a separate osc command line client. The docker compose file shows a backend and a worker as distinct processes with a database, a cache and the frontend on top. ### How do I install the Open Build Service in production? The documentation recommends the appliance, a pre-configured openSUSE system with all components. Otherwise add the OBS software repository with zypper for your base system, install with `zypper in -t pattern OBS_Server`, and run `/usr/lib/obs/server/setup-appliance.sh --force`. The docker compose setup is for development only. ### What licence is the Open Build Service under? GPL-2.0, except where noted. Third party content, such as the webui icon theme, may be released under a different licence, so the respective files need to be checked. The last push was on 2026-10-15. ### How do I contribute to the Open Build Service? The contribution readme in CONTRIBUTING.md is the starting point, and the project is discussed on the #opensuse-buildservice IRC channel on Libera Chat and on the opensuse-buildservice mailing list. ## Sources - [License: GPL-2.0](https://github.com/openSUSE/open-build-service/blob/master/LICENSE) - [openSUSE/open-build-service on GitHub](https://github.com/openSUSE/open-build-service) - [Project website](https://openbuildservice.org) - [README](https://github.com/openSUSE/open-build-service/blob/master/README.md) - [Releases](https://github.com/openSUSE/open-build-service/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/opensuse-open-build-service