bino registryPublic registry · freeManaged or self-hosted

One reporting standard. Every team, every report.

bino registry is where report definitions live: layouts, styles, tables and commentary blocks packaged as versioned, digest-verified artefacts. A team publishes the standard once — everyone else adds it with a single command and gets the exact same result, on a laptop and in CI.

Browse the registry Registry docs Talk to sales

Immutable versions
Digest-verified installs
Public & private teams
Self-hosted or managed

Why it matters

A standard only holds when reusing it is easier than ignoring it

Copied report folders drift apart within a quarter. A registry turns your reporting standard into something teams consume instead of re-implement — and gives you the audit trail that comes with it.

Write the standard once

Your layout, your colour and scenario rules, your recurring commentary blocks become a package. Teams add it in one command instead of copying a folder that quietly diverges.

Reproducible by contract

bino.lock pins every resolved version and its digest. The report you signed off in March rebuilds from the same inputs in November — on any machine, in any pipeline.

An auditable supply chain

Published versions are immutable; nothing is ever overwritten. bino registry verify re-hashes every installed file against the lockfile and fails the pipeline on the first byte of drift.

Governance without a bottleneck

Each team owns its scope, and a four-step role ladder decides who may publish, move tags, or withdraw a version. No central ticket queue for every change to a layout.

How it works

Consume, publish, prove — three commands deep

The registry is a normal part of the build. Dependencies are declared in bino.toml, pinned in bino.lock and materialised under .bino/registry/ — installed packages then behave exactly like local documents.

bino registry add resolves the whole dependency tree, verifies the digests, writes the files and records the dependency for you:

# follow the "latest" tag
bino registry add @acme/base-layout

# or pin an exact version
bino registry add @acme/quarterly-report@1.2.3

The result lands in bino.toml — an exact version stays put, a tag name moves when you run bino registry update:

[dependencies]
"@acme/quarterly-report" = "1.2.3"
"@acme/base-layout"      = "latest"

Installed components are referenced by their scoped name and take parameters, like any local document:

apiVersion: bino.bi/v1alpha1
kind: LayoutPage
metadata:
  name: commentary-page
spec:
  children:
    - kind: Text
      ref: "@acme/commentary"
      params:
        REGION: EU

A project becomes publishable by declaring a [package] table. include decides what ships:

[package]
name = "@acme/starter-kit"
description = "A reusable kit: an IBCS table, the style it wears and a logo asset."
tags = ["starter", "ibcs"]
category = "components"
visibility = "private"
compat-cli = ">=1.0.0"
include = ["components", "styles", "resources"]

# validate the package without creating a version
bino publish --dry-run

# cut an immutable release
bino publish --bump patch

Versions are immutable, so --dry-run belongs in front of every automated publish. --visibility public|private applies when the package is first created.

A pipeline reproduces the locked state and refuses to build on drift:

export BINO_REGISTRY_TOKEN="bino_pat_..."

bino registry install
bino registry verify
bino build

Teams & visibility

Public by default. Private where it matters.

Every team owns a scope — the @acme in @acme/base-layout. Visibility is set per package, so one organisation can publish openly to the community and keep its internal layouts to itself.

Public teams

public

Readable by anyone, including anonymous callers — nobody needs an account to add a package.
The natural home for community IBCS starter kits, shared layouts and open templates.
Free on registry.bino.bi.

Private teams

private

Reading a private package requires at least the viewer role on the owning team.
To everyone else the package answers 404 — its existence never leaks, so nobody can probe for your internal names.
Publishing needs a personal access token; the CLI works against a private registry unchanged.

The role ladder

Role	May
`viewer`	Read the team’s private packages. No write action at all.
`member`	Publish versions, move non-protected tags, edit registry metadata, claim the scope.
`maintainer`	Everything a member may, plus deprecate and withdraw versions, manage members, move protected tags, transfer the scope.
`owner`	Everything a maintainer may, plus manage owners and delete the team.

Deployment

Our infrastructure, or yours

The public registry is free and stays free. Organisations that need private packages choose where the registry runs — we operate it for you, or you run it inside your own perimeter.

