Platform

Golden images, from your pipeline.

Primcoat is an API with a dashboard on top — not a dashboard with an API bolted on. Everything you can click, you can automate.

API-first, not API-also

The dashboard is a consumer of the same public API you use. If you can do it in the UI, you can do it from CI — there is no privileged internal endpoint doing the real work.

Async by default

Builds take minutes to hours. Triggering one returns a build ID immediately, and every response while it is still running carries a Retry-After telling you when to look again. Nothing blocks an HTTP connection for two hours.

Safe to retry

Write operations take an idempotency key, so a CI runner that retries on a network blip does not trigger a second build. Rate limits come back with a Retry-After header.

Typed from the spec

The API is described by a versioned OpenAPI 3.x specification, and the client types are generated from it rather than maintained by hand — so the types cannot drift from the API they describe.

Trigger a build

A build request returns immediately with an ID and a queue position. You are never left guessing whether the call went through.

$ curl -X POST https://api.primcoat.app/v1/image-definitions/def_9f2/builds \
    -H "Authorization: Bearer $PRIMCOAT_API_KEY" \
    -H "Idempotency-Key: release-2026-07-13"

202 Accepted
{
  "id": "bld_4c81",
  "status": "queued",
  "queue_position": 2,
  "current_stage": null
}

Poll it without guessing

A running build reports the stage it is in and when it expects to finish, and it tells you how long to wait before asking again. TheRetry-After header is on every response while the build is still going and on none once it is finished — so its absence, not a guess about elapsed time, is how your pipeline knows to stop.

$ curl -si https://api.primcoat.app/v1/builds/bld_4c81 \
    -H "Authorization: Bearer $PRIMCOAT_API_KEY"

200 OK
Retry-After: 60
{
  "id": "bld_4c81",
  "status": "running",
  "current_stage": "harden",
  "stages": [ ... ],
  "estimated_completion_at": "2026-07-13T14:52:00Z"
}

Core resources

Predictable REST paths, versioned under /v1/, with cursor-based pagination.

/v1/image-definitions: Define an OS, a policy, software, and publish targets.
/v1/image-definitions/{id}/builds: Trigger a build of a definition.
/v1/builds: List builds; read status, stages, and queue position.
/v1/builds/{id}/reports/{kind}: Retrieve the SBOM, the CVE report, or the compliance scan.
/v1/builds/{id}/artifacts: The published artifacts, with signatures and attestations.
/v1/builds/{id}/logs: Read the build log.
/v1/policies: The hardening profiles available for an OS family and version.
/v1/sources: The verified base images you can build from, with digests.
/v1/image-definitions/{id}/exceptions: Manage documented exceptions to a hardening policy.
/v1/publish-targets: Manage the destinations you publish to.
/v1/connectors: Manage the credentials those destinations authenticate with.
/v1/channels/{id}/promote: Promote a build through dev, staging, and prod.

Authentication

API keys are scoped per organization with fine-grained permissions — read, trigger builds, or administer. A CI runner that only needs to kick off a build does not need a key that can also delete a publish target.

Wire it into the pipeline you already have.

A versioned REST API, scoped keys, idempotent writes, and async builds your CI can poll without guessing.

Request access Explore the platform