Skip to content

Software Object Warehouse

Build Package Repo Ship What Changed

One self-contained binary turns local RPM and DEB packages into usable repositories, then manages snapshots, audit history, and incremental publication when you need more control.

Single binary · Linux + macOS · RPM + DEB · Apache-2.0

Get Started Download

Core capabilities

Flat or Managed

One command builds a local repository; a Managed workspace keeps membership, generations, and publication history.

01 / CREATE

Create repo in one command

◇ Point SOW at a directory of packages

  • sow create indexes top-level RPM and DEB files in place
  • Produces a directly usable flat YUM/APT repository
  • Replaces createrepo_c, dpkg-scanpackages, and reprepro

From package files to repository metadata, no daemon or toolchain.

create.sh
$ sow create /srv/repo --jobs 8
✓ repodata/repomd.xml
✓ Packages
✓ Packages.gz

03 / READY TO RUN

One binary, production ready

◇ The same executable on macOS and Linux

  • Self-contained CGO_ENABLED=0 archives for amd64 and arm64
  • The release pipeline builds RPM and DEB packages for Linux
  • Safe paths, bounded concurrency, fsync, and atomic publication

No repository daemon and no language runtime to operate.

04 / INCREMENTAL

Publish only the change set

◇ Inspect first, then synchronize

  • sow changes reports payload, metadata, pointer, and removal records
  • The operation log preserves who changed what and when
  • Publication uploads the delta, not every repository object

Small repository changes stay small on filesystem and cloud targets.

publish.sh
$ sow changes -r pgsql
+ pool/p/postgresql-18/...
~ dists/el9/x86_64/repodata/...
$ sow publish prod
✓ changed objects verified

Operating model

Simple at the start, explicit under control

SOW keeps the easy path rebuildable and makes every managed delivery decision visible.

01

Rebuild derived state

Plain mode treats repository metadata as a deterministic result of the package directory. Change the inputs, then run sow create again.

02

Own managed intent

Managed mode separates Desired Membership from immutable Built Generations, so policy and publication never become hidden side effects.

03

Verify before delivery

Checks, signatures, operation history, and atomic publication turn a repository build into an auditable release boundary.

Common questions

Choose the smallest workflow that fits

Plain and Managed use the same binary, but solve different operating problems.

Should I start with Plain or Managed mode?

Start with Plain mode when the directory already contains exactly what you want to serve. Use a Managed workspace when SOW must own membership, policy, signed metadata, immutable generations, audit history, or publication targets.

Can SOW handle RPM and DEB packages together?

Yes. A Plain directory can contain both RPM and DEB packages. In Managed mode, each Dist has one format, while one Repository can expose multiple RPM and DEB Dists from its shared public tree.

Does SOW need a daemon or database service?

No. SOW is a self-contained CLI and emits static repository files. Managed workspaces keep their embedded state locally; serve only the generated public tree with the HTTP server you already operate.

Where can a Managed repository be published?

A configured target can be a local or mounted filesystem, or Cloudflare R2 object storage. sow changes shows the delta before publication, and SOW records the target state for the next incremental run.

Build the first repository now.Start with sow create; move to a Managed workspace when you need policy, snapshots, and publication history.

Get StartedBrowse Docs