saggar

Push anything, get a built artifact back, with the logs in a web page.

saggar.dev is the build service. Hand it a git URL, a directory or a tarball, and it works out what the tree is, builds it in a disposable environment, streams the live logs, and stores the artifacts. Green artifacts come back as registries: docker pull and apt install address them directly.

saggar.dev builds nothing itself. Your builds run on runners: machines paired with your account, usually your own hardware. The service queues the jobs and serves the results; the runners do the computing. Pair one from a laptop or a home PC in a few minutes (see Pair your own runners).

Two programs touch your machine:

saggar

The client: submit, download, logs. The loop’s human and agent side.

saggar-worker

The runner: run it on a machine you want builds to happen on and pair it with your account (see Pair your own runners).

The web app covers the same ground in the browser: sign in, import projects, follow live logs, browse artifacts, manage your runner fleet. An account comes from your Gitea or GitHub login; saggar.dev stores no passwords.

Where to start

How-tos take a goal and carry it through, start to finish:

The reference aims to be complete, precise, and boring in the good way:

Conventions used throughout:

  • The CLI talks to https://saggar.dev by default; --server points a command at another instance (see Connection settings).

  • API paths are written relative to the management prefix /api/v1 (see The management API for what mounts where).

  • A runner is a machine that builds, a build is one job, an artifact is what a green build leaves behind. The CLI’s saggar node commands and the wire protocol say “worker” and “node”: same thing, different word.