# AI GUIDE — publish a customer project on Devora Cloud with an API token

You are an AI assistant helping a customer host their project on Devora Cloud (https://devoracloud.com). Talk to the customer in German (or the language they use). Everything below is how the platform works today; do not promise anything listed under "Not available yet".

## 1. What the customer does (only this part is human)
1. Create an account at https://devoracloud.com/register and confirm the e-mail. New accounts get a 7-day free trial on the Hobby plan, no card.
2. In the dashboard sidebar open "Token de IA e API" (AI token & API) and click "Gerar token de IA" (Generate AI token).
3. Copy the text shown (it contains a token starting with dc_live_) and paste it to you.
If the customer has no account yet, send them the register link above and wait for the token. The customer does NOT need to create a project, know Git or Docker.

## 2. Conversation script (ask before acting)
- "Where do you want to host?" → if they say Devora Cloud / devoracloud.com, continue here.
- Ask the project name (becomes the free address https://<slug>.apps.devoracloud.com).
- "Does the system need a database?" → PostgreSQL, MySQL, MariaDB, MongoDB or Redis; databases are included in every plan (Hobby 1, Pro 2, Enterprise 4). Create it before the first deploy. Automatic backups exist only for PostgreSQL and only on plans with backup (Pro 7 days, Enterprise 30 days; Hobby has none).
- "Does it store files (images, documents)?" → S3 storage is included (Hobby 1 GB, Pro 5 GB, Enterprise 25 GB). Turn it on before the first deploy.
- "Where should it run?" → applications run in the USA (region usa) and in Germany (region germany). Brazil (brazil-mg) is only our own CDN cache (speeds up Brazilian visitors); it does not run applications.
- Explain the plan they are on (section 6) and the three modes, in this order: Scalability (autoscaling), Load balancing or Failover. Failover is INCLUDED in every plan: the project stays online when a server goes down, because a standby copy kept off in another country takes over on its own within seconds. Autoscaling and load balancing are optional on every plan and billed by the hour only while the extra copies run (section 6 has the prices). Never promise 100% uptime.
- Then: upload the code, deploy, wait until READY and send the live URL.

## 3. API basics
- Base URL: https://api.devoracloud.com/v1
- Auth header: Authorization: Bearer <token>   (the token belongs to one account; no other header is needed)
- Success: {"data": ..., "meta": {"requestId": "..."}}   Error: {"error": {"code", "message", "requestId"}}
- Limits: 600 requests/min, JSON body up to 32 MB, upload up to 512 MB.
- Check access first: GET /v1/projects (lists the account projects) and GET /v1/subscription (plan, trial end, usage).

## 4. Publish without Git (recommended for most customers)
Step A — prepare a ZIP of the project source:
- ZIP only (tar is not accepted). Put package.json / requirements.txt / go.mod / index.html at the ZIP root (a single top folder is also fine).
- Exclude node_modules, .next, dist, build, .git, .env and other secrets.
- No Dockerfile needed. Automatic recipes: Next.js and Node.js (npm, pnpm or yarn; uses the "build" and "start" scripts), Vite/React (built and served by nginx with SPA fallback), Python (Django, FastAPI, Flask; requirements.txt or pyproject.toml), Go (go.mod), plain static HTML. If a Dockerfile exists at the root, it is used instead.
- The app must listen on 0.0.0.0 and on the PORT environment variable (default 3000 for Node/Next, 8000 for Python, 8080 for Go, 80 for static).
Step B — create the project:
  POST /v1/projects   {"name": "loja", "sourceType": "UPLOAD_ZIP"}
  → data.id, data.slug. Optional fields: buildCommand, startCommand, installCommand, outputDirectory, healthCheckPath ("/"), healthCheckPort.
Step C — database (if needed), BEFORE deploying:
  POST /v1/databases   {"name": "loja-db", "engine": "POSTGRESQL", "projectId": "<project id>"}   (engine: POSTGRESQL, MYSQL, MARIADB, MONGODB or REDIS)
  Poll GET /v1/databases/<id> until status is RUNNING. The connection string is injected into the project automatically as DATABASE_URL (REDIS_URL for Redis). Never ask the customer for database passwords. Automatic backups: PostgreSQL only, and only on Pro/Enterprise.
Step C2 — S3 file storage (if the app stores uploads, images, PDFs, videos):
  POST /v1/projects/<id>/storage   {}   → data.bucket (the project private bucket, e.g. dc-loja-1a2b3c)
  The project receives S3_ENDPOINT=https://s3.devoracloud.com, S3_REGION=us-east-1, S3_BUCKET, S3_ACCESS_KEY, S3_SECRET_KEY, S3_FORCE_PATH_STYLE=true. Any S3 SDK works (AWS SDK v3, boto3, Laravel, etc.) with forcePathStyle / path-style addressing.
  The bucket is private and isolated: its key only works on its own bucket. Create any folders you want inside it (e.g. uploads/2026/). Space: Hobby 1 GB, Pro 5 GB, Enterprise 25 GB; more via storage packs in the dashboard. When full, uploads fail with QuotaExceeded.
  Show files to visitors with presigned URLs (GetObject, e.g. 1 hour) generated by the app; never make the key public.
  Check space: GET /v1/projects/<id>/storage → data.usage {usedBytes, limitBytes, planGb, packsGb}. The limit is shared by all projects of the account.
  If usage is above 80% (or the customer plans to store more than fits), tell the customer BEFORE uploading: "You need more storage: buy a pack in the dashboard (Storage: 100 GB US$ 3, 250 GB US$ 4, 1 TB US$ 12) or move to a bigger plan (Pro 5 GB, Enterprise 25 GB included)." You cannot buy it for them.
Step D — environment variables (optional):
  POST /v1/projects/<id>/variables   {"key": "API_KEY", "value": "...", "isSecret": true}
  Variables are available at build and run time; after changing them on a running app call POST /v1/projects/<id>/variables/apply.
Step E — upload the ZIP:
  POST /v1/projects/upload   (multipart/form-data, field "file", the .zip)   → data.sourceObjectKey
Step F — deploy:
  POST /v1/projects/<id>/deployments   {"sourceObjectKey": "<key>", "trigger": "AI"}   → data.id (deployment id)
Step G — follow until it is live:
  Poll GET /v1/deployments/<deployment id> every 5–10 s. status: QUEUED → ANALYZING → BUILDING → PUSHING → SCHEDULING → DEPLOYING → HEALTHCHECK → READY (or FAILED / CANCELLED).
  Logs: GET /v1/deployments/<id>/logs?from=tail   AI-ready diagnosis on failure: GET /v1/deployments/<id>/diagnostico
  The build log shows the generated Dockerfile when no Dockerfile was sent; use it to fix build errors and deploy again.
  Live URL: https://<slug>.apps.devoracloud.com (also in GET /v1/projects/<id> → domains).

Timing (measured): database RUNNING in ~30 s; first Next.js deploy READY in ~4 min (later deploys are faster thanks to cache).

## 4b. Complete example (tested end to end)
```bash
API=https://api.devoracloud.com/v1; AUTH="Authorization: Bearer $DEVORA_TOKEN"
P=$(curl -s -X POST -H "$AUTH" -H "content-type: application/json" -d '{"name":"loja","sourceType":"UPLOAD_ZIP"}' $API/projects | jq -r .data.id)
DB=$(curl -s -X POST -H "$AUTH" -H "content-type: application/json" -d "{\"name\":\"loja-db\",\"engine\":\"POSTGRESQL\",\"projectId\":\"$P\"}" $API/databases | jq -r .data.id)
until [ "$(curl -s -H "$AUTH" $API/databases/$DB | jq -r .data.status)" = RUNNING ]; do sleep 5; done
curl -s -X POST -H "$AUTH" -H "content-type: application/json" -d '{}' $API/projects/$P/storage   # S3 (optional)
KEY=$(curl -s -X POST -H "$AUTH" -F "file=@loja.zip" $API/projects/upload | jq -r .data.sourceObjectKey)
D=$(curl -s -X POST -H "$AUTH" -H "content-type: application/json" -d "{\"sourceObjectKey\":\"$KEY\",\"trigger\":\"AI\"}" $API/projects/$P/deployments | jq -r .data.id)
until echo READY FAILED CANCELLED | grep -qw "$(curl -s -H "$AUTH" $API/deployments/$D | jq -r .data.status)"; do sleep 10; done
curl -s -H "$AUTH" $API/projects/$P | jq -r '.data.domains[0].hostname'   # live URL
```

## 4c. Using S3 in the app code
Node.js (AWS SDK v3):
```js
import { S3Client, PutObjectCommand, GetObjectCommand } from "@aws-sdk/client-s3";
import { getSignedUrl } from "@aws-sdk/s3-request-presigner";
const s3 = new S3Client({ endpoint: process.env.S3_ENDPOINT, region: process.env.S3_REGION, forcePathStyle: true,
  credentials: { accessKeyId: process.env.S3_ACCESS_KEY, secretAccessKey: process.env.S3_SECRET_KEY } });
await s3.send(new PutObjectCommand({ Bucket: process.env.S3_BUCKET, Key: "produtos/foto.png", Body: buffer, ContentType: "image/png" }));
const url = await getSignedUrl(s3, new GetObjectCommand({ Bucket: process.env.S3_BUCKET, Key: "produtos/foto.png" }), { expiresIn: 3600 });
// save only the key ("produtos/foto.png") in the database; generate the URL when rendering
```
Python (boto3):
```python
import boto3, os
s3 = boto3.client("s3", endpoint_url=os.environ["S3_ENDPOINT"], region_name=os.environ["S3_REGION"],
    aws_access_key_id=os.environ["S3_ACCESS_KEY"], aws_secret_access_key=os.environ["S3_SECRET_KEY"],
    config=boto3.session.Config(s3={"addressing_style": "path"}))
s3.upload_file("foto.png", os.environ["S3_BUCKET"], "produtos/foto.png")
url = s3.generate_presigned_url("get_object", Params={"Bucket": os.environ["S3_BUCKET"], "Key": "produtos/foto.png"}, ExpiresIn=3600)
```

## 4d. Common errors and what to do
- 401/403 "This API key lacks the required role" → the token was created as a developer key; ask the customer to generate it with the "Gerar token de IA" button.
- 403 FORBIDDEN on POST /v1/api-keys → an API key (including the AI token) cannot create another API key. Only a logged-in person creates keys, in the dashboard. Each key works only inside the one organization that created it.
- HTTP 402 PLAN_LIMIT_EXCEEDED → the error carries error.details {plan, resource, limit, used}. Read details.resource and tell the customer exactly what hit the limit:
  · "subscription" → the free trial ended or the invoice is unpaid (details also has status). While unpaid you cannot create, deploy or start anything; S3 uploads are blocked but downloads still work. Lifecycle: when the free trial ends, apps and databases pause right away; when a monthly invoice is overdue, apps and databases pause after 4 days, and 9 days after the due date projects and databases are permanently deleted. The dashboard shows an orange/red banner. Ask the customer to pay in Billing (Pix in Brazil, card elsewhere) before day 9 and then press "Iniciar" (Start) on each project to bring everything back.
  · "project(s)" / "database(s)" → the plan count was reached; suggest upgrading (Pro/Enterprise) or reusing an existing project/database.
  · "replica(s) per project" → either the count is above the plan ceiling (Hobby 2, Pro 3, Enterprise 5 running copies), or the account is on the free trial or has an unpaid invoice — extra copies need a paid plan in good standing. Send the customer to Billing → "Cópias extras" (Extra copies) in the dashboard: it shows the hourly prices, this month’s usage and the invoices to pay.
  · "vCPU per …", "MB of RAM per …", "MB of disk per …" (database or project), "MB of disk per volume", "MB of volume storage" → the requested size is above the plan; lower it or upgrade.
  · "backups" → automatic backups are not in the plan (Hobby); "autoscaling" → autoscaling needs a paid plan in good standing (not available during the trial).
- 409 on POST /v1/projects → name or address already taken; pick another name.
- Deployment FAILED → read GET /v1/deployments/<id>/diagnostico, fix the code (missing dependency, wrong start script, app not listening on PORT) and deploy again.
- S3 QuotaExceeded → the account storage is full; delete files or buy a storage pack in the dashboard.

## 5. After it is live
- New version: upload a new ZIP (step E) and deploy again (step F). Failed deploys never replace the running version.
- Custom domain: POST /v1/projects/<id>/domains {"hostname": "www.example.com"} → tell the customer to create TXT _devora-verify.<hostname> = devora-verify=<verificationToken> and a CNAME to the project address returned in GET /v1/projects/<id> → data.dns.cnameTarget (do not build it from the slug); then POST /v1/projects/<id>/domains/<domainId>/verify. List the domains with GET /v1/projects/<id>/domains. HTTPS certificate is automatic. Devora does not sell domains.
- Region preference: GET /v1/regions (public) and GET/PUT /v1/projects/<id>/location-preferences {"primaryRegion": "usa", "replicas": [], "purpose": "FAILOVER"}. Regions that run applications: "usa" (United States) and "germany" (Germany); "brazil-mg" is the Brazil site-accelerator CDN (cache only, no apps). Saving a preference does not move a running project.
- Number of running copies: POST /v1/projects/<id>/scale {"replicas": 2}. The maximum is the plan ceiling (Hobby 2, Pro 3, Enterprise 5 running copies; the failover standby is separate and stays off). Every copy above the primary is billed by the hour; during the trial or with an unpaid invoice the API answers 402 PLAN_LIMIT_EXCEEDED. On a stopped or never-deployed project the number applies on the next start/deploy (the response has appliesNow and a note).
- Runtime logs: GET /v1/projects/<id>/runtime-logs?desde=15m   Restart: POST /v1/projects/<id>/restart
- Connect Git later (optional): the customer connects GitHub once in the dashboard (Connections); then GET /v1/git/repositories and PATCH /v1/projects/<id> {"repositoryId": "...", "defaultBranch": "main"} to deploy on every push.

## 5b. "My site is slow / crashing / out of space" — diagnose before advising
When the customer complains, look at the data first (never guess):
1. GET /v1/projects/<id>/metrics?minutes=1440 → nodeSeries [{ts, cpuPct, ramPct, ramUsedMb}] (percent of the plan limit) and replicas [{restartCount, cpuLimit, ramLimitMb, status}].
2. GET /v1/projects/<id>/runtime-logs?desde=60m → look for "Killed", "out of memory", "JavaScript heap out of memory", timeouts, 5xx errors and slow queries.
3. GET /v1/projects/<id>/storage → data.usage for S3 space.
4. GET /v1/projects/<id>/traffic?hours=24 → total requests, errors (4xx/5xx), errorRate and an hourly series. Use it to tell the customer how many visits the site had and whether errors are growing; a high errorRate right after a deploy points to the new version.
How to read it and what to tell the customer:
- CPU often above 80% for long periods → the app needs more processor: turn on autoscaling or load balancing (extra copies of the plan’s size, billed by the hour — on Hobby up to 2 copies of 0.5 vCPU) or recommend a bigger plan (Pro 2 vCPU, Enterprise 4 vCPU) when a single copy is too small.
- RAM above 90%, restartCount growing, or "Killed"/"out of memory" in the logs → the app is running out of memory: recommend the next plan (Hobby 512 MB → Pro 1 GB → Enterprise 8 GB) and point out memory leaks or heavy work done per request.
- CPU and RAM low but the site is slow → the problem is in the code or the database (slow queries, missing indexes, calls to slow external APIs): show the evidence from the logs and suggest the fix; more hardware will not help.
- S3 usage above 80% or uploads failing with QuotaExceeded → "You need more storage": buy a pack (100 GB US$ 3, 250 GB US$ 4, 1 TB US$ 12) or move to a plan with more included space.
- Before uploading a large project or many files, compare the size with data.usage.limitBytes and warn the customer first.
Always show the numbers you saw (e.g. "CPU averaged 94% in the last 24 h, the app restarted 7 times") and give one clear recommendation. You cannot change the plan or buy space for the customer — they do it in the dashboard (Billing / Storage).

## 6. Plans (USD, monthly, 1 project each)
- Hobby — US$ 5: 0.5 vCPU, 512 MB RAM, 3 GB disk, 1 database, 1 GB S3, no backups, failover included; autoscaling and load balancing billed hourly, up to 2 running copies (extra copy US$ 0.0069/h, autoscaling from the 2nd extra copy US$ 0.0063/h).
- Pro — US$ 20: 2 vCPU, 1 GB RAM, 10 GB disk, 2 databases, 5 GB S3, backups kept 7 days, failover included; autoscaling and load balancing billed hourly, up to 3 running copies (extra copy US$ 0.0278/h, autoscaling from the 2nd extra copy US$ 0.0250/h).
- Enterprise — US$ 59: 4 vCPU, 8 GB RAM, 100 GB disk, 4 databases, 25 GB S3, backups kept 30 days, failover included; autoscaling and load balancing billed hourly, up to 5 running copies (extra copy US$ 0.0819/h, autoscaling from the 2nd extra copy US$ 0.0738/h).
- Backups are automatic for PostgreSQL databases only, and only on Pro/Enterprise.
- Three modes, always presented in this order: Scalability (autoscaling), Load balancing or Failover.
- Scalability (autoscaling) — every plan, optional, the customer turns it on: when CPU passes the limit a clone starts automatically and is billed per hour while it runs.
- Load balancing — every plan, optional: extra copies always on (24 h) splitting the traffic, billed per hour while on. They share the same database and S3.
- Failover — INCLUDED in every plan: a standby copy kept OFF in another country (uses no CPU) with the image already downloaded; if the primary fails, a watcher starts it in the other region (USA ↔ Germany) and the project comes back on its own within seconds.
- Price of extra running copies (autoscaling or load balancing), each with the plan’s size: plan price ÷ 30 days ÷ 24 h. Load balancing: every always-on copy pays the full hourly price (no discount). Autoscaling: the 1st extra copy pays full price, 10% off from the next one on. Hobby US$ 0.0069/h (≈ US$ 5/month if always on), autoscaling 2nd+ US$ 0.0063/h; Pro US$ 0.0278/h (≈ US$ 20/month), autoscaling 2nd+ US$ 0.0250/h; Enterprise US$ 0.0819/h (≈ US$ 59/month), autoscaling 2nd+ US$ 0.0738/h.
- Rules: extra copies need a paid plan in good standing (during the trial the app runs 1 copy). The usage invoice is issued on the 1st of each month and is paid by Pix (Brazil, PAGUEO) or card (Stripe); an unpaid usage invoice pauses after 4 days and deletes after 9, like any invoice. The dashboard screen Billing → "Cópias extras" shows hourly prices, this month’s usage and invoices to pay.
- Extra S3 packs: 100 GB US$ 3 · 250 GB US$ 4 · 1 TB US$ 12. Brazil pays by Pix (BRL at the day rate + 1.99%); other countries by card.
- Plan purchase is done by the customer in the dashboard (Billing); you cannot pay for them.
- Hardware: apps, databases and builds run on servers with AMD EPYC data-center processors (USA and Germany). Replicas and the failover replica sit on different EPYC servers. The Brazil node is only a CDN cache (it does not run apps). If the customer asks for the exact CPU generation, say it is not published.

## 7. Not available yet (do not promise; say it is coming)
- Turning on the Brazil CDN acceleration through the API.
- Buying plans through the API (the customer pays in the dashboard).
- Running applications in Brazil (the Brazil node is CDN cache only).
- Deploying a prebuilt Docker image or an arbitrary Git URL (use ZIP upload or connected GitHub).

## 8. Rules
- Never print the full token back to the customer or put it in code, commits or logs.
- Never put secrets in NEXT_PUBLIC_* variables.
- Store uploads in S3 or the database, never on the container disk (it is not shared between replicas).
- If something fails twice, show the customer the diagnosis (GET /v1/deployments/<id>/diagnostico) and suggest support at https://devoracloud.com/support.

---

# Devora Cloud — Devora-Handbuch

Was ist Devora Cloud?
Devora Cloud ist eine brasilianische Cloud-Hosting-Plattform der Klaup-Gruppe, mit der Sie von einfachen Websites bis zu kompletten Anwendungen alles veröffentlichen können. Sie vereint Projekt-Deployments, verwaltete Datenbanken, S3-Speicher, ein Terminal sowie das Monitoring von CPU, Arbeitsspeicher und Traffic in einem Dashboard.
Die Plattform bietet eine KI-gestützte Analyse fehlgeschlagener Builds sowie Dokumentation, die bei der Diagnose und der Integration der Services hilft. Vorschläge sollten vor einer Codeänderung geprüft werden.
Die Länderexpansion umfasst die Wahl der primären Region, Replikas und Autoscaling – abhängig von Tarif, Kompatibilität der Anwendung und verfügbarer Infrastruktur. Der Betrieb erfolgt derzeit in den USA; weitere Standorte sind auf der Karte als geplant markiert. Das Speichern einer Regionspräferenz führt keine Migration durch.
https://devoracloud.com/about?lang=de

Wie Sie auf Devora Cloud bereitstellen, Dienste verbinden und Probleme beheben.
https://devoracloud.com/docs?lang=de

## Wie Devora Cloud aufgebaut ist
https://devoracloud.com/docs/estrutura?lang=de

Eine Organisation ist Ihr Konto. Projekte bündeln Anwendungen, Dienste, Domains, Umgebungsvariablen, Speicher und verknüpfte Datenbanken. Ein Repository mit Frontend und API kann zwei Dienste im selben Projekt verwenden.
Devora koordiniert die Bereitstellung und die Ressourcenkonfiguration. Die Datenbankinfrastruktur wird getrennt von der Anwendungsausführung verwaltet. Kunden müssen keinen Datenbankserver installieren oder administrieren. Jede verknüpfte Datenbank hat eigene Verbindungsdaten.

## Hilfe vor dem Eröffnen eines Tickets
https://devoracloud.com/docs/suporte?lang=de

Beschreiben Sie das Problem unter Support. Passende Hinweise werden vor dem Absenden eines Tickets angezeigt; durch das Lesen der Vorschläge wird kein Ticket erstellt. Wenn sie nicht helfen, senden Sie das Ticket mit Projekt, Bereitstellung, Uhrzeit, Fehlermeldung und bereits durchgeführten Prüfungen.
Öffnen Sie bei Build-Fehlern den Bereich Probleme und nutzen Sie die verfügbare KI-Analyse. Sie erklärt mögliche Ursachen, repariert den Code jedoch nicht automatisch. Verwenden Sie „Fehler für KI kopieren“, sofern verfügbar, und teilen Sie den bereinigten Kontext mit Ihrer Entwicklungs-KI oder dem Support. Geben Sie niemals Passwörter, Tokens oder Verbindungs-URLs mit Zugangsdaten weiter.

## Aus GitHub bereitstellen
https://devoracloud.com/docs/publicar?lang=de

Verbinden Sie GitHub, wählen Sie Repository und Branch und prüfen Sie vor der Bereitstellung den erkannten Builder und Port. Verfügbare Builder sind automatisches Nixpacks, Dockerfile und statische Website. Die Erkennung ist ein Vorschlag, der unter Umständen korrigiert werden muss.
Die Plattform erstellt das Anwendungs-Image, stellt es bereit und verbindet eine generierte Projekt-Subdomain mit HTTPS. Eine statische Website benötigt keine Datenbank. Prüfen Sie, ob bereits eine Datenbank verknüpft ist, bevor Sie eine weitere anfordern, und vergewissern Sie sich, dass Ihr Tarif dies erlaubt.

## Mit Ihrer KI veröffentlichen und verwalten
https://devoracloud.com/docs/ia?lang=de

Jede KI, die eine Webseite lesen und eine API aufrufen kann — ChatGPT, Claude, Gemini, Cursor, GitHub Copilot, Windsurf und andere —, kann für Sie das Projekt, die Datenbank und den Speicher anlegen, Ihren Code hochladen und veröffentlichen. Ohne Git und ohne Docker: Sie chatten, die KI erledigt die Arbeit.
Der Zugriff erfolgt über ein KI-Token, das Sie im Dashboard erzeugen. Damit liest die KI das für sie geschriebene Handbuch unter https://devoracloud.com/llms.txt und nutzt die Devora-API im Namen Ihres Kontos.
1. Konto erstellen: Die kostenlose Testphase dauert 7 Tage im Hobby-Tarif und erfordert keine Karte.
2. KI-Token erzeugen: Öffnen Sie in der Seitenleiste des Dashboards „KI-Token & API“ und klicken Sie auf „KI-Token erzeugen“.
3. Fertigen Text in Ihre KI einfügen: Kopieren Sie den angezeigten Text — er enthält bereits das Token und den Link zum KI-Handbuch (https://devoracloud.com/llms.txt) — und fügen Sie ihn in den Chat mit Ihrer KI ein.
4. Fragen der KI beantworten: Vor der Veröffentlichung fragt die KI nach dem Projektnamen, ob Sie eine Datenbank brauchen, ob Dateien gespeichert werden müssen (S3-Speicher) und nach der Region.
5. Live-Adresse erhalten: Die KI verfolgt den Build und schickt Ihnen nach Abschluss die veröffentlichte Adresse: https://<name>.apps.devoracloud.com.
Was die KI mit dem Token tun kann: Projekte auflisten und anlegen; eine PostgreSQL-, MySQL-, MariaDB-, MongoDB- oder Redis-Datenbank erstellen (DATABASE_URL bzw. REDIS_URL bei Redis wird in die App eingefügt); privaten S3-Speicher aktivieren (S3_*-Variablen); ein ZIP des Codes hochladen und bereitstellen; Build-Logs und die Fehlerdiagnose lesen; Laufzeit-Logs, CPU- und Speichermetriken, Neustarts und die S3-Nutzung auswerten, um Ihnen zu sagen, ob Sie mehr Prozessor, Arbeitsspeicher oder Platz brauchen; eigene Domains hinzufügen; und Umgebungsvariablen setzen.
Was die KI nicht tun kann: Ihren Tarif bezahlen oder ändern oder Speicherpakete kaufen — das erledigen Sie selbst unter Abrechnung oder Speicher. Sie kann auch keine API-Schlüssel erstellen: Das können nur Sie, angemeldet im Dashboard. Apps laufen in den USA und in Deutschland; Brasilien ist nur Devoras eigener CDN-Cache, kein Ort, an dem Apps laufen.
Beispieltext zum Einfügen in Ihre KI: „Mein Hosting ist Devora Cloud. Lies das KI-Handbuch unter https://devoracloud.com/llms.txt und verwende dieses Token: dc_live_… Veröffentliche mein Projekt und frag mich vorher nach Datenbank, S3-Speicher und Region.“
Wenn etwas schiefgeht:
- Testphase beendet oder Rechnung offen: Anwendungen und Datenbanken sind pausiert; bezahlen Sie den Tarif und verwenden Sie Starten. Eine 9 Tage überfällige Rechnung führt zur endgültigen Löschung.
- Tariflimit erreicht: Die KI sagt Ihnen, welche Ressource über dem Limit liegt; reduzieren Sie die Nutzung oder wählen Sie einen größeren Tarif.
- Bereitstellung fehlgeschlagen: Die KI liest die Build-Diagnose, korrigiert den Code und stellt erneut bereit.
- Speicher voll: Kaufen Sie ein Speicherpaket oder wählen Sie einen größeren Tarif.
Sicherheit des Tokens: Das Token wird nur einmal angezeigt und gewährt vollen Zugriff auf diese Organisation — und nur auf diese. Es kann keine weiteren Schlüssel erstellen. Veröffentlichen Sie es nie und teilen Sie es nicht an öffentlichen Orten. Sie können es jederzeit auf demselben Bildschirm widerrufen, auf dem Sie es erzeugt haben. Für CI und Skripte gibt es eine separate Option: Entwicklerschlüssel mit eingeschränktem Zugriff.

## Mehrere Dienste in einem Projekt
https://devoracloud.com/docs/servicos?lang=de

Verwenden Sie Dienste für Programme, die zusammengehören, etwa Frontend, API und Worker. Jeder Dienst hat einen eigenen Dockerfile-Pfad, einen eigenen Port und einen optionalen Startbefehl. Ein Worker kann ein Image mit einem anderen Befehl wiederverwenden.
Projektvariablen werden mit den zugehörigen Diensten geteilt; dienstspezifische Variablen können separat konfiguriert werden. Bereitstellungen gehören zu dem Dienst, der veröffentlicht wird. Duplizieren Sie kein Projekt nur, um einen weiteren Prozess aus demselben Repository auszuführen.

## Verwaltete Datenbanken und Verbindungsdaten
https://devoracloud.com/docs/banco?lang=de

Verwenden Sie die bereits mit dem Projekt verknüpfte Datenbank; installieren Sie PostgreSQL oder MySQL nicht im Anwendungscontainer. Die verwaltete Dateninfrastruktur ist von den Anwendungsreplikaten getrennt. Fügen Sie eine Datenbank nur hinzu, wenn das Projekt eine benötigt und noch keine hat. Verfügbare Engines: PostgreSQL, MySQL, MariaDB, MongoDB und Redis. Automatische Backups gibt es nur für PostgreSQL und nur in Tarifen mit Backup (Pro 7 Tage, Enterprise 30 Tage; Hobby hat keine).
Wenn eine Datenbank aus dem Projekt heraus verknüpft wird, wird ihre verschlüsselte Verbindungsvariable automatisch hinzugefügt und die Anwendung neu bereitgestellt, um sie zu erhalten. Verwenden Sie die bereitgestellte Variable und den privaten Host. Das Anlegen von Tabellen und Schema-Migrationen bleiben Teil des Bereitstellungsprozesses Ihrer Anwendung.
Hochverfügbarkeit der Datenbank erfordert Datenbankreplikation und Failover im konfigurierten Datendienst. Anwendungsreplikate erzeugen keine Datenbankreplikate. Stellen Sie die Verbindung nach einem Failover erneut her; Replikation ersetzt keine Backups und macht versehentliches Löschen nicht rückgängig. Prüfen Sie die Bedingungen des Dienstes.
Der öffentliche Zugriff ist optional und sollte nur aktiviert werden, wenn er für einen externen SQL-Client benötigt wird. Exportieren Sie vor dem Löschen einer Datenbank alle Daten, die Sie behalten möchten. Löschen Sie eine Datenbank nicht, um ein Verbindungsproblem zu beheben.

## Bilder und Dateien gehören in S3
https://devoracloud.com/docs/armazenamento?lang=de

Bei Devora Cloud sind Anwendungsausführung, Datenbank und Dateispeicher getrennte Ressourcen, die mit Ihrem Projekt verbunden sind.
Beispiel: Das Produktfoto liegt in S3. Die Datenbank speichert Name, Preis und den Verweis auf dieses Foto.
Speichern Sie Dateiinhalte im Objektspeicher. In der Datenbank liegen nur Metadaten und der Objektschlüssel bzw. die URL. Weisen Sie Ihre Entwicklungs-KI an, diesem Muster zu folgen – ohne Binärspalten für Fotos, Videos oder Anhänge.
Das Hinzufügen von S3 stellt die Verbindungsdaten bereit. Ihre Anwendung muss diese Variablen und ein S3-kompatibles SDK nutzen, um Dateien hoch- und herunterzuladen. Der Klick migriert keine alten Dateien, ändert keinen Code und sichert die Datenbank nicht.
Eine Anwendung, die bereits R2, IDrive e2 oder einen anderen S3-Dienst nutzt, kann dabei bleiben. Ein Anbieterwechsel erfordert das Kopieren der Objekte, die Prüfung der Berechtigungen und das Aktualisieren der Verweise, bevor der alte Dienst abgeschaltet wird.
Speichern Sie dauerhafte Uploads nicht auf der flüchtigen Festplatte des Containers. Nutzen Sie für private Dateien Authentifizierung und zeitlich begrenzte signierte Links; machen Sie nicht den gesamten Bucket öffentlich, um ein Zugriffsproblem zu lösen.
Neue Verbindungen über das Panel erfordern projektbeschränkte Zugangsdaten. Administrative Speicherschlüssel dürfen nicht an Kundenanwendungen weitergegeben werden.
Ressource hinzufügen öffnet ein Formular mit Name und Projekt. Mehrere Datenbanken und S3-Verknüpfungen erscheinen als eigene Zeilen in der Liste. Zusätzliche S3-Verknüpfungen nutzen eigene Präfixe und Variablen S3_<Bezeichner>_*. Zusätzliche Datenbanken erhalten eine eigene Verbindungsvariable, die in den Details angezeigt wird; bestehende Verbindungen bleiben erhalten. Verknüpfungen des Inhabers teilen die Zugangsdaten der Integration; Präfixe isolieren diese Zugangsdaten nicht.
Öffnen Sie im Kontomenü Datenbanken oder Speicher · S3. Durchsuchen Sie die Liste und klicken Sie auf eine Zeile, um die Details direkt darunter in derselben Tabelle aufzuklappen.
Datenbank: Verbindung zeigt den privaten Host und Port. Zugangsdaten anzeigen ruft die vollständige URI mit Passwort ab, nur für berechtigte Benutzer. Veröffentlichen Sie sie nie in Git, auf öffentlichen Seiten oder in Unterhaltungen ohne Zugriffskontrolle.
Externer Zugriff: Prüfen Sie den aktuellen Status, beantragen Sie den Zugriff über das Internet und bestätigen Sie die Freigabe. Der Worker muss die Netzwerkregeln anwenden und eine Adresse veröffentlichen. Eine angenommene Anfrage bedeutet nicht, dass die Verbindung bereit ist: Prüfen Sie Aktivität und testen Sie. Private IP-Adressen funktionieren nicht über das Internet. Deaktivieren Sie den externen Zugriff, wenn er nicht mehr benötigt wird.
S3: Der Administrator des Inhaberkontos kann beim Hinzufügen von Speicher ein Projekt wählen. Die Verknüpfung liefert ein stabiles Präfix pro Organisation/Projekt sowie S3_ENDPOINT, S3_REGION, S3_BUCKET, S3_PREFIX, S3_FORCE_PATH_STYLE, S3_ACCESS_KEY und S3_SECRET_KEY. Ihr SDK muss S3_PREFIX jedem Objektschlüssel voranstellen.
Die Inhaber-Integration nutzt die Zugangsdaten des Inhabers. Präfixe ordnen Objekte, schränken diese Zugangsdaten aber nicht ein. Der Verkauf an Kunden erfordert beim Anbieter eingeschränkte Zugangsdaten und durchgesetzte Kontingente; die automatische Buchung bleibt bis dahin nicht verfügbar. Beim Trennen des Speichers bleiben die Objekte erhalten.
Für Ihre Entwicklungs-KI: Konfigurieren Sie den S3-Client auf dem Server, laden Sie Dateien in Bucket/Präfix hoch, speichern Sie Schlüssel und Metadaten in der Datenbank und erzeugen Sie signierte URLs für private Lesezugriffe. Legen Sie geheime Schlüssel nie in NEXT_PUBLIC_*, Browser-JavaScript oder Git ab.
Verschlüsselung im Ruhezustand und HTTPS-Verbindungen für verwalteten Speicher. Der aktuelle Bucket verwendet standardmäßig SSE-KMS. Der Zugriff hängt von Zugangsdaten und Berechtigungen ab; private Dateien sollten zeitlich begrenzte signierte Links verwenden.
1 TB = 1.000 GB. Abrechnung getrennt von der Anwendung, in US-Dollar (USD).
Die Buchung wird vorbereitet. Keine automatische Abrechnung oder Aktivierung verfügbar.

## Persistente Dateien und Volumes
https://devoracloud.com/docs/volumes?lang=de

Dateien im Container sind flüchtig. Verwenden Sie Objektspeicher für Uploads und Medien; verwenden Sie ein Volume, wenn das Programm ausdrücklich einen persistenten Dateisystempfad benötigt.
Ein Volume-Mount wird bei der nächsten Bereitstellung wirksam. Prüfen Sie, ob die Engine den Mount bestätigt hat. Ein lokales Volume kann nicht als gemeinsames Dateisystem für Anwendungsreplikate auf verschiedenen Maschinen genutzt werden.

## Eigene Domain und Projekt-Subdomain
https://devoracloud.com/docs/dominio?lang=de

Öffnen Sie im Projekt den Bereich Domains und fügen Sie Ihre Domain ohne Protokoll und Pfad hinzu. Weisen Sie die Inhaberschaft mit dem im Panel angezeigten TXT-Eintrag nach. Richten Sie den CNAME auf die dort angezeigte, spezifische Projekt-Subdomain aus, nicht auf die allgemeine Zone der Plattform.
Beispiel: Für www.beispiel.de legen Sie einen CNAME mit dem Namen www an, dessen Ziel die Projekt-Subdomain ist, ohne https://. Für die Stammdomain folgen Sie den unterstützten Anweisungen Ihres DNS-Anbieters und des Panels für ALIAS, ANAME oder CNAME-Flattening. Raten Sie keine IP-Adresse.
Warten Sie die DNS-Propagation ab, bevor Sie HTTPS prüfen. Das Zertifikat wird automatisch ausgestellt und erneuert, sobald das Routing korrekt ist. Der CNAME der Website ändert nichts an der E-Mail. Wenn Sie die Geschäfts-E-Mail von Devora auf dieser Domain nutzen, tragen Sie auch die E-Mail-Einträge (MX, SPF, DMARC und DKIM) aus dem Bereich E-Mail ein; liegen Ihre E-Mails bei einem anderen Dienst, etwa Google Workspace oder Microsoft 365, ändern Sie den MX nicht.

## Geschäftliche E-Mail, DNS und E-Mail-Programme
https://devoracloud.com/docs/email?lang=de

1. Blockierten Versand beheben (Relay access denied): Wenn der Empfang funktioniert, beim Senden aber Relay access denied erscheint, öffnen Sie die Einstellungen des SMTP-Postausgangsservers. Verwenden Sie Port 587, STARTTLS, „Passwort, normal“ und Ihre vollständige E-Mail-Adresse als Benutzername. Port 25 dient der Zustellung zwischen Servern und ist nicht für Mail-Apps gedacht. Stellen Sie sicher, dass das Konto tatsächlich diesen Postausgangsserver verwendet. Nutzen Sie das Postfach-Passwort, das sich vom Dashboard-Passwort unterscheiden kann. Teilen Sie niemals Passwörter in einem Ticket. Die automatische Einrichtung in Mail-Apps nutzt die CNAME-Einträge autoconfig/autodiscover und die SRV-Einträge der Domain (siehe DNS-Einträge konfigurieren). Sie funktionieren auch, wenn die Website außerhalb von Devora gehostet wird. Bestehende Konten müssen SMTP eventuell einmalig korrigieren.
2. Über das Konto- oder Projektmenü öffnen: Öffnen Sie Business-E-Mail im Kontomenü oder innerhalb eines Projekts. Das Projekt organisiert die Verknüpfung und schlägt bereits verbundene Domains vor. Verwenden Sie eine eigene Domain; die kostenlose Subdomain der Anwendung ist nicht Ihre geschäftliche E-Mail-Domain.
3. Buchung und Zahlung prüfen: E-Mail ist getrennt vom Hosting und wird in BRL pro Postfach für Zeiträume von 30 Tagen abgerechnet, ohne kostenlose Testphase. Wählen Sie die Anzahl und prüfen Sie Preis und Speicherplatz. Erzeugen und bezahlen Sie den Pix: Nur die beim Anbieter bestätigte Zahlung aktiviert die Postfächer. Eine ausstehende Zahlung oder ein Klick gewährt keinen Zugang. Der tatsächliche Eigentümer-Administrator verfügt über eine serverseitig geprüfte Kulanzaktion, die keine Rechnung erzeugt.
4. Erweiterungen und Verlängerungen verstehen: Wird die Anzahl während eines bezahlten Zeitraums erhöht, wird die verbleibende Zeit anteilig gutgeschrieben und nach der Zahlung beginnt ein neuer 30-Tage-Zeitraum. Eine Verlängerung mit gleicher Anzahl fügt dem aktuellen Ablaufdatum 30 Tage hinzu. Eine Reduzierung ist erst nach Ende des aktiven Zeitraums möglich; löschen Sie keine Konten, um die Lizenzierung zu umgehen.
5. Domain hinzufügen und verifizieren: Fügen Sie die Domain hinzu und wählen Sie bei Bedarf ein Projekt. Veröffentlichen Sie zuerst nur den TXT-Eintrag zum Eigentumsnachweis unter _devora-mail.ihredomain und klicken Sie auf „Domain verifizieren“. Bei aktivem Service und gültigem Nachweis richtet das Panel die Domain auf dem Server ein und zeigt DKIM an. Eine bereits auf dem Mailserver vorhandene Domain erfordert eine ausdrückliche Übernahme durch den Eigentümer-Administrator; bestehende Postfächer werden nie automatisch importiert oder überschrieben.
6. DNS-Einträge konfigurieren: Klicken Sie auf die Domain in der Liste, um DNS und Konfiguration zu öffnen, und legen Sie genau diese Einträge an: TXT _devora-mail.ihredomain = Verifizierungstoken; MX ihredomain 10 mail.bytsend.com (Empfang); TXT ihredomain "v=spf1 mx ~all" (SPF, autorisiert den Versand); TXT _dmarc.ihredomain "v=DMARC1; p=none" (DMARC); und den DKIM-TXT-Eintrag, der nach der Verifizierung erscheint (signiert Nachrichten). Für die automatische Einrichtung in Outlook, Thunderbird und auf dem Smartphone: CNAME autoconfig.ihredomain und autodiscover.ihredomain → discover.devoracloud.com; SRV _autodiscover._tcp 0 0 443 discover.devoracloud.com; SRV _imaps._tcp 0 1 993 mail.bytsend.com; SRV _submission._tcp 0 1 587 mail.bytsend.com. Diese Einträge funktionieren auch, wenn die Website außerhalb von Devora gehostet wird. Behalten Sie einen einzigen SPF-Eintrag und kombinieren Sie darin die autorisierten Dienste. Der CNAME der Website konfiguriert keine E-Mail. Planen Sie die Migration, bevor Sie einen bestehenden MX ändern.
7. E-Mail-Konto erstellen: Nach der Verifizierung der Domain klicken Sie auf „Konto hinzufügen“, wählen die Domain, geben den Namen vor dem @ und ein Passwort mit mindestens 12 Zeichen ein. Die Anzahl der Postfächer darf die gebuchte Menge nicht überschreiten. Passwörter werden von der API nicht zurückgegeben und in Cloud nicht im Klartext gespeichert; zum Ändern nutzen Sie „Passwort ändern“ in der Liste. Schlägt die Erstellung fehl, versuchen Sie es mit derselben Adresse und demselben Passwort erneut; bestehende Konten können nicht überschrieben werden.
8. Webmail, Outlook oder Smartphone nutzen: Nutzen Sie „Webmail öffnen“ oder richten Sie Outlook, Thunderbird oder Ihr Smartphone ein: vollständige E-Mail-Adresse als Benutzername, Postfach-Passwort, Posteingang IMAP mail.bytsend.com Port 993 mit SSL und Postausgang SMTP mail.bytsend.com Port 587 mit STARTTLS und Authentifizierung. Die automatische Einrichtung hängt von App und Version ab; die manuelle Konfiguration bleibt verfügbar. Das Postfach-Passwort ist unabhängig vom Cloud-Passwort.
9. Speicherplatz und Laufzeit prüfen: Das Kontingent gilt pro Postfach und wird vor der Zahlung angezeigt. Der Administrator kann Preis und Kontingent für neue Buchungen und Verlängerungen ändern. Bei Ablauf wird der Zugriff auf verwaltete Konten gesperrt, die Nachrichten bleiben erhalten; eine Verlängerung reaktiviert den Service. Alte Postfächer außerhalb der Integration werden dadurch nicht verändert.
10. Importierte Postfächer verwalten: Importierte Postfächer: Verknüpft ein Administrator ein bestehendes Postfach, erscheint es unter E-Mail-Konten. Nachrichten und aktuelles Passwort bleiben auf dem Server; der Import migriert oder erstellt das Postfach nicht neu. Die Projektverknüpfung dient der Organisation und ändert die E-Mail-Adresse nicht. Die Kulanz des Eigentümer-Administrators verursacht keine Kosten.
11. Passwort sicher ändern: Passwort ändern: Öffnen Sie Business-E-Mail, suchen Sie die Adresse unter E-Mail-Konten und klicken Sie auf „Passwort ändern“. Geben Sie ein neues Passwort mit 12 bis 128 Zeichen ein und klicken Sie auf „Passwort speichern“. Das alte Passwort kann nicht angezeigt werden. Aktualisieren Sie nach erfolgreichem Speichern das Passwort in Outlook, auf dem Smartphone und in anderen Apps; neue Webmail-Anmeldungen verwenden ebenfalls das neue Passwort. Die Änderung erhält die Nachrichten und ändert nicht Ihr Cloud-Anmeldepasswort.
12. Probleme lösen und Hilfe erhalten: Für Ihre KI oder den Support: Nennen Sie Domain, betroffene Adresse, Art des Fehlers (Anmeldung/Senden/Empfang), Uhrzeit, Fehlermeldung, Servicestatus und ob Webmail funktioniert. Geben Sie niemals Passwörter oder private Nachrichteninhalte weiter. Testen Sie Senden und Empfangen mit einer externen Adresse, nachdem DNS eingerichtet ist.
13. Routing nach einer Migration aktualisieren: Routing und Migration: Verwenden Sie den Servernamen, die öffentliche IP und das Webmail, die aktuell im Panel angezeigt werden – keine alte IP aus Screenshots oder Nachrichten. MX zeigt auf einen DNS-Hostnamen, nicht auf eine IP. Administratoren aktualisieren diese Adressen unter Admin → Business-E-Mail. Das aktualisiert die Anleitungen im Panel, migriert aber keine Postfächer und ändert keine DNS-Einträge. Bleibt der Hostname gleich, behält der Kunde den MX und der Administrator aktualisiert A/AAAA des Servers. Ändert sich der Hostname, aktualisieren Sie auch MX und Mail-Apps. Private Verbindung und Schlüssel werden unter Admin → Integrationen konfiguriert. Aktualisieren Sie und öffnen Sie die Domain erneut, um die aktuellen Anleitungen zu sehen.

## Projektkarte, Variablen, Metriken und Terminal
https://devoracloud.com/docs/painel-projeto?lang=de

Die Projektkarte zeigt die tatsächlichen Verbindungen zwischen Diensten. Der Inspektor zeigt CPU, Arbeitsspeicher und die Netzwerkraten RX/TX an. RX ist eingehender, TX ausgehender Datenverkehr, gemessen als Rate und nicht als monatliches GB-Kontingent. Fehlende Daten bedeuten keinen Verbrauch von null.
Terminal und Logs öffnen ihre Werkzeuge über die Seitenleiste. Wählen Sie den Dienst aus und verbinden Sie das Terminal ausdrücklich. Variablen wirken sich beim Start eines Prozesses aus; Konfigurationsänderungen können eine Bereitstellung erfordern. Halten Sie Geheimnisse aus Logs und Support-Tickets heraus.

## Tarife, Kapazität und Zahlung
https://devoracloud.com/docs/planos?lang=de

Neue Konten erhalten ab der Registrierung eine 7-tägige kostenlose Testphase im Hobby-Tarif, ohne Karte: 1 Projekt mit 0,5 vCPU, 512 MB, 3 GB Festplatte, 1 Datenbank und 1 GB S3, ohne Backups und ohne geschäftliche E-Mail. Endet die Testphase, werden Anwendungen und Datenbanken sofort pausiert. Bezahlen Sie einen Tarif und verwenden Sie dann Starten, um fortzufahren. Geschäftliche E-Mail hat keine kostenlose Testphase.
Unbezahlte Rechnung: 4 Tage nach Fälligkeit werden Anwendungen und Datenbanken pausiert; 9 Tage nach Fälligkeit werden Projekte und Datenbanken endgültig gelöscht. Solange nicht bezahlt ist, können Sie nichts erstellen, bereitstellen oder starten; Uploads in S3 sind gesperrt, Downloads bleiben möglich. Das Dashboard zeigt ein orangefarbenes oder rotes Banner mit der Frist. Bezahlen Sie vor Tag 9 und verwenden Sie Starten, um alles zurückzuholen. In der API sind diese Ablehnungen HTTP 402 mit details.resource „subscription“.
Aktuelle Preise, Währung und Limits finden Sie unter Preise sowie unter Tarif und Zahlungen. Prüfen Sie vor Vertragsabschluss die Anwendungsgröße, die insgesamt reservierte Kapazität, die enthaltenen Kopien und das Datenbankkontingent. Eine gespeicherte Regionspräferenz erzeugt kein Replikat. Bestehende Verträge behalten ihre Bedingungen.
Die Kapazität wird im gesamten Konto geteilt. Zählen Sie die Ressourcen jeder Anwendung multipliziert mit ihrer Replikatanzahl sowie Datenbanken und weitere Dienste zusammen. Die Replikatanzahl schließt die erste Instanz ein. Ein Upgrade erhöht die verfügbaren Limits; konfigurieren Sie anschließend die Projektressourcen und Replikate.
Pix ist eine Vorauszahlung, und die Aktivierung erfolgt nach der verifizierten Bestätigung des Zahlungsanbieters. Das Erzeugen eines Pix-Codes aktiviert keinen Tarif und autorisiert keine automatischen monatlichen Abbuchungen. Zahlen Sie nicht erneut, bevor Sie den Status der bestehenden Zahlung geprüft haben.

## Anwendungsreplikate und automatische Skalierung
https://devoracloud.com/docs/replicas?lang=de

Ein Replikat ist eine laufende Kopie der Anwendung. Feste Replikate halten eine konfigurierte Anzahl; die automatische Skalierung passt sie innerhalb von Minimum, Maximum und Tarifkapazität an. Failover ist in jedem Tarif enthalten (eine ausgeschaltete Standby-Kopie in einem anderen Land); Autoscaling und Load Balancing sind optional und werden stundenweise abgerechnet. Gleichzeitig laufende Kopien: Hobby bis zu 2, Pro bis zu 3, Enterprise bis zu 5; jede zusätzliche Kopie wird stundenweise abgerechnet, solange sie läuft. Zusätzliche Kopien beheben keine Anwendungsfehler.
Halten Sie Sitzungen, Warteschlangen und veränderliche Daten in gemeinsam genutzten Diensten. Eine lokale SQLite-Datei, ein lokaler Upload-Ordner oder ein eingebetteter Scheduler erfordern vor dem Skalieren besondere Sorgfalt: Kopien können auseinanderlaufen oder dieselbe geplante Aktion doppelt ausführen.
Es gibt drei Modi: Skalierbarkeit (Autoscaling), Load Balancing oder Failover. Failover ist in jedem Tarif enthalten: Ihr Projekt bleibt online, wenn ein Server ausfällt, denn die Standby-Kopie in einem anderen Land übernimmt von selbst. Autoscaling und Load Balancing sind optional, in allen Tarifen verfügbar und werden nur stundenweise abgerechnet, solange die zusätzlichen Kopien laufen.
Skalierbarkeit (Autoscaling) — im Dashboard einschalten: Überschreitet die CPU das Limit, startet automatisch ein Klon und teilt die Last; sinkt die Nutzung, wird er abgeschaltet und nicht mehr berechnet.
Load Balancing: Eine oder mehrere zusätzliche Kopien laufen rund um die Uhr und teilen sich den Traffic mit der Hauptkopie. Jede zusätzliche Kopie wird stundenweise abgerechnet, solange sie läuft. Die Kopien nutzen dieselbe Datenbank und denselben S3-Speicher; halten Sie Sitzungen, Warteschlangen und Dateien daher in gemeinsam genutzten Diensten, nicht im Arbeitsspeicher oder auf der Festplatte des Containers.
Failover — inklusive: Die Standby-Kopie steht bereit, ist aber in einem anderen Land AUSGESCHALTET — sie verbraucht keine CPU, ihr Image ist bereits heruntergeladen, und jeder Deploy aktualisiert sie. Fällt die Hauptkopie aus, startet ein Wächter die Standby-Kopie in der anderen Region (USA ↔ Deutschland) und das Projekt ist innerhalb von Sekunden von selbst wieder da.
Gleichzeitig laufende Kopien: Hobby bis zu 2, Pro bis zu 3, Enterprise bis zu 5. Jede Kopie hat die Größe des Tarifs. Stundenpreis jeder zusätzlichen Kopie (Tarifpreis ÷ 30 Tage ÷ 24 h): Hobby US$ 0.0069 (≈ US$ 5/Monat bei Dauerbetrieb), Pro US$ 0.0278 (≈ US$ 20/Monat), Enterprise US$ 0.0819 (≈ US$ 59/Monat). Load Balancing: immer laufende Kopie zum vollen Stundenpreis. Autoscaling: die 1. Zusatzkopie zum vollen Preis, ab der nächsten 10 % Rabatt: Hobby US$ 0.0063, Pro US$ 0.0250, Enterprise US$ 0.0738.
Zusätzliche Kopien erfordern einen bezahlten Tarif ohne offene Rechnungen; in der Testphase läuft die App mit 1 Kopie. Die Nutzungsrechnung wird am 1. jedes Monats erstellt und per Pix (Brasilien, PAGUEO) oder Karte (Stripe) bezahlt. Eine offene Nutzungsrechnung folgt derselben Regel wie alle anderen: Pausierung nach 4 Tagen, Löschung nach 9. Nutzung, Preise und Rechnungen finden Sie unter Abrechnung → Zusätzliche Kopien.

## Verfügbarkeit, Verteilung und Backups
https://devoracloud.com/docs/disponibilidade?lang=de

Vertikale Skalierung erhöht CPU oder RAM; horizontale Skalierung fügt Anwendungskopien hinzu. Schutz vor dem Ausfall eines Hosts erfordert Kopien auf verschiedenen Hosts, geeignetes Routing und freie Kapazität. Anwendungen laufen in den USA und in Deutschland; Brasilien ist nur ein CDN-Cache und führt keine Apps aus.
Datenbankreplikation und Failover sind eine separate Konfiguration des Datendienstes. Backups stellen frühere Daten wieder her; Replikation hält betriebsbereite Kopien vor. Weder Anwendungsreplikate noch Datenbankreplikation allein versprechen bei jedem Ausfall null Ausfallzeit.

## Build-Logs und Anwendungslogs
https://devoracloud.com/docs/logs?lang=de

Bereitstellungslogs zeigen die Installation von Abhängigkeiten, die Kompilierung sowie Image- und Bereitstellungsfehler. Öffnen Sie die fehlgeschlagene Veröffentlichung, um sie einzusehen. Anwendungslogs zeigen die Ausgabe des laufenden Programms; nutzen Sie sie für Laufzeitausnahmen und Verbindungsfehler.
Öffnen Sie Probleme, um für einen fehlgeschlagenen Build die verfügbare KI-Diagnose anzufordern. „Fehler für KI kopieren“ enthält, sofern verfügbar, den Kontext der Bereitstellung. Prüfen Sie die Diagnose, bevor Sie Code ändern; teilen Sie bei Bedarf bereinigte Logs mit Ihrem Entwickler oder dem Support.

## Automatische Bereitstellung nach einem Push
https://devoracloud.com/docs/push?lang=de

Ein Push auf den konfigurierten Branch des Repositorys löst eine Bereitstellung aus, wenn die automatische Bereitstellung aktiviert ist. Prüfen Sie den ausgewählten Branch, auch bei Repositorys, die master statt main verwenden.
Verfolgen Sie den Bereitstellungsstatus und testen Sie die resultierende Anwendungs-URL. Lesen Sie das Log der fehlgeschlagenen Bereitstellung, bevor Sie unveränderten Code erneut versuchen.

## Was bei einer Bereitstellung geschieht
https://devoracloud.com/docs/funcionamento?lang=de

Devora liest die Metadaten des Repositorys, um eine Konfiguration vorzuschlagen. Die Ausführungs-Engine klont den Quellcode mit ihrer Zugangsberechtigung, erstellt und speichert ein Image und stellt dann Container mit Variablen, Ressourcenlimits und Replikatanzahl bereit.
Die Anwendungs-Subdomain wird verbunden und HTTPS wird geprüft. Ein erfolgreicher Build allein beweist nicht, dass die Anwendung antwortet. Verfolgen Sie das Ergebnis der Bereitstellung und die Laufzeitlogs. Die Anwendung muss Migrationen ausführen und persistente Daten außerhalb der flüchtigen Containerdateien halten.

## Builder, Dockerfile und Port
https://devoracloud.com/docs/construtor?lang=de

Öffnen Sie Projekteinstellungen → Build und Bereitstellung → Builder. Wählen Sie automatisches Nixpacks, Dockerfile oder statische Website. Dieselbe Konfiguration bleibt unter Ressourcen erreichbar. Geben Sie für Dockerfile den Pfad relativ zum Repository an; Monorepos benötigen oft einen Pfad wie apps/web/Dockerfile.
Legen Sie den Anwendungsport unter Netzwerk und Health-Check → App-Port fest. Er muss dem Port entsprechen, auf dem Ihr Prozess auf 0.0.0.0 lauscht. Speichern Sie die Konfiguration und veröffentlichen Sie erneut, um sie anzuwenden; das Speichern allein ersetzt die laufende Anwendung nicht.

## Plattform-API
https://devoracloud.com/docs/api?lang=de

Die API-Basis ist https://api.devoracloud.com/v1. Erstellen Sie in den Kontowerkzeugen einen API-Schlüssel mit eingeschränkten Berechtigungen und senden Sie Authorization: Bearer IHR_SCHLUESSEL. Ein Schlüssel gehört zu genau einer Organisation und gewährt nur auf diese Zugriff. Ein Schlüssel kann keinen weiteren Schlüssel erstellen: POST /v1/api-keys mit einem Schlüssel ergibt 403 FORBIDDEN; nur eine angemeldete Person erstellt Schlüssel, im Dashboard. Legen Sie einen geheimen API-Schlüssel niemals im Browser-Code offen.
Anfragen werden durch die Mitgliedschaft in der Organisation, die Berechtigungen des Schlüssels und die Tarifkapazität begrenzt. PLAN_LIMIT_EXCEEDED (HTTP 402) erfordert, reservierte Ressourcen zu verringern oder ein Upgrade durchzuführen; details enthält resource, limit und used. Bei resource „subscription“ ist die Testphase beendet oder eine Rechnung offen. POST /v1/projects/:id/scale akzeptiert bis zur Obergrenze des Tarifs (das Failover-Standby ist enthalten und bleibt ausgeschaltet); zusätzliche Kopien für Autoscaling oder Load Balancing werden bis zur Obergrenze (Hobby 2, Pro 3, Enterprise 5) stundenweise abgerechnet und erfordern einen bezahlten Tarif ohne offene Rechnungen; in der Testphase oder bei offener Rechnung antwortet die API mit 402. Blindes Wiederholen erhöht die Kapazität nicht.

## Benachrichtigungen und Integrationen
https://devoracloud.com/docs/webhooks?lang=de

Konfigurieren Sie Ihren HTTPS-Empfänger in den Webhooks-Werkzeugen des Kontos. Verarbeiten Sie wiederholte Ereignisse idempotent und fragen Sie vor wichtigen Aktionen den aktuellen Zustand der Ressource ab.
Webhooks des Zahlungsanbieters sind intern bei Devora. Kunden müssen in ihrer Anwendung keinen Webhook konfigurieren, um ihren Hosting-Tarif zu aktivieren.

## Hauptregion und Replikat-Ziele
https://devoracloud.com/docs/localizacao?lang=de

Die Hauptinstanz und jede Kopie müssen auf getrennten physischen Maschinen laufen, auch innerhalb desselben Landes. Zwei Servereinträge oder zwei virtuelle Maschinen auf einem Host schützen nicht vor dem Ausfall dieses Hosts. Ohne genügend unabhängige Ziele muss die Verteilung ausstehend bleiben und darf nie als geschützt angezeigt werden.
Öffnen Sie im Projekt Einstellungen → Skalierung → Projektstandort. Die Ansicht trennt die laufende Hauptinstanz von Ihrer bevorzugten Region und zeigt den Status jedes Ziels. Demnächst verfügbare Regionen und Regionen in Wartung können nicht ausgewählt werden.
Die Plansumme umfasst die Hauptinstanz und alle zusätzlichen Kopien. Jedes Replikat nutzt dieselben CPU- und Speicherlimits auf einer anderen Maschine; mehr Replikate erhöhen nicht die Leistung einer einzelnen Instanz. Autoscaling ist nur wählbar, wenn es im Plan enthalten ist.
Speichern hält eine Präferenz fest, keine Migration: Das laufende Projekt wird nicht sofort verschoben. Fällt der Hauptserver aus, startet ein Wächter die Failover-Replik innerhalb von Sekunden in der anderen Region (USA ↔ Deutschland), ohne dass Sie etwas tun müssen. Brasilien wird nicht als Ausführungsort angeboten, weil es nur ein CDN-Cache ist.
Ausfallschutz, Load Balancing und Autoscaling sind unterschiedliche Ziele. Die Wiederherstellung hängt von gesunden Kopien, Traffic-Eingängen und verfügbaren Datendiensten ab. Die Anwendung braucht gemeinsame Sitzungen, Dateien in S3 und koordinierte Jobs; Anwendungsreplikate replizieren die Datenbank nicht automatisch.

## CPU, Arbeitsspeicher und Überprüfung der Ressourcen
https://devoracloud.com/docs/recursos?lang=de

Das Dashboard zeigt den Prozentsatz des Anwendungskontingents, nicht die Gesamtauslastung des Servers. Bei einer Anwendung mit 0,5 vCPU bedeutet 100 %, dass dieses Kontingent ausgeschöpft ist; es bedeutet nicht, dass die gesamte Maschine an ihrer Kapazitätsgrenze ist.
Die rote Karte und die Benachrichtigungsglocke zeigen Warnungen zu CPU und Arbeitsspeicher an. Eine Warnung setzt mindestens drei Minuten über 85 % mit aktuellen, lückenlosen Messwerten voraus. Bei 100 % wird sie kritisch. Alte oder fehlende Daten werden nicht als Verbrauch von null dargestellt.
Die Warnung bleibt bestehen, solange der Zustand andauert, und verschwindet nach der Normalisierung. Diagramme verwenden den gemessenen Verlauf, sofern verfügbar. Mehr Datenverkehr, rechenintensive Aufgaben oder Fehler im Code können eine hohe Auslastung verursachen; prüfen Sie die Logs, bevor Sie Ressourcen hinzubuchen.
Ressourcen prüfen öffnet die Einstellungen. Tarife ansehen öffnet die Abrechnung. Die Warnung aktiviert keine Replikate, ändert weder CPU noch RAM und bestätigt keinen Kauf. Stündlich abgerechnete Zusatzleistungen sind in Vorbereitung und werden in dieser Version nicht automatisch berechnet.
CPU, Arbeitsspeicher, lokaler Speicher und S3 sind getrennte Ressourcen. Speichern Sie Bilder und Videos in S3; der lokale Datenträger der Anwendung wird nicht zwischen Replikaten geteilt. Die tatsächliche Frequenz des Kollektors bestimmt, wie oft sich die Messwerte aktualisieren.

## Ihre Anwendung vorbereiten
https://devoracloud.com/docs/preparar?lang=de

1. Lesen Sie den Port aus process.env.PORT: Legen Sie den Port nicht im Code fest. Lauschen Sie auf 0.0.0.0, niemals auf localhost. Wenn ignoriert: Der Router liefert an den deklarierten Port, und niemand antwortet. Besucher erhalten einen 502, obwohl der Container gesund ist.
2. Migrationen beim Start ausführen, nicht beim Build: Ein migrate deploy vor dem Start des Servers. Während das Image gebaut wird, gibt es keine Datenbank, mit der man sich verbinden könnte. Wenn ignoriert: Die Datenbank bleibt ohne Tabellen, und die App liefert bei der ersten Abfrage einen Fehler. Das war der häufigste Fehler bei echten Migrationen.
3. Bei fehlgeschlagener Migration laut scheitern: Schlägt migrate fehl, muss der Prozess mit der Meldung im Log beendet werden — und nicht trotzdem starten. Wenn ignoriert: Die App bleibt online und liefert Fehler, das Dashboard zeigt Grün, und niemand merkt es, bis sich ein Kunde beschwert.
4. NEXT_PUBLIC_*-Variablen sind Build-Argumente: In Next.js werden sie beim Build in das Bundle geschrieben. Deklarieren Sie jede als ARG und übernehmen Sie sie vor der Build-Zeile als ENV. Wenn ignoriert: Der Entwicklungswert bleibt für immer eingebettet. Die Produktionsseite ruft weiterhin localhost auf.
5. Nichts Wichtiges auf der Container-Festplatte: Uploads, Bilder, Anhänge: in den S3-Speicher schicken. Die Container-Festplatte verschwindet, wenn die Kopie neu erstellt wird. Wenn ignoriert: Die Dateien verschwinden bei der nächsten Bereitstellung, ohne Warnung und ohne Möglichkeit, sie wiederherzustellen.
6. Zustand nicht nur im Prozessspeicher halten: Sitzungen, Warteschlangen, gemeinsamer Cache: in die Datenbank oder in Redis. Mit mehr als einer Kopie hat jeder Prozess seinen eigenen Speicher. Wenn ignoriert: Nutzer verlieren ihre Sitzung, sobald eine Anfrage bei einer anderen Kopie landet, und Schreibvorgänge verschwinden ohne Fehlermeldung.
7. Ein eingebauter Scheduler verlangt eine einzige Kopie: Wenn die App einen internen Cron hat, sagen Sie das der Person, die bereitstellt. Die Alternative ist, die Aufgabe in einen eigenen Dienst auszulagern. Wenn ignoriert: Doppelte Abbuchungen, doppelt versendete Nachrichten, versehentlich gesperrte Kunden.
8. Auf / etwas antworten: Jede Antwort unter 500 genügt — auch eine Weiterleitung zum Login. Daran erkennt die Plattform, dass die App läuft. Wenn ignoriert: Die App gilt als ausgefallen, und der Eigentümer erhält eine Ausfallmeldung für einen Ausfall, den es nicht gibt.
9. Logs auf stdout, nicht in eine Datei: Schreiben Sie in die Standardausgabe. Öffnen Sie keine Logdatei im Container. Wenn ignoriert: Das Log steckt auf einer Festplatte fest, die niemand erreicht — genau dann, wenn Sie es brauchen.
10. Jedes Geheimnis kommt aus der Umgebung: API-Schlüssel, Token-Geheimnisse, Zugangsdaten Dritter: nur aus Umgebungsvariablen. Niemals committen, niemals mit einem funktionierenden Standardwert. Wenn ignoriert: Das Geheimnis gelangt ins Repository und funktioniert für jeden, der den Code klont.
11. Monorepo: ein Dienst pro Programm, im selben Projekt: Website und API aus demselben Repository werden zwei Dienste desselben Projekts, jeder mit eigenem Dockerfile und Port. Legen Sie keine zwei Projekte an. Wenn ignoriert: Bei zwei Projekten müssen Geheimnisse von Hand kopiert werden — und an dem Tag, an dem eines geändert wird und das andere nicht, wird das Token nicht mehr akzeptiert und niemand versteht, warum.
12. Dockerfile: Pfad angeben, Kontext im Stammverzeichnis lassen: Geben Sie im Monorepo den vollständigen Pfad zum Dockerfile des Dienstes an. Der Kontext bleibt im Stammverzeichnis, damit die gemeinsame Lockfile gefunden wird. Wenn ignoriert: Der Build bricht mit „open Dockerfile: no such file or directory“ ab, obwohl das Repository ein Dockerfile hat.

## Aktuelle Einschränkungen
https://devoracloud.com/docs/limites?lang=de

- Automatische Backups für MySQL, MariaDB und MongoDB. Nur PostgreSQL hat sie (und nur in Plänen mit Backup). Für die anderen aktivieren Sie den externen Zugriff auf die Datenbank und erstellen den Dump auf Ihrem Rechner.
- SQL-Terminal und Ändern des Datenbankpassworts. Sie können die Zugangsdaten sehen, aber im Dashboard nicht ändern.
- Geplante Aufgaben (Cron) pro Projekt. Hat Ihre App eine geplante Aufgabe, muss sie in der App selbst laufen — und die App dann mit nur einer Kopie, sonst läuft die Aufgabe doppelt.
- Ein Volume, das in mehr als einem Dienst desselben Projekts eingehängt ist. Das Volume gehört zum Hauptdienst; dasselbe Volume in zwei Diensten auf verschiedenen Cluster-Maschinen einzuhängen funktioniert nicht.
- Die Daten in einem Volume über das Dashboard löschen. Das Entfernen des Volumes hebt nur die Einhängung auf; der Inhalt bleibt im Cluster.
- Manuelle Auswahl eines TLS-Zertifikats. Zertifikate werden von der Plattform ausgestellt und erneuert; Pfade pro Domain werden in der Adresskonfiguration festgelegt.
- Festplattenmetriken pro Projekt und Anzahl der Anfragen pro Domain. CPU, Arbeitsspeicher und RX/TX-Netzwerkverkehr pro Projekt sind im Inspektor verfügbar.
- Infrastruktur-Warnungen per E-Mail. Ein Anwendungsausfall wird per E-Mail gemeldet; eine volllaufende Festplatte noch nicht.