Hosted repositories

A hosted repository is a package registry that managed.works runs for you. You get the same signed registry as publishing to your own bucket , but without an S3 bucket, without managing a signing key, and without sharing a public key by hand. Sign in once and push:

managed login                                   # authorize this computer
managed repository create feeder                # provision a repo under your org
managed repository link managed.works/<org>/feeder   # add it to this project
managed repository push --repo feeder --directory packages/

Because the repository lives in your managed.works account, it also shows up in the dashboard under Repositories, and any project in your org can add it with one click, no key copy-paste.

How it compares to self-hosting

	Hosted	Self-hosted
Storage	managed.works	your S3/R2 bucket
Signing key	held & rotated for you	you run keygen, keep the private key
Sharing	your account / one-click in the dashboard	hand out the public key
Auth	account login (managed login)	bucket credentials
Visibility	per-repo private (default) or public	bucket ACL

Everything else, the index format, the signature, the tarball layout, is identical, so the same managed apply resolves hosted and self-hosted packages the same way.

1. Sign in

managed login

This opens your browser to authorize the computer, then stores a token at ~/.config/managed/auth.json (readable only by you). It's separate from managed ui connect, which links a single project to the dashboard, login authorizes you to manage repositories. Sign out with managed logout.

2. Create a repository

managed repository create feeder            # private (default)
managed repository create feeder --public   # world-readable
managed repository create feeder --org acme  # a specific org (default: your personal org)

The name is lowercase letters, digits, and dashes. managed generates the signing key on the server and prints the repository's endpoint and visibility.

• Private (default): pulls require your account token. Good for internal packages.
• Public: the index and tarballs are world-readable over HTTPS (still signed). Good for packages you want anyone to consume.

You can flip a repository between public and private any time from the dashboard's Repositories page.

3. Link it to a project

managed repository link managed.works/<org>/feeder

This adds the repository to the current project's managed.yaml. managed fetches the repository's public key for you and pins it, so signatures are verified exactly as for any other registry:

repos:
  - url: managed.works/<org>/feeder
    type: managed-hosted
    public_key: "<fetched and pinned for you>"

You never copy a key by hand, link reads it from your account.

4. Publish packages

managed repository push --repo feeder ./packages/redis   # one package
managed repository push --repo feeder --directory packages/   # every package under a directory

managed builds each package tarball and uploads it; the server updates and signs the index. Bump version: in each service.yaml for a release, published versions are immutable (--force overrides). If your project has exactly one hosted repository, you can omit --repo.

Pulling private repositories, who needs the token

A public hosted repo pulls anywhere with no credentials, like the official registry. A private repo's index and tarballs require your account token, so resolve private repos on your own (logged-in) machine, managed apply and managed repository pull send your token automatically. The resolved packages are then deployed to your servers as usual; the servers themselves never need the token.

In practice:

• Local / operator-driven deploys (you run managed apply from your laptop or a logged-in CI runner): private repos just work.
• A server pulling packages by itself: it has no account token. Use a public hosted repo for anything resolved on the box, or inject the token into that environment deliberately (managed login there, or set it in CI secrets).

When in doubt, make repos that servers pull public (they're still signed) and keep private for packages you push and resolve yourself.

Managing repositories

Use the dashboard's top-level Repositories page to see every repository in your org, its visibility and package count, to create or delete repositories, toggle public/private, and add a repository to any project with one click.

From the CLI, managed repo list shows the repositories linked to the current project (hosted ones appear as managed-hosted).

What's stored where

• managed.works keeps each repository's metadata and its Ed25519 signing key (the private key encrypted at rest) and serves the registry at managed.works/repos/<org>/<name>/….
• Your managed.yaml keeps only the repository URL, type: managed-hosted, and the pinned public key, no secrets.
• Your machine keeps the account token at ~/.config/managed/auth.json.