OCI Images

Quilt supports Docker-compatible image ingress through OCI registry pulls and OCI-backed container create.

Primary Routes

POST   /api/build-contexts
POST   /api/oci/images/build
POST   /api/oci/images/pull
GET    /api/oci/images
GET    /api/oci/images/inspect?reference=<ref>
GET    /api/oci/images/history?reference=<ref>
DELETE /api/oci/images?reference=<ref>

Pull From a Registry

{
  "reference": "docker.io/library/alpine:3.20"
}

After the pull, launch it with normal container create plus oci: true:

{
  "name": "oci-demo",
  "image": "docker.io/library/alpine:3.20",
  "oci": true,
  "command": ["sleep", "60"]
}

Build From Your Own Context

Upload the context first:

{
  "content": "<base64 tar.gz build context>"
}

Then build from that context_id:

{
  "context_id": "uuid",
  "image_reference": "quilt.local/demo/app:latest",
  "dockerfile_path": "Dockerfile",
  "build_args": {
    "APP_ENV": "prod"
  },
  "target_stage": "runtime"
}

Important Semantics

build contexts are uploaded as JSON, not raw archive bytes
content contains base64-encoded tar or tar.gz
Quilt accepts Docker and OCI registry references
this is image compatibility, not Docker Engine API compatibility
image metadata such as env, entrypoint, and working directory come from the pulled image unless you override them

Tooling And OCI

Curated Quilt tooling still rides on OCI-backed images underneath, even when the user selects those runtimes through Quilt’s native container image selectors.

That means tools such as Aegis, RLM, and AMP still depend on the same stored image artifacts and OCI preparation semantics documented here, even though users do not have to create them with oci: true.

See Aegis, RLM, and AMP.

Next Step

Once your image is available, continue with Containers.