Skip to content
FractalOps

Internal Package Supply Chain

Internal Package Supply Chain

Section titled “Internal Package Supply Chain”

FractalOps internal packages are product artifacts, not workspace image mutations. Each package has its own source repository, release workflow, provenance, and Nexus publication contract. Nexus is the company package endpoint and cache, while GitHub remains the source-of-truth for package source.

Standard Model

Section titled “Standard Model”
package source repo
  -> CI build
  -> minified dist package
  -> SBOM + provenance
  -> private source-map/debug artifact
  -> Nexus publish
  -> FractalOps catalog/version pin
  -> Daytona/workspace runtime install with short-lived .npmrc

The package source repository owns:

  • source code, tests, build scripts, and release notes
  • package version and immutable Git tag
  • generated dist/ tarball contents
  • SBOM and provenance artifact
  • private source maps or debug bundles as CI artifacts

FractalOps owns:

  • package catalog entry and approved version pin
  • registry token minting policy
  • runtime bootstrap contract
  • project/agent authorization and audit
  • OpenBao refs for signing keys, registry broker credentials, and debug-artifact access

Nexus owns:

  • package serving and caching
  • package namespace enforcement through the FractalOps Nexus plugin
  • install/publish validation against FractalOps-issued registry JWTs

Nexus must not become the source-of-truth for package source, secrets, or release policy.

Security Contract

Section titled “Security Contract”
  • Publish only built artifacts needed by consumers.
  • Do not publish source maps in the package tarball.
  • Keep private source maps/debug bundles outside the registry package, referenced by immutable build ID.
  • Use OpenBao for registry signing keys, machine publish credentials, and source-map access credentials.
  • Runtime users and agents receive short-lived install tokens through FractalOps, not long-lived Nexus credentials.
  • Publish requires a brokered FractalOps policy decision and package scope ownership.
  • Install requires a brokered FractalOps policy decision and project/agent context.

Runtime Install Contract

Section titled “Runtime Install Contract”

Runtime images must not be customized for each internal package. Daytona and agent workspaces install approved packages at runtime using:

package spec: @fractalops/workspace-shims@0.1.30
registry:     https://npm.yamon.io/
auth:         FractalOps-issued short-lived .npmrc
pin source:   FractalOps catalog/OpenBao-backed runtime config

The runtime may cache packages under a user-local prefix, but it must reinstall when the pinned package spec changes. It must not fall back to public npm for FractalOps scopes.

Release Contract

Section titled “Release Contract”

Recommended release stages:

1. CI validates tests, lint, dependency policy, and package contents.
2. CI builds a minified package with source maps disabled in the tarball.
3. CI creates SBOM and provenance artifacts.
4. CI stores private source maps/debug bundle as restricted build artifacts.
5. CI publishes the tarball to Nexus using a short-lived FractalOps-brokered publish token.
6. CI opens or updates the FractalOps catalog/version pin PR.
7. FractalOps runtime consumes only the approved package spec.

Dist-tags are channels, not truth:

latest      = stable approved package
next        = candidate package
canary      = short-lived validation channel
deprecated  = blocked from new runtime pins

Runtime contracts should prefer exact versions for reproducibility. Dist-tags are acceptable only in CI smoke paths that immediately resolve and record the exact version.

Workspace Guardrails

Section titled “Workspace Guardrails”
  • Do not bake internal package source into workspace images.
  • Do not write permanent .npmrc files containing tokens.
  • Do not store package publish tokens in Daytona, agent prompts, or project repos.
  • Do not let npm install or pnpm install fetch internal scopes from public registries.
  • Prefer FractalOps wrappers such as fractalops-npm/fractalops-pnpm when they are present.
  • If raw package managers are used, FractalOps should emit an actionable hint to use the brokered registry flow.

Evidence

Section titled “Evidence”

Every internal package release should produce:

  • package name and exact version
  • Git repo and commit SHA
  • package tarball digest
  • SBOM artifact reference
  • provenance artifact reference
  • source-map/debug artifact reference, access controlled through OpenBao
  • Nexus publish receipt
  • FractalOps catalog/version pin commit