Elastic Container Registry API Coverage — Spinifex Docs
Every operation in the Amazon ECR API model and whether Spinifex implements it, alongside the OCI distribution endpoint that carries the image layers.
Coverage
overview
aws
compatibility
coverage
ecr
containers
registry
ECR API Coverage
Overview
Spinifex implements 19 of the 47 operations in the ECR 2015-09-21 API model, as pinned in aws-sdk-go v1.55.8 — 40.4%.
Two endpoints, one registry
Repository metadata is served over the AWS API on the gateway endpoint. Image data moves over the OCI Distribution /v2/ endpoint on that same host, authenticated by the bearer token GetAuthorizationToken mints for docker login.
The split explains the largest group of unimplemented operations below. The layer-transfer operations — BatchCheckLayerAvailability, InitiateLayerUpload, UploadLayerPart, CompleteLayerUpload and GetDownloadUrlForLayer — are registered stubs because the /v2/ endpoint carries that traffic instead. A client using docker or any OCI-compatible tool never calls them.
Vulnerability scanning is not offered, so the image-scanning operations refuse deliberately rather than pretending to have found nothing. Registry replication is likewise absent: a deployment is a single registry, with no cross-region peer to replicate to.
Operations
Status
Meaning
✅ Implemented
A modelled operation bound to a real handler.
🟡 Stub
A registered handler that answers with a fixed or empty result.
🚫 Not supported
A registered handler that deliberately refuses, so a client sees "not offered" rather than an unknown action.
❌ Not implemented
Modelled by AWS, not registered by Spinifex.
🔒 Outside the pinned model
Registered by Spinifex but absent from the pinned model — an internal route, not a tenant-callable AWS action.
Julian Sommer