Container Images and Registry
Apinizer components are distributed as container images in Kubernetes environments. In environments without direct internet access or those using corporate registries (Nexus, Harbor, etc.), registry configuration must be applied on cluster nodes and the image fields in deployment files must be updated accordingly.
Which Scenario Applies to You?
Pulling images via corporate Nexus docker-proxy with containerd and deployment configuration
Image access and deployment configuration via corporate Harbor registry
Setting up your own Docker Distribution registry, uploading images, and using them in Kubernetes
Transferring images as .tar files or pushing to a local registry (version upgrade)
Apinizer Container Images
The following image repositories are used in Kubernetes deployment and Helm configuration:
| Component | Default image repository |
|---|---|
| API Manager | apinizercloud/apimanager |
| Worker | apinizercloud/worker |
| Cache | apinizercloud/cache |
| Integration | apinizercloud/integration |
| API Portal | apinizercloud/apiportal |
Replace <APINIZER_VERSION> with the version you are installing or upgrading to (e.g. 2026.04.4).
Image Field in Deployment Files
When using a corporate registry, update the image field according to your organization's registry host and path structure:
image: <REGISTRY_HOST>/<REGISTRY_PATH>/apinizercloud/cache:<APINIZER_VERSION>
Nexus docker-proxy example:
image: repo.xxx.gov.tr/docker-proxy/apinizercloud/cache:2025.07.6
Private registry example:
image: myregistry.local:5000/apinizercloud/manager:<APINIZER_VERSION>
Registry configuration must be consistent across all Kubernetes worker nodes. After changing configuration, test image pull on each node.
Related Documentation
- Kubernetes Setup — default image pull and deployment steps
- Apinizer Version Upgrade — Local Registry — image push and
kubectl set imagesteps in offline environments - Kubernetes, Docker and Containerd Troubleshooting —
ImagePullBackOff, certificate errors, etc.