# Limits and resources

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

# Limits and resources

## Resources allocated per service

| Resource | Guaranteed minimum | Cap |
|-----------|:---:|:---:|
| CPU | 50 m (0.05 core) | 1 core |
| Memory | 64 MB | 512 MB |

> These caps cover the vast majority of use cases. If your application needs more (heavy processing, large build), contact support for an adjustment.

## Storage

- **Application services**: the filesystem is ephemeral. Anything written to disk disappears when the pod restarts or redeploys. Never store data there that needs to persist.
- **Databases**: persistent storage via a Kubernetes volume (PVC). Data survives restarts, updates, and migrations.

## Databases

A database service gets a larger allocation than an application service, and its storage is persistent:

| Resource | Guaranteed minimum | Ceiling |
|-----------|:---:|:---:|
| CPU | 100 m (0.1 core) | 1 core |
| Memory | 256 MB | 1 GB |

### Managed databases and your plan quota

There are two ways to get a database, with two counting rules:

- **Managed database** (MySQL or PostgreSQL created from the Databases page): it runs on the platform's shared database servers and is **not counted** against your plan's vCPU or memory. It has its own limits: with a paid subscription, up to **10 databases of 10 GB** with 50 concurrent connections each; without a subscription, **one 500 MB database** with 10 connections.
- **Database run as a service** in a project (MySQL, MariaDB, PostgreSQL, MongoDB or Redis container): it is a service like any other. It uses your plan's vCPU, memory and storage, within the limits of the table above.

A plan's resources (vCPU, memory, storage, traffic) are one envelope shared by the services it covers: a plan with unlimited services lets you create as many as you need, within that same envelope.

## Build

- maximum build time: **1 hour**. Past that, the build is stopped and the deployment marked as failed. A build that reaches this limit is almost always stuck (a development server started instead of the build command, a script waiting for input);
- recommended image size: **under 2 GB**, for fast deployments;
- builds do not consume your services' resources: they run in a separate environment with their own allocation.

## Network

- each service is exposed over HTTPS on its domain(s);
- no artificial limit on the number of simultaneous connections;
- available bandwidth depends on the subscribed plan.

## Availability

The infrastructure targets **99.5%** availability, with no contractual commitment. Scheduled maintenance is announced in advance on the [status page](/status).