Community

Public registry

Free

registry.bino.bi — the shared home for public report definitions.

Unlimited public packages
Anonymous read access for consumers
Personal access tokens for CI
Passwordless login with passkeys or a one-time code

Fastest start

Enterprise

Registry as a Service

On request

We run a dedicated bino registry for your organisation.

Private packages, teams and roles
Hosting in the EU
Backups, monitoring and updates included
Onboarding for your first internal packages
Support with guaranteed response times

Enterprise

Self-hosted / on-prem

On request

One binary in your own data centre, VPC or air-gapped network.

A single self-contained binary with the web UI embedded
Bundled SQLite with full-text search — no separate database
No Node runtime in production
Container image and deployment support
Your report definitions never leave your network

The client side stays open source

bino cli is open source and free forever, and it speaks to any registry — the public one, ours under your name, or yours. Nothing about your reports is locked to a hosted service.

Technical detail

What your architects will ask before the first package ships

The full command reference and every flag live in the docs; this is the shape of the system.

Packages & versions

Package names are always @scope/name; the scope belongs to a team.
A published version is immutable — it is never overwritten or replaced.
No version ranges: either an exact pin (1.2.3) or a tag (latest) that moves on bino registry update.
The latest tag is advanced by the publish flow only; manual moves are refused.
Versions can be deprecated or withdrawn without being deleted.

Integrity

bino.lock records the exact version, digest, kind, path and dependency edges of every package. Commit it.
.bino/registry/ is regenerated from the lockfile — gitignore it.
Digests cover the canonical document form, so reformatting a file never fails a check; changed content does.
bino registry verify is an offline CI gate and exits non-zero on any failure.
list, remove and verify work without network access.

Publishing rules

At most 50 files per package, each at most one directory deep.
1 MB per manifest, 50 MB per resource.
Manifests are .yaml/.yml; resources may be .png .jpg .jpeg .webp .gif .csv .xlsx .parquet.
Symlinks, anything under secrets/ or signing/, and ConnectionSecret or SigningProfile documents are rejected — credentials cannot be published by accident.
bino lint runs first and never blocks; the registry validates the upload itself and has the final word.
Exit codes: 0 published, 1 configuration error, 3 registry rejected or unreachable.

Authentication

Personal access tokens (bino_pat_…) are created in the web UI under Settings → Tokens.
A token is exchanged for a short-lived session token on every invocation.
bino registry login stores it in ~/.bino/credentials.json (mode 0600), keyed by registry URL.
CI passes BINO_REGISTRY_TOKEN instead; bino registry login --with-token reads it from stdin.
Anonymous access is enough for everything public. Tokens are listed and revoked in the web UI.

Pointing at a registry

Resolution order: the --registry flag, then bino.toml [registry].url, then BINO_REGISTRY_URL, then ~/.bino/config.toml, then the public default.
The public default is https://registry.bino.bi.
A project’s bino.toml always wins over the environment and the global config.
One line in ~/.bino/config.toml points every project on a machine at your own registry.

Running it yourself

One self-contained binary serving the API and the web UI from a single process.
Pure-Go SQLite with full-text search built in — no second service to operate.
Migrations apply automatically on first boot against an empty data directory.
Scheduled backups out of the box, nightly by default.
Search, download and the whole read path stay available even without the authoring runtime.

Documentation

Read the reference

Everything on this page is documented in full, with every flag and edge case.

bino registry

The command reference: add, install, update, remove, list, search, info, verify, login, logout.

bino publish

Publishing a package version: flags, what ships, validation, limits and exit codes.

Registry and dependencies

The guide: package names, pin vs. tag, the lockfile workflow, CI and authentication.

Project configuration

The [package], [registry] and [dependencies] tables in bino.toml, field by field.

Name scoping

Why @scope/name is a valid document name and how scoped names resolve.

A private registry for your organisation?

Tell us how your reporting teams are set up. We will show you the shortest path to a registry of your own — hosted by us, or running in your own data centre.

Talk to sales Services