Serverless Registry Solution

Serverless Registry is the successor of Serverless Satis, which only handled Composer.

Sample Use Cases

Bellow are provided a few sample use cases:

1. Hosting a private registry with your company's internal packages, in every language you use, from a single place
2. Distributing commercial packages to your customers, with a separate read-only token (and set of packages) for each of them
3. Publishing from CI without any stored secrets, using GitHub Actions OIDC
4. Hosting binaries and installers as versioned generic packages

How it works

Serverless Registry Worker runs on CloudFlare Workers and serves the native read protocols of the package managers, the publishing and administration API and a small admin panel. Packages are stored in a CloudFlare R2 bucket, credentials in CloudFlare KV.

Versions are published with the sreg CLI, usually from CI using GitHub Actions. Archives go straight to and from R2 through presigned URLs and never pass through the Worker.

Supported ecosystems

• Composer,
• npm,
• cargo (sparse index),
• NuGet (V3),
• Swift (package registry),
• Maven / Gradle,
• generic files (JSON feed) - binaries, installers, anything else.

Only the ecosystems you need have to be enabled (ECOSYSTEMS variable of the Worker).

Features

• Credentials with grants - one named credential per consumer, pipeline or administrator, of exactly one kind (read, publish or admin), with grants on packages (acme/*) and version ranges.
• Transitive access - a read grant also opens the versions of the registry's packages that the granted versions depend on.
• GitHub Actions OIDC - publish and install without stored secrets.
• Sign in through the browser - people use a login (password and optional one-time code) and sreg login to get short-lived tokens, approved per operation, instead of copying tokens around.
• Immutable versions - a published version never changes; an admin can yank or delete it.
• Admin panel - credentials, grants, packages, versions and settings, without any framework or external resources.
• Easy updates - a GitHub workflow in your own repository updates the Worker from upstream and keeps your bindings.
• Nothing to run - one Worker, one R2 bucket and one KV namespace; the free plan is enough for a small team.

Requirements

• GitHub account - for the repository the Worker is deployed from and for publishing with GitHub Actions,
• CloudFlare account:
  • access to CloudFlare Workers,
  • CloudFlare R2 Storage enabled,
  • optionally a domain configured and pointing to CloudFlare DNS servers (without one the registry runs on workers.dev).

Quick Start

1. Deploy the Worker using the button below. CloudFlare creates the Worker, the KV namespace and the R2 bucket for you.Deploy to CloudFlare
2. Configure it in the Worker's Settings → Variables and Secrets: PUBLIC_URL, S3_ENDPOINT, and secrets S3_ACCESS_KEY_ID, S3_SECRET_ACCESS_KEY and SESSION_SECRET. See Worker configuration.
3. Open the registry in a browser and create the first admin: a password and, optionally, a one-time code for an authenticator app (shown once). Create a publish credential for each pipeline and a read credential for each consumer.
4. Publish a package:

export REGISTRY_URL=https://packages.example.com
export REGISTRY_TOKEN='ci-acme-sdk:…'
sreg composer publish

Or, without a stored token, sign in through the browser: sreg composer publish --login.

Components

Further reading

Detailed specifications are maintained next to the code:

• Specification
• HTTP API contract
• Deployment guide