Registry options
Every space starts from container images: Marshal’s own and the tool images of the packages in
its manifest. Where your nodes pull those images from decides how fast spaces start as your team
grows. A pull-through cache in your own environment keeps repeat pulls local and fast, and keeps
your installation clear of the per-token rate limit on registry.marshal.codes.
Which should I pick
- Evaluating, or a handful of spaces? Direct pull works out of the box with your pull token. It is the default on k3s and EKS.
- Production on GKE? Keep the default. The installer creates an Artifact Registry cache in your project and points the install at it.
- Production on EKS? If the installer builds the cluster, turn on its Harbor cache. If you
already run a registry mirror, point the install at it with
image_cache_registry. - Production on k3s or ArgoCD? Point the install at a mirror you run.
By target
| Target | Default | Cache option | Who runs the cache |
|---|---|---|---|
| single-node k3s | Direct pull | image_cache_registry, set to your own mirror | You |
| GKE | Cache on (create_registry_cache = true) | An Artifact Registry remote repository mirroring registry.marshal.codes | Terraform creates and wires it |
| EKS | Direct pull | create_harbor_cache = true (needs deploy_cluster = true), or image_cache_registry set to your own mirror | Terraform (Harbor) or you |
| ArgoCD (any cloud) | Whatever you set global.registry to | Your own mirror | You |
On AWS, the cache is Harbor rather than ECR because ECR’s pull-through cache accepts only a fixed list of public upstream registries. See EKS for what the Harbor option sets up.
One cache for all your installs
A mirror you set with image_cache_registry is a resource for your whole company. Set it up
once and point every Marshal install at it: production, staging and any others. Any Docker v2
mirror that the cluster can reach works, such as Harbor, Zot or Distribution.