Fridr

Fridr AS

Get software into restricted networks, and know exactly what you're running once it's there.

Two tools that work alone and fit together: Bifröst brings artifacts across the boundary, Sindri decides which of them are approved for which environment.

How Bifröst and Sindri work togetherAn artifact is fetched from a public registry, crosses the network boundary through Bifröst, lands in Sindri where it is promoted per environment, and CI or Kubernetes asks Sindri whether that exact digest is approved.InternetPublic registriesDocker Hub · PyPI · npm · Maven · HFboundaryBifröstpolicy-controlled crossingRestricted networkSindriidentity · evidence · lifecycledev ✓staging ✓prod ✗CI · Kubernetes“is sha256:ab12… approved for prod?”

  • Bifröst

    Pre-1.0 · early access

    Bring approved software across the air gap.

    Fetches container images, packages, and models from the open internet and delivers them into air-gapped and restricted networks through one auditable crossing.

    Get early accessHow it works →

  • Sindri

    v1 · open source

    The artifact repository that knows what's approved where.

    One Go binary for OCI and PyPI, with hosted, proxy, and virtual repositories. Artifacts carry identity, evidence, and per-environment approval instead of being copied around.

    View on GitHubWhat it does →

Bifröst

Pre-1.0 · early accessCommercial

Bring approved software across the air gap.

Move approved software across the air gap, without opening a hole back out.

Bifröst fetches container images, packages, and models from the open internet and delivers them into restricted and air-gapped networks through a single, auditable bridge.

Get early accessRead the docs
How an artifact reaches the high sideAn artifact is fetched from the open internet, crosses a single policy-controlled boundary whose mechanism is swappable, and arrives verified and logged on the air-gapped high side.Internet — any registryDocker · Maven · PyPInpm · Helm · Hugging Face · filesPolicy-controlled crossingNiFi bridge · diode relay · manual carryHigh side — no internet accessVerified & availablelogged · ready to use

The crossing mechanism is yours to choose. See the options.

How a request crosses the boundary

  1. 1

    Request

    A request or schedule comes into the Orchestrator API on the high side, and is placed on the job queue.

  2. 2

    Cross to the low side

    The bridge relays the job request across the boundary to a Minion worker with internet access.

  3. 3

    Fetch

    The Minion fetches the requested artifact from its source registry — Docker, Maven, PyPI, npm, Helm, Hugging Face, a website, or a plain file.

  4. 4

    Cross back

    The bridge relays the fetched artifact back to the high side, where it's recorded and made available. Nothing else crosses.

  • On-demand or scheduled

    Trigger a one-off pull, or set a recurring schedule — a nightly base-image sync, a weekly package mirror — and Bifröst keeps it current without anyone re-triggering it.

  • Driven by API, not a human

    The same REST surface that runs the request above — /downloads and /schedules — is what your CI pipelines call directly. No UI to script around.

  • Pick your own crossing

    This is the reference setup: one live bridge. Swap in a diode-paired bridge, a one-way diode relay, or fully manual carry to match your compliance posture — see architecture options.

Built for restricted networks

One set of Minion workers per ecosystem, each speaking that registry's protocol directly rather than shelling out to its CLI.

  • Docker
  • Maven
  • Python
  • npm
  • Helm
  • Files
  • Websites
  • Hugging Face

Every request has an owner

Bifröst sits behind Keycloak, so every download request and every scheduled job is tied to an OAuth2/OIDC identity — not just a source IP. Job history is kept, so you can answer "what came in, and who asked for it" after the fact.

The bridge is the only door

Minion workers never talk to the high side directly. The bridge is the single, policy-controlled crossing point — the one thing you have to trust, instead of every worker on the low side.

Sindri

v1 · open sourceApache 2.0

The artifact repository that knows what's approved where.

Not “does this image exist?” but “is exactly this artifact approved for this environment?”

A lightweight, multi-protocol artifact repository in a single Go binary. It starts from one Docker Compose file and grows to a Kubernetes install without switching products. It sits between heavyweight Nexus/Artifactory and a patchwork of Harbor, Verdaccio, and a homegrown PyPI server.

View on GitHubQuickstart
payments-api:1.4.2
├─ identity   sha256:abc123…
├─ owner      team:payments
├─ source     git abc123
├─ evidence   sbom · signature
└─ lifecycle  dev ✓ staging ✓ prod ✗

  • Identity, not file copies

    An artifact isn't copied between repositories as it matures. It keeps one identity (digest, owner, provenance, evidence) and its trust status changes per environment.

  • One core, many protocols

    Protocol adapters sit on one content-addressed store, so lifecycle and policy exist once. Hosted, proxy, and virtual repositories are kept separate, and that separation blocks dependency confusion.

  • Config as code

    One short YAML file declares repositories, stages, and access, reconciled on startup with no apply step. Teams that outgrow it use enveloped manifests and org policy from CI.

Where it is

  • OCI / DockerToday
  • Helm (OCI)Today
  • PyPIToday
  • SBOM & signaturesToday
  • npmNext
  • Scan to evidenceLater
  • MavenLater
  • K8s admissionLater

Better together

Planned

Each tool stands on its own. In an air-gapped or restricted Sindri install, Bifröst becomes its native downloader: the open-source repository gets a way in, and the bridge gets a place to land.

  1. 1

    A pull misses

    A developer or CI job asks Sindri for an image or package the restricted network doesn't have yet.

  2. 2

    Bifröst fetches it

    The proxy repository's upstream is Bifröst, not the internet. The miss becomes a Bifröst request, and the artifact crosses the boundary through your chosen mechanism.

  3. 3

    It lands with a history

    The artifact arrives in Sindri as a proxied artifact with its provenance attached, and from there goes through the same lifecycle gates as everything else.

Start with either. Grow into both.

Try Sindri (open source)Talk to us about Bifröst