Registry as a Service
Registry privé suisse, satellite du Kubernetes managé. Auth dans le projet.
Le Registry as a Service Hikube est un registre de conteneurs privé, satellite du Kubernetes managé. Vos images restent en Suisse, authentifiées dans votre tenant, consommables par les workers et vos pipelines CI. Ce n’est pas GHCR, pas ECR, pas un marketplace d’images.
- Privé par tenant
- Satellite Kubernetes
- CI dans le VPC
- ISO 27001
- 3 DC
- SLA 99,99 %
Évite de pousser des images métier vers Docker Hub, GHCR ou ECR (Cloud Act). Utile pour une chaîne GitOps dont le cluster, le registry et l’object storage partagent la même juridiction. Compatible docker, buildah, kaniko et les clients Kubernetes habituels. Intégration Terraform en préparation.
Capacités
Privé par tenant
Pas de dépôt public par défaut. Accès authentifié dans le projet.
Satellite Kubernetes
Les workers tirent. Flux ou Argo restent. Pas un PaaS qui cache le registry.
CI dans le VPC
Push depuis runners self-hosted ou dans le VPC. Jetons de préférence dans Vault.
Pas GHCR, pas ECR
Auth dans le projet. Pas un marketplace d’images.
Même juridiction que le cluster
Genève, Gland, Lucerne. Pas un cache Europe d’un groupe US.
Pilotage API
API Hikube et console. Intégration Terraform en préparation.
Dans le détail
GHCR et ECR sont des services de groupes US. Même avec un cache en Europe, le fournisseur reste soumis au Cloud Act. Un registry Hikube aligne images et cluster sur le même opérateur suisse. Le trade-off est honnête : pas l’écosystème marketplace d’ECR, pas de scan de vulnérabilités dans l’offre. La résidence et l’audit.
Jetons ou identifiants de projet, stockés de préférence dans Vault as a Service plutôt que dans les variables d’un SaaS CI américain. Les runners peuvent vivre dans le VPC. Détail dans docs.hikube.cloud. Intégration Terraform en préparation : aujourd’hui, API Hikube et console.
C’est un registry OCI : la séquence est celle que vous connaissez, sans commande maison. Les écrans et la référence d’API sont dans docs.hikube.cloud ; l’ordre, lui, ne bouge pas.
- Créez un jeton de projet dans la console, et rangez-le dans Vault plutôt que dans les variables d’un SaaS CI américain : le coffre à secrets
- Authentifiez le client, docker, buildah, kaniko, avec ce jeton, depuis un runner qui peut vivre dans le VPC
- Taguez l’image avec l’adresse du registry, puis poussez-la : c’est un push OCI standard, pas un format propriétaire
- Dans le cluster, référencez l’image et donnez au namespace le secret de tirage : sans lui, le pod reste en ImagePullBackOff, et c’est l’erreur la plus fréquente
- Vérifiez le tirage depuis un nœud du cluster, pas depuis votre poste : c’est le chemin réseau du cluster qui compte, pas le vôtre
La rétention des artefacts est de votre côté, et c’est une charge réelle : une CI qui pousse à chaque commit remplit un registry vite, et personne ne s’en aperçoit avant la facture de stockage. Décidez tôt combien de tags vous gardez par dépôt, et faites-le appliquer par votre pipeline plutôt que par une purge manuelle un vendredi. Hikube ne publie pas de politique de nettoyage automatique ni de quota par dépôt sur cette page : si votre chaîne en dépend, faites-les confirmer avant de la construire. Le scan de vulnérabilités n’est pas fourni non plus, et c’est dit plus bas sans détour.
Hidora SA opère le registry, les trois DC et le support FR/EN. Vous gardez images, tags, rétention d’artefacts, CI et les secrets d’accès. Les workers Kubernetes tirent ; Hikube les répartit automatiquement, vous ne choisissez pas le DC.
Chaîne GitOps suisse : cluster + registry + S3 + Vault. Images d’entraînement GPU. Images métier qui ne doivent pas aller sur GHCR. Ce n’est pas un miroir Docker Hub mondial.
Hikube ne fournit pas de scan de vulnérabilités. Le registry est privé, authentifié, en Suisse. Les outils de scan que vous opérez déjà (CI, admission) restent les vôtres. Flux CD est un addon optionnel du cluster managé : la plateforme Kubernetes.
Produits liés
Questions fréquentes
Non. Hikube est un cloud souverain : compute, stockage, sauvegardes et métadonnées restent sur trois datacenters indépendants en Suisse (Genève, Gland, Lucerne). Aucune réplication vers l’UE ou les États-Unis.
L’opérateur est Hidora SA, société suisse à Lancy (Genève), sans maison-mère US. Compute, stockage, backups et métadonnées restent à Genève, Gland et Lucerne. Ce n’est pas la même base légale qu’AWS, Azure ou GCP. Nous ne sommes pas votre avocat : le RGPD pour des données UE en Suisse s’appuie notamment sur l’adéquation.
Par l’API Hikube et la console. Intégration Terraform et Cluster API en préparation. kubectl, Helm et les clients S3 restent. Docs : docs.hikube.cloud.
Oui : push/pull d’images OCI depuis docker, buildah, kaniko et les clients Kubernetes habituels.
Non. C’est le registry privé du tenant, satellite du Kubernetes managé. Le Marketplace Hikube n’est pas ouvert : /marketplace (liste d’attente, noindex).
Non. Il n’y en a pas. Le registry reste privé, en Suisse. Vos outils de CI et d’admission restent les vôtres.
Oui. Hikube est un cloud suisse IaaS (VMs, Kubernetes managé, GPU, S3, backup, vault) opéré par Hidora SA sur trois datacenters : Genève, Gland, Lucerne. SLA publié 99,99 %, ISO 27001, support ingénieur en français et en anglais. Ce n’est pas de l’hébergement web mutualisé. Les GPU sont dans l’essai de 14 jours. Windows Server est une image licenciée sur les instances.
Prêt à tourner sur une infra 100 % suisse ?
14 jours d’essai, sans carte. GPU inclus.