On-Prem Release Manifests

Every on-prem release is defined by a manifest with digest-pinned image references.

Generated from the app repo

Create a release from the app repo with:

cd /Users/otr/code/packetsafari
node scripts/release_packetsafari.mjs

The release helper builds and publishes:

• frontend
• backend
• sharkd

The manifest also includes worker, which reuses the backend image digest.

Manifest shape

The installer expects images to be a flat map of Docker image references:

{
  "version": "10.0.1",
  "gitTag": "v10.0.1",
  "gitCommit": "<commit>",
  "builtAt": "2026-03-12T12:00:00Z",
  "configSchemaVersion": 1,
  "requiredEnv": [
    "PACKETSAFARI_AUTH_JWT_SECRET_KEY",
    "REDIS_PASSWORD",
    "PACKETSAFARI_CAPTURE_SHARKD_JWT_SECRET",
    "SHARKD_JWT_SECRET",
    "PACKETSAFARI_MAIL_SERVER",
    "PACKETSAFARI_MAIL_PORT",
    "PACKETSAFARI_MAIL_DEFAULT_SENDER",
    "PACKETSAFARI_MAIL_USERNAME",
    "PACKETSAFARI_MAIL_PASSWORD"
  ],
  "images": {
    "frontend": "registry.example.com/packetsafari/frontend@sha256:...",
    "backend": "registry.example.com/packetsafari/backend@sha256:...",
    "worker": "registry.example.com/packetsafari/backend@sha256:...",
    "sharkd": "registry.example.com/packetsafari/sharkd@sha256:..."
  }
}

The release helper also writes imageDetails for audit and troubleshooting, but the on-prem compose renderer consumes the plain values in images.

Required fields

For a release to be deployable, the target manifest must include:

• version
• images.frontend
• images.backend
• images.worker or a backend image that can be reused for worker
• images.sharkd
• images.egress-dns
• images.egress-ironproxy
• images.egress-firewall

The deployment status page checks both:

• whether the target manifest is structurally complete
• whether the current deployment has all required environment keys for that target release

If the admin UI shows the target as Blocked, fix the missing env keys or publish a complete manifest before upgrading.