Why We Built Cargoman

Cargoman started where most tools start: with a job I didn't want to do twice.

I run a small consultancy that builds and maintains commercial PHP applications — mostly Magento and Laravel, mostly with a long tail of internal modules that aren't open source and never will be. For years, sharing those modules across projects meant the same uncomfortable choice every team in this corner of PHP eventually faces.

The choice nobody enjoys

If you have private Composer packages and you don't want them on Packagist, your options have looked roughly like this for a decade:

• Satis. Free, but you edit a JSON file by hand every time a repo is added, run a build script on cron, and serve the output as static files. It works, until it doesn't, and when it doesn't there's no dashboard to tell you why.
• Toran Proxy. Used to be the answer. The maintainer moved on, the project went quiet, and now it shows up as a cautionary tale on Stack Overflow.
• Private Packagist. Excellent product. Priced for teams who already have a finance department.
• Roll your own. A weekend project that turns into a year of maintenance the moment it touches production.

Most of the agencies I know picked Satis and just accepted the friction. Edit satis.json. SSH in. Re-run the build. Hope nobody pushed during the window. Update auth.json across every dev machine when a token rotates. Find out months later that the cron silently stopped firing.

The friction was tolerable on a single project. It was not tolerable across twenty.

What we wanted instead

The brief I wrote for myself was short:

1. Add a repository by clicking on it, not by editing JSON.
2. Updates appear when I git push, not when a cron decides.
3. A single registry URL per project, no matter how many packages live behind it.
4. A real dashboard — packages, tokens, downloads, who has access to what.
5. Self-host it for free if you want full control. Pay for the cloud version if you'd rather not.

Nothing on that list is exotic. The npm and Cargo ecosystems have had this for years. Composer just hadn't.

Why Rust

The unglamorous reason is that I didn't want the registry to be the thing that broke. A registry is infrastructure — it sits between your developers and composer install working at all. If it's slow, deploys are slow. If it's down, deploys are blocked. If it leaks memory under load, you find out at the worst possible time.

Rust gave us a single static binary, predictable memory, and the kind of throughput that means a small VPS handles a real team without breaking a sweat. The whole server fits in a Docker image small enough to pull faster than most teams can finish reading the release notes.

The fact that it's also fun to work on is a bonus we'll quietly take credit for.

Two ways to run it

Cargoman ships as one product with two deployment shapes, because the people who want to self-host and the people who want a managed service are not the same people, and pretending otherwise leads to a worse version of both.

• Self-hosted (Pro). One Docker container, your database, your domain, your data. Licensed with a signed key that validates offline — no phone-home, no degraded mode if our website is down.
• Cloud. A dedicated subdomain like acme.packages.cargoman.io, TLS handled, backups handled, updates handled. Sign up, install the GitHub App, ship.

Both speak the same Composer protocol. Both have the same dashboard. The only thing that changes is who owns the server.

Where we are today

The registry is in production. The storefront you're reading this on is in production. The first paying customers are in production. The compare pages, the migration tooling, the docs — all in flight.

What we're not is done. There's a roadmap of things we want to do that's longer than the things we've already done, and most of it is shaped by what early customers ask for. If you're running Composer at any kind of scale and the workflow above sounds familiar, we'd like to hear from you.

If you're already mid-Satis-migration and looking for the practical steps, the next post in this series will walk through exactly that.

Thanks for reading.

— Serhiy