Registry as a Service
Swiss private registry, satellite of managed Kubernetes. Auth in the project.
Hikube Registry as a Service is a private container registry, satellite of managed Kubernetes. Images stay in Switzerland, authenticated in your tenant, consumable by workers and your CI pipelines. This is not GHCR, not ECR, not an image marketplace.
- Private per tenant
- Kubernetes satellite
- CI in the VPC
- ISO 27001
- 3 DC
- SLA 99.99%
Avoids pushing business images to Docker Hub, GHCR or ECR (CLOUD Act). Useful for a GitOps chain whose cluster, registry and object storage share one jurisdiction. Compatible with docker, buildah, kaniko and usual Kubernetes clients. Terraform integration in preparation.
Capabilities
Private per tenant
No public repository by default. Authenticated access in the project.
Kubernetes satellite
Workers pull. Flux or Argo stay. Not a PaaS that hides the registry.
CI in the VPC
Push from self-hosted runners or runners in the VPC. Tokens preferably in Vault.
Not GHCR, not ECR
Auth in the project. Not an image marketplace.
Same jurisdiction as the cluster
Geneva, Gland, Lucerne. Not a US group’s Europe cache.
API control
Hikube API and console. Terraform integration in preparation.
In detail
GHCR and ECR are US-group services. Even with a European cache, the provider stays under the CLOUD Act. A Hikube registry aligns images and cluster on the same Swiss operator. The trade-off is honest: not ECR’s marketplace ecosystem, no vulnerability scan in the offer. Residency and audit.
Project tokens or credentials, preferably stored in Vault as a Service rather than in a US CI SaaS variable store. Runners can live in the VPC. Detail in docs.hikube.cloud. Terraform integration in preparation: today, Hikube API and console.
It is an OCI registry: the sequence is the one you know, with no bespoke command. The screens and the API reference are in docs.hikube.cloud; the order does not change.
- Create a project token in the console and put it in Vault rather than in a US CI SaaS’s variables: the secrets vault
- Authenticate the client, docker, buildah, kaniko, with that token, from a runner that can live in the VPC
- Tag the image with the registry address, then push: it is a standard OCI push, not a proprietary format
- In the cluster, reference the image and give the namespace the pull secret: without it the pod stays in ImagePullBackOff, which is the most common mistake
- Verify the pull from a cluster node, not from your laptop: it is the cluster’s network path that matters, not yours
Artefact retention is on your side, and it is real work: a CI that pushes on every commit fills a registry fast, and nobody notices before the storage bill. Decide early how many tags you keep per repository, and have your pipeline enforce it rather than a manual purge on a Friday. Hikube publishes no automatic cleanup policy and no per-repository quota on this page: if your chain depends on either, have them confirmed before building on them. Vulnerability scanning is not provided either, and that is said plainly below.
Hidora SA operates the registry, the three DCs and FR/EN support. You keep images, tags, artefact retention, CI and access secrets. Kubernetes workers pull; Hikube spreads them automatically, you do not choose the DC.
Swiss GitOps chain: cluster + registry + S3 + Vault. GPU training images. Line-of-business images that must not go to GHCR. This is not a worldwide Docker Hub mirror.
Hikube does not provide a vulnerability scan. The registry is private, authenticated, in Switzerland. Scan tools you already operate (CI, admission) stay yours. Flux CD is an optional addon on the managed cluster: the Kubernetes platform.
Related products
Managed KubernetesDedicated managed Kubernetes in Switzerland, workers in your tenant.
GPU cloudSix dedicated NVIDIA cards, 24 to 141 GB.- VPC & subnetsVMware VLANs to VPC and subnets, three Swiss DCs, no SDN fabric to repurchase.
- Vault as a ServiceSecrets and keys in Switzerland, for apps, CI and Kubernetes.
Frequently asked questions
No. Hikube is a sovereign cloud: compute, storage, backups and metadata stay on three independent Swiss datacenters (Geneva, Gland, Lucerne). There is no replication to the EU or the United States.
The operator is Hidora SA, a Swiss company in Lancy (Geneva), with no US parent. Compute, storage, backups and metadata stay in Geneva, Gland and Lucerne. That is not the same legal basis as AWS, Azure or GCP. We are not your counsel: GDPR for EU data in Switzerland relies in particular on adequacy.
Through the Hikube API and the console. Terraform and Cluster API integration in preparation. kubectl, Helm and S3 clients stay. Docs: docs.hikube.cloud.
Yes: OCI image push/pull from docker, buildah, kaniko and usual Kubernetes clients.
No. It is the tenant’s private registry, satellite of managed Kubernetes. The Hikube Marketplace is not open: /marketplace (waitlist, noindex).
No. There is none. The registry stays private, in Switzerland. Your CI and admission tools stay yours.
Yes. Hikube is Swiss cloud IaaS (VMs, managed Kubernetes, GPU, S3, backup, vault) operated by Hidora SA on three datacenters: Geneva, Gland, Lucerne. Published SLA 99.99%, ISO 27001, engineer support in French and English. It is not shared web hosting. GPUs are in the 14-day trial. Windows Server is a licensed image on instances.
Ready to run on 100% Swiss infrastructure?
14-day trial, no credit card. GPUs included.
