# Limites et ressources

Source : https://webgune.cloud/eu-eu/docs/limites-ressources · Mis à jour le 2026-10-27

# 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](/status).