Limites et ressources
Mis à jour le 27 octobre 2026
Limites et ressources
Ressources allouées par service
| Ressource | Minimum garanti | Plafond |
|---|---|---|
| CPU | 50 m (0,05 cœur) | 1 cœur |
| Mémoire | 64 Mo | 512 Mo |
Ces plafonds couvrent la grande majorité des usages. Si votre application a besoin de plus (traitement lourd, build volumineux), contactez le support pour un ajustement.
Stockage
- Services applicatifs : le système de fichiers est éphémère. Tout ce qui est écrit sur disque disparaît au redémarrage ou au redéploiement du pod. N'y stockez jamais de données à conserver.
- Bases de données : stockage persistant via un volume Kubernetes (PVC). Les données survivent aux redémarrages, mises à jour et migrations.
Bases de données
Un service de type base de données reçoit une allocation plus large qu'un service applicatif, et son stockage est persistant :
| Ressource | Minimum garanti | Plafond |
|---|---|---|
| CPU | 100 m (0,1 cœur) | 1 cœur |
| Mémoire | 256 Mo | 1 Go |
Bases gérées et quota du plan
Deux façons d'avoir une base de données, deux règles de décompte :
- Base gérée (MySQL ou PostgreSQL créée depuis la page Bases de données) : elle tourne sur les serveurs de bases mutualisés de la plateforme et n'est pas décomptée du vCPU ni de la mémoire de votre plan. Elle a ses propres limites : avec un abonnement payant, jusqu'à 10 bases de 10 Go et 50 connexions simultanées chacune ; sans abonnement, une base de 500 Mo et 10 connexions.
- Base lancée comme service dans un projet (conteneur MySQL, MariaDB, PostgreSQL, MongoDB ou Redis) : c'est un service comme un autre. Elle consomme le vCPU, la mémoire et le stockage de votre plan, dans les limites du tableau ci-dessus.
Les ressources d'un plan (vCPU, mémoire, stockage, trafic) forment une enveloppe partagée par les services qu'il couvre : un plan aux services illimités permet d'en créer autant que nécessaire, dans cette même enveloppe.
Build
- délai maximum d'un build : 1 heure. Au-delà, le build est arrêté et le déploiement marqué en échec. Un build qui atteint cette limite est presque toujours bloqué (serveur de développement lancé à la place de la commande de build, script qui attend une saisie) ;
- taille d'image recommandée : moins de 2 Go, pour des déploiements rapides ;
- les builds ne consomment pas les ressources de vos services : ils tournent dans un environnement séparé, avec leur propre allocation.
Réseau
- chaque service est exposé en HTTPS sur son ou ses domaines ;
- pas de limite artificielle sur le nombre de connexions simultanées ;
- la bande passante disponible dépend du plan souscrit.
Disponibilité
L'infrastructure vise une disponibilité de 99,5 %, sans engagement contractuel. Les maintenances planifiées sont annoncées à l'avance sur la page de statut.