# Límites y recursos

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

# Límites y recursos

## Recursos asignados por servicio

| Recurso | Mínimo garantizado | Tope |
|-----------|:---:|:---:|
| CPU | 50 m (0,05 núcleo) | 1 núcleo |
| Memoria | 64 MB | 512 MB |

> Estos topes cubren la gran mayoría de los usos. Si tu aplicación necesita más (procesamiento pesado, build voluminoso), contacta con soporte para un ajuste.

## Almacenamiento

- **Servicios de aplicación**: el sistema de archivos es efímero. Todo lo escrito en disco desaparece al reiniciar o redesplegar el pod. Nunca almacenes ahí datos que deban conservarse.
- **Bases de datos**: almacenamiento persistente mediante un volumen de Kubernetes (PVC). Los datos sobreviven a reinicios, actualizaciones y migraciones.

## Bases de datos

Un servicio de tipo base de datos recibe una asignación mayor que un servicio aplicativo, y su almacenamiento es persistente:

| Recurso | Mínimo garantizado | Tope |
|-----------|:---:|:---:|
| CPU | 100 m (0,1 núcleo) | 1 núcleo |
| Memoria | 256 MB | 1 GB |

### Bases gestionadas y cuota del plan

Hay dos formas de tener una base de datos, con dos reglas de cómputo:

- **Base gestionada** (MySQL o PostgreSQL creada desde la página Bases de datos): funciona en los servidores de bases compartidos de la plataforma y **no se descuenta** de la vCPU ni de la memoria de tu plan. Tiene sus propios límites: con una suscripción de pago, hasta **10 bases de 10 GB** y 50 conexiones simultáneas cada una; sin suscripción, **una base de 500 MB** y 10 conexiones.
- **Base lanzada como servicio** en un proyecto (contenedor MySQL, MariaDB, PostgreSQL, MongoDB o Redis): es un servicio como cualquier otro. Consume la vCPU, la memoria y el almacenamiento de tu plan, dentro de los límites de la tabla anterior.

Los recursos de un plan (vCPU, memoria, almacenamiento, tráfico) forman una bolsa compartida por los servicios que cubre: un plan con servicios ilimitados permite crear todos los que necesites, dentro de esa misma bolsa.

## Build

- tiempo máximo de un build: **1 hora**. Más allá, el build se detiene y el despliegue se marca como fallido. Un build que alcanza este límite casi siempre está bloqueado (un servidor de desarrollo lanzado en lugar del comando de build, un script esperando una entrada);
- tamaño de imagen recomendado: **menos de 2 GB**, para despliegues rápidos;
- los builds no consumen los recursos de tus servicios: se ejecutan en un entorno separado, con su propia asignación.

## Red

- cada servicio se expone en HTTPS en su(s) dominio(s);
- sin límite artificial en el número de conexiones simultáneas;
- el ancho de banda disponible depende del plan contratado.

## Disponibilidad

La infraestructura apunta a una disponibilidad del **99,5 %**, sin compromiso contractual. Los mantenimientos planificados se anuncian con antelación en la [página de estado](/status).