# Limits und Ressourcen

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

# Limits und Ressourcen

## Pro Dienst zugewiesene Ressourcen

| Ressource | Garantiertes Minimum | Obergrenze |
|-----------|:---:|:---:|
| CPU | 50 m (0,05 Kern) | 1 Kern |
| Speicher | 64 MB | 512 MB |

> Diese Obergrenzen decken die große Mehrheit der Anwendungsfälle ab. Wenn Ihre Anwendung mehr benötigt (aufwendige Verarbeitung, umfangreicher Build), kontaktieren Sie den Support für eine Anpassung.

## Speicher

- **Anwendungsdienste**: das Dateisystem ist flüchtig. Alles, was auf die Festplatte geschrieben wird, verschwindet beim Neustart oder Redeployment des Pods. Speichern Sie dort niemals zu bewahrende Daten.
- **Datenbanken**: persistenter Speicher über ein Kubernetes-Volume (PVC). Die Daten überstehen Neustarts, Updates und Migrationen.

## Datenbanken

Ein Datenbankdienst erhält eine größere Zuteilung als ein Anwendungsdienst, und sein Speicher ist persistent:

| Ressource | Garantiertes Minimum | Obergrenze |
|-----------|:---:|:---:|
| CPU | 100 m (0,1 Kern) | 1 Kern |
| Arbeitsspeicher | 256 MB | 1 GB |

### Verwaltete Datenbanken und das Kontingent des Plans

Es gibt zwei Wege zu einer Datenbank, mit zwei Zählregeln:

- **Verwaltete Datenbank** (MySQL oder PostgreSQL, erstellt auf der Seite Datenbanken): Sie läuft auf den gemeinsamen Datenbankservern der Plattform und wird **nicht** auf vCPU und Arbeitsspeicher Ihres Plans **angerechnet**. Sie hat eigene Grenzen: mit einem bezahlten Abonnement bis zu **10 Datenbanken mit je 10 GB** und 50 gleichzeitigen Verbindungen; ohne Abonnement **eine Datenbank mit 500 MB** und 10 Verbindungen.
- **Datenbank als Dienst** in einem Projekt (Container mit MySQL, MariaDB, PostgreSQL, MongoDB oder Redis): ein Dienst wie jeder andere. Sie verbraucht vCPU, Arbeitsspeicher und Speicher Ihres Plans, innerhalb der Grenzen der Tabelle oben.

Die Ressourcen eines Plans (vCPU, Arbeitsspeicher, Speicher, Traffic) bilden ein gemeinsames Budget für alle Dienste, die er abdeckt: Ein Plan mit unbegrenzten Diensten erlaubt beliebig viele Dienste, innerhalb desselben Budgets.

## Build

- maximale Build-Dauer: **1 Stunde**. Danach wird der Build gestoppt und das Deployment als fehlgeschlagen markiert. Ein Build, der dieses Limit erreicht, hängt fast immer (ein Entwicklungsserver anstelle des Build-Befehls gestartet, ein Skript, das auf eine Eingabe wartet);
- empfohlene Image-Größe: **weniger als 2 GB**, für schnelle Deployments;
- Builds verbrauchen nicht die Ressourcen Ihrer Dienste: sie laufen in einer separaten Umgebung mit eigener Zuteilung.

## Netzwerk

- jeder Dienst wird über HTTPS auf seiner/seinen Domain(s) exponiert;
- keine künstliche Grenze bei der Anzahl gleichzeitiger Verbindungen;
- die verfügbare Bandbreite hängt vom abgeschlossenen Plan ab.

## Verfügbarkeit

Die Infrastruktur strebt eine Verfügbarkeit von **99,5 %** an, ohne vertragliche Zusage. Geplante Wartungsarbeiten werden im Voraus auf der [Statusseite](/status) angekündigt.
