Bosca / Artifacts

Bosca Artifacts

One registry,
six formats.

Docker images, Helm charts, Maven artifacts, npm packages, ML models, and raw files — pushed with the standard tools you already use, stored once in content-addressed storage, and governed by one permission model.

How it works

Push, verify, serve.

01

Create a namespace

Group repositories under a namespace — public for anonymous pulls, or private behind group permissions. Add typed repositories: docker, helm, maven, npm, ml, or raw.

02

Push with your tools

Docker, Helm, Gradle, Maven, and npm publish straight to the registry — it speaks each client's native protocol, hashes every upload, and stores identical blobs once.

03

Pull anywhere

People pull with group permissions, machines with scoped tokens, and anyone from public namespaces. CI jobs can require an artifact and dispatch the moment it lands.

What makes it powerful

A real registry. And part of the platform.

Everything you expect from an artifact registry — native protocols, deduplicated storage, scoped credentials — plus the integrations you only get when the registry lives next to your code and CI.

Six formats

Docker images, Helm charts, Maven artifacts, npm packages, ML models, and raw files — each a typed repository inside a namespace.

Standard protocols

The OCI distribution API, Maven layout with generated metadata, the npm registry protocol with search, and Helm's index.yaml — clients don't change.

Content-addressed storage

Blobs are keyed by digest and stored once — push the same layer into two repositories and it lands as one object.

Digest verification

Uploads are hashed as they stream in; Docker content is verified against its declared digest and rejected on mismatch.

Scoped tokens

Token scopes narrow to a format, a namespace or repository, and a version pattern — granting exactly pull, push, or admin.

One permission model

Namespaces are public or private, and private access is granted to the same security groups used across Bosca.

Publish events

Every published version fires a platform event — the signal CI requirement gates and automation listen for.

A lean server

A standalone service that compiles to a GraalVM native image — bytes in S3-compatible object storage, metadata in PostgreSQL.

Deep platform integration

Not a shelf — part of the pipeline

Because the registry isn't a separate product bolted onto Bosca, a published version isn't just a file on a shelf — it's an event the rest of the platform acts on.

  • CI jobs declare artifact requirements — a release that compiles against io.bosca:core at the new version simply waits, then dispatches the moment the registry publishes it.
  • Every published version fires a platform event over pub/sub, so waiting builds re-evaluate immediately — no polling loops, no retry scripts.
  • ML models are artifacts too: recommendation models are published as versioned archives and pulled for serving from the same registry as your images and jars.
  • Namespaces, repositories, versions, tags, and permissions are managed in Studio and over a GraphQL admin API — with the same security groups as the rest of Bosca.
connected
CI job waiting on artifacts → dispatched
Event → bosca.artifacts.version.published
Model pulled from model/… for serving
Managed in Studio → Artifacts

Artifacts ship with Bosca

One registry beside your code, your CI, and your deployments — no separate product to run, no second set of accounts. The docs cover namespaces, repositories, versions, and permissions end to end.