# 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 French (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 — Manuel Devora

Qu’est-ce que Devora Cloud ?
Devora Cloud est une plateforme brésilienne d’hébergement cloud du groupe Klaup, conçue pour publier aussi bien des sites simples que des applications complètes. Elle réunit déploiement de projets, bases de données gérées, stockage S3, terminal et suivi du processeur, de la mémoire et du trafic dans un seul tableau de bord.
La plateforme propose une analyse des échecs de compilation assistée par IA et une documentation pour faciliter le diagnostic et l’intégration des services. Les suggestions doivent être vérifiées avant de modifier le code.
L’expansion par pays prévoit le choix de la région principale, les répliques et la mise à l’échelle automatique selon le forfait, la compatibilité de l’application et l’infrastructure disponible. Les opérations sont actuellement aux États-Unis ; les autres localisations sont indiquées comme prévues sur la carte. Enregistrer une préférence de région ne déclenche pas une migration.
https://devoracloud.com/about?lang=fr

Déployer, connecter les services et résoudre les problèmes sur Devora Cloud.
https://devoracloud.com/docs?lang=fr

## Organisation de Devora Cloud
https://devoracloud.com/docs/estrutura?lang=fr

Une organisation est votre compte. Les projets regroupent applications, services, domaines, variables, stockage et bases liées. Un frontend et une API peuvent être deux services du même projet.
Devora coordonne les déploiements. L’infrastructure de données est gérée séparément des applications ; le client n’installe ni n’administre de serveur de base de données. Chaque base liée possède ses informations de connexion.

## Aide avant l’ouverture d’un ticket
https://devoracloud.com/docs/suporte?lang=fr

Décrivez le problème dans Support. Des conseils s’affichent avant l’envoi ; les lire ne crée aucun ticket. Si nécessaire, envoyez projet, déploiement, heure, erreur et vérifications effectuées.
Pour un échec de build, ouvrez Problèmes et lancez l’analyse IA disponible. Elle ne répare pas automatiquement le code. Utilisez Copier l’erreur pour l’IA si disponible, sans mots de passe, jetons ni URL contenant des identifiants.

## Déployer depuis GitHub
https://devoracloud.com/docs/publicar?lang=fr

Connectez GitHub, choisissez dépôt et branche, puis confirmez constructeur et port. Les options sont Nixpacks automatique, Dockerfile et site statique. La détection peut nécessiter une correction.
La plateforme construit l’image, déploie l’application et connecte un sous-domaine HTTPS. Un site statique n’a pas besoin de base. Vérifiez si une base est déjà liée avant d’en demander une autre et consultez la capacité du forfait.

## Publier et gérer avec votre IA
https://devoracloud.com/docs/ia?lang=fr

Toute IA capable de lire une page web et d’appeler une API — ChatGPT, Claude, Gemini, Cursor, GitHub Copilot, Windsurf et d’autres — peut créer le projet, la base de données et le stockage, envoyer votre code et le publier pour vous. Sans Git ni Docker : vous discutez, elle fait le travail.
L’accès passe par un jeton IA généré dans votre tableau de bord. Avec lui, l’IA lit le manuel écrit pour elle sur https://devoracloud.com/llms.txt et utilise l’API Devora au nom de votre compte.
1. Créez votre compte: L’essai gratuit dure 7 jours sur le forfait Hobby et ne demande pas de carte.
2. Générez le jeton IA: Dans le menu latéral du tableau de bord, ouvrez « Jeton IA et API » et cliquez sur « Générer un jeton IA ».
3. Collez le texte prêt à l’emploi dans votre IA: Copiez le texte affiché à l’écran — il contient déjà le jeton et le lien vers le manuel pour IA (https://devoracloud.com/llms.txt) — et collez-le dans la conversation avec votre IA.
4. Répondez aux questions de l’IA: Avant de publier, l’IA vous demande le nom du projet, si vous avez besoin d’une base de données, si vous devez stocker des fichiers (stockage S3) et la région.
5. Recevez l’adresse en ligne: L’IA suit la construction et, une fois terminée, vous envoie l’adresse publiée : https://<nom>.apps.devoracloud.com.
Ce que l’IA peut faire avec le jeton : lister et créer des projets ; créer une base PostgreSQL, MySQL, MariaDB, MongoDB ou Redis (la variable DATABASE_URL, ou REDIS_URL pour Redis, est injectée dans l’application) ; activer le stockage S3 privé (variables S3_*) ; envoyer un ZIP du code et le déployer ; lire les logs de construction et le diagnostic d’échec ; lire les logs d’exécution, les métriques de CPU et de mémoire, les redémarrages et l’usage S3 pour vous dire s’il vous faut plus de processeur, de mémoire ou d’espace ; ajouter des domaines personnalisés ; et définir des variables d’environnement.
Ce que l’IA ne peut pas faire : payer ou changer votre forfait, ni acheter des packs de stockage — c’est vous qui le faites, dans Facturation ou Stockage. Elle ne peut pas non plus créer de clés d’API : seulement vous, connecté au tableau de bord. Les applications tournent aux États-Unis et en Allemagne ; le Brésil est uniquement le cache CDN propre à Devora, pas un lieu d’exécution.
Exemple de texte à coller dans votre IA : « Mon hébergement est Devora Cloud. Lis le manuel pour IA sur https://devoracloud.com/llms.txt et utilise ce jeton : dc_live_… Publie mon projet en me demandant d’abord la base de données, le stockage S3 et la région. »
En cas de problème :
- Essai gratuit terminé ou facture impayée : applications et bases sont suspendues ; payez le forfait et utilisez Démarrer. Une facture en retard de 9 jours entraîne la suppression définitive.
- Limite du forfait atteinte : l’IA vous indique quelle ressource dépasse la limite ; réduisez l’usage ou choisissez un forfait supérieur.
- Le déploiement a échoué : l’IA lit le diagnostic de construction, corrige le code et redéploie.
- Stockage plein : achetez un pack de stockage ou choisissez un forfait supérieur.
Sécurité du jeton: Le jeton n’est affiché qu’une seule fois et donne un accès complet à cette organisation — et à elle seule. Il ne peut pas créer d’autres clés. Ne le publiez jamais et ne le partagez pas dans un lieu public. Vous pouvez le révoquer à tout moment sur le même écran que celui où vous l’avez généré. Pour la CI et les scripts, il existe une option distincte : les clés développeur, à accès limité.

## Plusieurs services par projet
https://devoracloud.com/docs/servicos?lang=fr

Regroupez frontend, API et worker comme services du projet. Chaque service possède un chemin Dockerfile, un port et une commande facultative. Un worker peut réutiliser une image avec une autre commande.
Les variables du projet sont partagées ; des variables propres au service sont également possibles. Les déploiements concernent le service publié. Ne dupliquez pas un projet uniquement pour exécuter un second programme du même dépôt.

## Base gérée et informations de connexion
https://devoracloud.com/docs/banco?lang=fr

Utilisez la base déjà liée ; n’installez pas PostgreSQL ou MySQL dans le conteneur applicatif. L’infrastructure de données est indépendante des répliques applicatives. Ajoutez une base uniquement si nécessaire et absente du projet. Moteurs disponibles : PostgreSQL, MySQL, MariaDB, MongoDB et Redis. Les sauvegardes automatiques existent uniquement pour PostgreSQL, et seulement sur les forfaits avec sauvegarde (Pro 7 jours, Enterprise 30 jours ; Hobby n’en a pas).
Lors de la liaison depuis le projet, la variable de connexion chiffrée est ajoutée automatiquement et l’application est redéployée pour la recevoir. Utilisez la variable et l’hôte privé fournis. Les tables et migrations relèvent de votre processus applicatif.
La haute disponibilité des données nécessite réplication et basculement dans le service de base configuré. Les répliques applicatives ne répliquent pas la base. Votre application doit se reconnecter après un basculement. La réplication ne remplace pas les sauvegardes ni n’annule une suppression accidentelle. Consultez les conditions du service.
Activez l’accès public uniquement pour un client SQL externe si nécessaire. Exportez les données avant toute suppression. Ne supprimez pas une base pour réparer une connexion.

## Les images et fichiers vont dans S3
https://devoracloud.com/docs/armazenamento?lang=fr

Devora Cloud sépare l’exécution de l’application, la base de données et le stockage de fichiers en ressources liées au projet.
Exemple : la photo du produit est dans S3. La base contient son nom, son prix et la référence de la photo.
Stockez le contenu des fichiers dans le stockage objet. La base garde uniquement les métadonnées et la clé ou URL. Demandez à votre IA de suivre ce modèle, sans colonnes binaires pour les photos, vidéos ou pièces jointes.
Ajouter S3 fournit les paramètres de connexion. Votre application doit les utiliser avec un SDK compatible pour envoyer et consulter les fichiers. Le clic ne migre aucun fichier, ne modifie pas le code et ne sauvegarde pas la base.
Une application utilisant déjà R2, IDrive e2 ou un autre S3 peut le conserver. Pour changer de fournisseur, copiez les objets, vérifiez les permissions et actualisez les références avant de couper l’ancien service.
Ne gardez pas les fichiers permanents sur le disque temporaire du conteneur. Pour les fichiers privés, utilisez authentification et liens signés temporaires ; ne rendez pas tout le bucket public pour résoudre un accès.
Les nouvelles connexions du panneau nécessitent des identifiants limités au projet. Les clés administratives ne doivent pas être transmises aux applications clientes.
Ajouter une ressource ouvre un formulaire avec nom et projet. Plusieurs bases et liens S3 apparaissent dans des lignes distinctes. Les liens S3 supplémentaires utilisent des préfixes et variables S3_<identifiant>_* distincts. Chaque base supplémentaire possède sa variable de connexion affichée dans les détails, sans remplacer la connexion existante. Les liens du propriétaire partagent les identifiants ; les préfixes ne les isolent pas.
Ouvrez Bases de données ou Stockage · S3 dans le menu du compte. Recherchez une ressource puis cliquez sur sa ligne pour déployer les détails sous la ligne dans le même tableau.
Base de données : Connexion affiche l’hôte et le port privés. Afficher les identifiants récupère l’URI complète avec mot de passe pour les utilisateurs autorisés. Ne la publiez jamais dans Git, des pages publiques ou des conversations sans contrôle d’accès.
Accès externe : vérifiez l’état puis demandez l’accès internet et confirmez l’exposition. Le worker doit appliquer les règles et publier l’adresse. Une demande acceptée ne signifie pas une connexion prête : consultez Activité et testez. N’utilisez pas l’IP privée sur internet ; désactivez cet accès après utilisation.
S3 : l’administrateur propriétaire peut choisir le projet lors de l’ajout. Le lien fournit un préfixe stable et S3_ENDPOINT, S3_REGION, S3_BUCKET, S3_PREFIX, S3_FORCE_PATH_STYLE, S3_ACCESS_KEY et S3_SECRET_KEY. Le SDK doit ajouter S3_PREFIX au début de chaque clé d’objet.
L’intégration du propriétaire utilise ses identifiants. Un préfixe organise les objets sans restreindre ces identifiants. La vente aux clients nécessite des identifiants limités par le fournisseur et des quotas appliqués ; la souscription automatique reste indisponible. La déconnexion conserve les objets.
IA de développement : configurez S3 côté serveur, envoyez les fichiers dans le bucket/préfixe, gardez clés et métadonnées dans la base et générez des liens signés pour la lecture privée. Ne publiez jamais de clé secrète dans NEXT_PUBLIC_*, JavaScript du navigateur ou Git.
Chiffrement au repos et connexions HTTPS pour le stockage géré. Le bucket actuel utilise SSE-KMS par défaut. L’accès dépend des identifiants et permissions ; les fichiers privés doivent utiliser des liens signés temporaires.
1 To = 1 000 Go. Facturation séparée de l’application, en dollars américains (USD).
Souscription en préparation. Aucun paiement ni activation automatique disponible.

## Fichiers persistants et volumes
https://devoracloud.com/docs/volumes?lang=fr

Les fichiers du conteneur sont temporaires. Utilisez le stockage objet pour les fichiers envoyés et un volume quand le programme exige un chemin persistant.
Le montage s’applique au prochain déploiement. Vérifiez sa confirmation. Un volume local n’est pas un système partagé entre répliques situées sur des machines distinctes.

## Domaine personnalisé et sous-domaine du projet
https://devoracloud.com/docs/dominio?lang=fr

Dans Domaines du projet, ajoutez votre domaine sans protocole ni chemin. Vérifiez sa propriété avec le TXT indiqué. Le CNAME pointe vers le sous-domaine spécifique du projet, pas vers la zone générale.
Pour www.exemple.com, créez un CNAME nommé www avec ce sous-domaine comme cible, sans https://. Pour le domaine racine, suivez les options du fournisseur et du panneau : ALIAS, ANAME ou aplatissement CNAME. N’inventez pas d’IP.
Attendez la propagation DNS puis vérifiez HTTPS. Le certificat est émis et renouvelé automatiquement. Le CNAME du site ne touche pas aux e-mails. Si vous utilisez la messagerie professionnelle Devora sur ce domaine, ajoutez aussi les enregistrements e-mail (MX, SPF, DMARC et DKIM) affichés dans E-mail ; si vos e-mails sont chez un autre service, comme Google Workspace ou Microsoft 365, ne modifiez pas le MX.

## Messagerie professionnelle, DNS et applications
https://devoracloud.com/docs/email?lang=fr

1. Corriger l’envoi bloqué (Relay access denied): Si la réception fonctionne mais l’envoi affiche Relay access denied, ouvrez les paramètres SMTP. Utilisez le port 587, STARTTLS, Mot de passe normal et l’adresse complète comme identifiant. Le port 25 sert aux échanges entre serveurs. Vérifiez que ce compte utilise bien ce serveur sortant et le mot de passe de la boîte, qui peut différer de celui du tableau de bord. Ne partagez jamais de mot de passe dans un ticket. La configuration automatique des applications utilise les enregistrements CNAME autoconfig/autodiscover et SRV du domaine (voir Configurer les enregistrements DNS). Ils fonctionnent même si le site est hébergé en dehors de Devora. Les comptes existants peuvent nécessiter une correction SMTP unique.
2. Accéder depuis le compte ou le projet: Ouvrez E-mail professionnel dans le menu du compte ou du projet. Le projet organise le lien et propose ses domaines connectés. Utilisez un domaine vous appartenant ; le sous-domaine gratuit de l’application n’est pas votre domaine e-mail professionnel.
3. Vérifier l’abonnement et le paiement: L’e-mail est distinct de l’hébergement, facturé en BRL par boîte pour des périodes de 30 jours, sans essai gratuit. Choisissez le nombre et vérifiez prix et quota. Générez puis payez Pix : seule la confirmation auprès du fournisseur active les boîtes. Un paiement en attente ou un clic ne donne aucun accès. L’administrateur propriétaire dispose d’une gratuité validée côté serveur, sans facture.
4. Comprendre extensions et renouvellements: Une augmentation du nombre applique un crédit proportionnel au temps payé restant et ouvre une nouvelle période de 30 jours après paiement. Renouveler le même nombre ajoute 30 jours à l’échéance actuelle. Une réduction doit attendre la fin de la période active.
5. Ajouter et vérifier le domaine: Ajoutez le domaine, éventuellement lié au projet. Publiez d’abord seulement le TXT de propriété à _devora-mail.votredomaine puis vérifiez. Avec service actif et preuve valide, le panneau configure le domaine et affiche DKIM. Un domaine déjà présent nécessite une adoption explicite par l’administrateur propriétaire ; aucune boîte existante n’est importée ou écrasée automatiquement.
6. Configurer les enregistrements DNS: Cliquez sur le domaine pour voir le DNS et créez exactement ces enregistrements : TXT _devora-mail.votredomaine = jeton de vérification ; MX votredomaine 10 mail.bytsend.com (réception) ; TXT votredomaine "v=spf1 mx ~all" (SPF, autorise l’envoi) ; TXT _dmarc.votredomaine "v=DMARC1; p=none" (DMARC) ; et le TXT DKIM, affiché après la vérification (signe les messages). Pour la configuration automatique dans Outlook, Thunderbird et sur mobile : CNAME autoconfig.votredomaine et autodiscover.votredomaine → 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. Ces enregistrements fonctionnent même si le site est hébergé en dehors de Devora. Gardez un seul SPF en fusionnant les services autorisés. Le CNAME du site ne configure pas l’e-mail. Prévoyez la migration avant de modifier un MX existant.
7. Créer une boîte e-mail: Après vérification, ajoutez une boîte avec domaine, nom avant @ et mot de passe d’au moins 12 caractères. Le nombre ne peut dépasser le contrat. L’API ne renvoie pas les mots de passe et Cloud ne les stocke pas en clair. Utilisez Modifier le mot de passe si nécessaire. Réessayez une création échouée avec la même adresse et le même mot de passe.
8. Utiliser le webmail, Outlook ou le mobile: Ouvrez le webmail ou configurez Outlook, Thunderbird ou mobile : adresse e-mail complète comme identifiant, mot de passe de la boîte, serveur entrant IMAP mail.bytsend.com port 993 en SSL et serveur sortant SMTP mail.bytsend.com port 587 en STARTTLS avec authentification. L’autoconfiguration dépend de l’application et de sa version. Le mot de passe est indépendant de celui du panneau Cloud.
9. Consulter quota et validité: Le quota est par boîte et apparaît avant paiement. Les nouveaux prix et quotas s’appliquent aux nouvelles souscriptions et renouvellements. À l’expiration, l’accès des comptes gérés est suspendu sans supprimer les messages ; le renouvellement réactive le service. Les anciennes boîtes hors intégration ne sont pas modifiées.
10. Gérer les boîtes importées: Boîtes importées : lorsqu’un administrateur rattache une boîte existante, elle apparaît dans Comptes e-mail. Les messages et le mot de passe actuel restent sur le serveur ; l’importation ne migre ni ne recrée la boîte. Le rattachement au projet organise le compte sans changer son adresse. La gratuité du propriétaire administrateur ne génère aucune facturation.
11. Changer le mot de passe en sécurité: Changer le mot de passe : ouvrez E-mail professionnel, trouvez l’adresse dans Comptes e-mail et choisissez Modifier le mot de passe. Saisissez un nouveau mot de passe de 12 à 128 caractères puis enregistrez. L’ancien mot de passe ne peut pas être affiché. Après confirmation, mettez à jour Outlook, le téléphone et les autres applications ; les nouvelles connexions au webmail utilisent également ce mot de passe. Les messages sont conservés et le mot de passe Cloud reste indépendant.
12. Résoudre les problèmes et demander de l’aide: Pour l’IA ou le support, indiquez domaine, adresse, panne de connexion/envoi/réception, heure, erreur, état du service et fonctionnement du webmail. Ne transmettez ni mots de passe ni messages privés. Testez envoi et réception avec une adresse externe après configuration DNS.
13. Actualiser le routage après une migration: Routage et migration : consultez le nom du serveur, l’IP publique et le webmail actuels dans le panneau, sans réutiliser une ancienne IP. MX cible un nom DNS, pas une IP. L’administrateur actualise les adresses dans Admin → E-mail professionnel. Cela actualise les instructions sans migrer les boîtes ni modifier le DNS. Avec le même nom, le client conserve MX et l’administrateur actualise A/AAAA. Sinon, actualisez MX et applications. La connexion privée et la clé sont configurées dans Admin → Intégrations. Actualisez puis rouvrez le domaine pour consulter les données actuelles.

## Carte, variables, métriques et terminal
https://devoracloud.com/docs/painel-projeto?lang=fr

La carte montre les liens réels. L’inspecteur affiche CPU, mémoire et débits RX/TX : RX entrant, TX sortant. Ce ne sont pas des quotas mensuels en Go. Une mesure absente ne signifie pas une consommation nulle.
Ouvrez Terminal ou Logs depuis le menu du projet. Choisissez le service et connectez le terminal. Les variables sont lues au démarrage du processus ; un déploiement peut être nécessaire. Gardez les secrets hors des logs et tickets.

## Forfaits, capacité et paiements
https://devoracloud.com/docs/planos?lang=fr

Les nouveaux comptes ont 7 jours d’essai gratuit sur le forfait Hobby à partir de l’inscription, sans carte : 1 projet avec 0,5 vCPU, 512 Mo, 3 Go de disque, 1 base de données et 1 Go de S3, sans sauvegardes ni messagerie professionnelle. À la fin de l’essai, applications et bases sont suspendues immédiatement. Payez un forfait puis utilisez Démarrer pour reprendre. La messagerie n’a pas d’essai gratuit.
Facture impayée : 4 jours après l’échéance, applications et bases sont suspendues ; 9 jours après l’échéance, projets et bases sont supprimés définitivement. Tant que ce n’est pas payé, impossible de créer, déployer ou démarrer ; les envois vers S3 sont bloqués, mais les téléchargements restent possibles. Le tableau de bord affiche un bandeau orange ou rouge avec le délai. Payez avant le 9e jour et utilisez Démarrer pour tout récupérer. Dans l’API, ces refus sont des HTTP 402 avec details.resource « subscription ».
Consultez Tarifs et Forfait et paiements pour les prix, la devise et les limites. Vérifiez les ressources par application, la capacité totale, les copies incluses et le quota de bases avant de souscrire. Enregistrer une préférence de région ne crée aucune réplique. Les contrats existants gardent leurs conditions.
La capacité est partagée par le compte. Additionnez ressources applicatives multipliées par leurs répliques, bases et services. Le nombre de répliques inclut la première instance. Un forfait supérieur augmente les plafonds ; configurez ensuite le projet.
Pix est prépayé et l’activation suit la confirmation vérifiée du prestataire. Générer un code n’active pas le service et n’autorise pas de prélèvement mensuel. Vérifiez l’état avant de payer à nouveau.

## Répliques et mise à l’échelle automatique
https://devoracloud.com/docs/replicas?lang=fr

Une réplique est une copie active. La mise à l’échelle automatique ajuste le nombre entre minimum, maximum et capacité du forfait. Le failover est inclus dans chaque forfait (une copie en attente, éteinte, dans un autre pays) ; l’autoscaling et le load balance sont optionnels et facturés à l’heure. Copies allumées en même temps : Hobby jusqu’à 2, Pro jusqu’à 3, Enterprise jusqu’à 5 ; chaque copie supplémentaire est facturée à l’heure pendant qu’elle tourne. Plus de copies ne corrigent pas les erreurs de code.
Stockez sessions, files et données mutables dans des services partagés. SQLite, fichiers locaux et planificateurs intégrés demandent des précautions : les copies peuvent diverger ou exécuter deux fois la même tâche.
Il existe trois modes : Scalabilité (autoscaling), Load balance ou Failover. Le failover est inclus dans chaque forfait : votre projet reste en ligne quand un serveur tombe, car la copie en attente dans un autre pays prend le relais toute seule. L’autoscaling et le load balance sont optionnels, disponibles dans tous les forfaits et facturés à l’heure uniquement pendant que les copies supplémentaires tournent.
Scalabilité (autoscaling) — à activer dans le tableau de bord : quand le CPU dépasse la limite, un clone démarre tout seul et partage la charge ; quand l’usage baisse, il est éteint et n’est plus facturé.
Load balance : une ou plusieurs copies supplémentaires restent allumées 24 h sur 24 et partagent le trafic avec la principale. Chaque copie supplémentaire est facturée à l’heure tant qu’elle est allumée. Les copies utilisent la même base de données et le même S3 ; gardez donc sessions, files et fichiers dans des services partagés, pas dans la mémoire ni sur le disque du conteneur.
Failover — inclus : la copie en attente est prête mais ÉTEINTE dans un autre pays — elle ne consomme pas de CPU et son image est déjà téléchargée ; chaque déploiement la met à jour. Si la principale tombe, un surveillant démarre la copie en attente dans l’autre région (États-Unis ↔ Allemagne) et le projet revient seul en quelques secondes.
Copies allumées en même temps : Hobby jusqu’à 2, Pro jusqu’à 3, Enterprise jusqu’à 5. Chaque copie a la taille du forfait. Prix horaire de chaque copie supplémentaire (prix du forfait ÷ 30 jours ÷ 24 h) : Hobby US$ 0.0069 (≈ US$ 5/mois si elle reste allumée), Pro US$ 0.0278 (≈ US$ 20/mois), Enterprise US$ 0.0819 (≈ US$ 59/mois). Load balance : copie toujours allumée, plein tarif horaire. Autoscaling : la 1re copie supplémentaire au plein tarif, puis 10 % de remise dès la suivante : Hobby US$ 0.0063, Pro US$ 0.0250, Enterprise US$ 0.0738.
Les copies supplémentaires exigent un forfait payant et à jour ; pendant l’essai, l’application tourne avec 1 copie. La facture d’usage est émise le 1er de chaque mois et se paie par Pix (Brésil, PAGUEO) ou carte (Stripe). Une facture d’usage impayée suit la même règle que les autres : pause après 4 jours, suppression après 9. Usage, prix et factures sont dans Facturation → Copies supplémentaires.

## Disponibilité, distribution et sauvegardes
https://devoracloud.com/docs/disponibilidade?lang=fr

L’échelle verticale augmente CPU ou mémoire ; l’horizontale ajoute des copies. Résister à une panne machine nécessite plusieurs hôtes, routage et capacité. Les applications tournent aux États-Unis et en Allemagne ; le Brésil est uniquement un cache CDN et n’exécute pas d’applications.
La réplication et le basculement de la base sont distincts. Une sauvegarde restaure des données antérieures ; la réplication maintient des copies opérationnelles. Aucun mécanisme seul ne garantit une absence absolue d’interruption.

## Logs de build et d’application
https://devoracloud.com/docs/logs?lang=fr

Les logs du déploiement montrent installation, compilation et déploiement. Ceux de l’application montrent la sortie du programme, les exceptions et les erreurs de connexion.
Dans Problèmes, utilisez l’analyse IA disponible. Copier l’erreur pour l’IA rassemble le contexte si disponible. Vérifiez le diagnostic avant de modifier le code et partagez des logs sans secrets avec votre développeur ou le support.

## Déploiement automatique après un push
https://devoracloud.com/docs/push?lang=fr

Un push sur la branche configurée déclenche un déploiement si l’automatisation est activée. Vérifiez la branche, y compris master plutôt que main.
Suivez le résultat et testez l’URL. Lisez le log d’échec avant de relancer le même code sans modification.

## Déroulement d’un déploiement
https://devoracloud.com/docs/funcionamento?lang=fr

Devora lit les métadonnées pour proposer la configuration. Le moteur clone le code avec son accès, construit l’image et déploie les conteneurs avec variables, limites et répliques.
Le sous-domaine est connecté et HTTPS vérifié. La réussite du build ne prouve pas que l’application répond. Consultez le résultat et les logs. Les migrations et données persistantes doivent être préparées dans votre application.

## Constructeur, Dockerfile et port
https://devoracloud.com/docs/construtor?lang=fr

Ouvrez Paramètres du projet → Build et déploiement → Constructeur. Choisissez Nixpacks automatique, Dockerfile ou site statique. La configuration reste dans Ressources. Indiquez le chemin relatif du Dockerfile, par exemple apps/web/Dockerfile.
Le port se règle dans Réseau et vérification de santé → Port de l’application. Il doit correspondre au processus écoutant sur 0.0.0.0. Enregistrez puis redéployez ; l’enregistrement seul ne remplace pas l’application active.

## API de la plateforme
https://devoracloud.com/docs/api?lang=fr

La base est https://api.devoracloud.com/v1. Créez une clé limitée dans les outils du compte et envoyez Authorization: Bearer VOTRE_CLE. Une clé appartient à une seule organisation et ne donne accès qu’à elle. Une clé ne peut pas créer une autre clé : POST /v1/api-keys appelé avec une clé renvoie 403 FORBIDDEN ; seule une personne connectée crée des clés, dans le tableau de bord. N’exposez pas la clé au navigateur.
Les accès respectent appartenance, permissions et capacité. PLAN_LIMIT_EXCEEDED (HTTP 402) demande de réduire les réservations ou de changer de forfait ; details contient resource, limit et used. Avec resource « subscription », l’essai est terminé ou une facture est impayée. POST /v1/projects/:id/scale accepte jusqu’au plafond du forfait (le failover en attente est inclus et reste éteint) ; les copies supplémentaires pour l’autoscaling ou le load balance sont facturées à l’heure jusqu’au plafond (Hobby 2, Pro 3, Enterprise 5) et exigent un forfait payant et à jour ; pendant l’essai ou avec une facture impayée, l’API répond 402. Répéter ne crée pas de capacité.

## Notifications et intégrations
https://devoracloud.com/docs/webhooks?lang=fr

Configurez votre récepteur HTTPS dans Webhooks du compte. Traitez les événements répétés de manière idempotente et consultez l’état actuel avant les actions importantes.
Les webhooks de paiement sont internes à Devora. Vous n’avez pas à les configurer dans votre application pour activer le forfait.

## Région principale et destinations des réplicas
https://devoracloud.com/docs/localizacao?lang=fr

L’instance principale et chaque copie doivent fonctionner sur des machines physiques distinctes, même dans le même pays. Deux serveurs déclarés ou deux machines virtuelles sur un même hôte ne protègent pas contre sa panne. Sans destinations indépendantes suffisantes, la répartition doit rester en attente et ne jamais être présentée comme protégée.
Dans le projet, ouvrez Paramètres → Mise à l’échelle → Emplacement du projet. L’écran distingue l’instance principale active de la région souhaitée et affiche l’état de chaque destination. Les régions à venir ou en maintenance ne sont pas sélectionnables.
Le total de l’offre inclut l’instance principale et toutes les copies supplémentaires. Chaque réplica utilise les mêmes limites CPU et mémoire sur une autre machine ; ajouter des copies n’augmente pas la puissance individuelle. La mise à l’échelle automatique doit être incluse dans l’offre.
Enregistrer conserve une préférence, pas une migration : le projet en marche n’est pas déplacé tout de suite. Si le serveur principal tombe, un surveillant démarre la réplique de basculement dans l’autre région (États-Unis ↔ Allemagne) en quelques secondes, sans action de votre part. Le Brésil n’est pas proposé comme lieu d’exécution, car il sert uniquement de cache CDN.
Protection contre les pannes, équilibrage et mise à l’échelle ont des objectifs distincts. La reprise dépend de copies saines, des entrées du trafic et des services de données disponibles. L’application doit partager sessions et fichiers S3, et coordonner les tâches ; ses réplicas ne répliquent pas automatiquement la base.

## Consommation CPU, mémoire et ajustement des ressources
https://devoracloud.com/docs/recursos?lang=fr

Le tableau de bord affiche le pourcentage du quota de l’application, pas l’utilisation totale du serveur. Pour une application de 0,5 vCPU, 100 % signifie que ce quota est occupé, pas que toute la machine est saturée.
La carte rouge et la cloche signalent les alertes CPU et mémoire. Une alerte exige au moins trois minutes au-dessus de 85 %, avec des mesures récentes et continues. À 100 %, elle devient critique. Les données anciennes ou absentes ne sont pas affichées comme une consommation nulle.
L’alerte reste visible tant que la condition est active et disparaît après le retour à la normale. Le graphique utilise les mesures historiques disponibles. Trafic, tâches lourdes ou problèmes de code peuvent expliquer une forte consommation ; vérifiez les logs avant d’acheter des ressources.
Vérifier les ressources ouvre les paramètres. Voir les offres ouvre la facturation. L’alerte n’active aucune réplique, ne modifie pas CPU/RAM et ne confirme aucun achat. Les suppléments horaires sont en préparation et ne sont pas facturés automatiquement dans cette version.
CPU, mémoire, stockage local et S3 sont distincts. Stockez images et vidéos dans S3 ; le disque local n’est pas partagé entre répliques. La fréquence réelle du collecteur détermine l’actualisation des mesures.

## Préparer votre application
https://devoracloud.com/docs/preparar?lang=fr

1. Lisez le port dans process.env.PORT: Ne codez pas le port en dur. Écoutez sur 0.0.0.0, jamais sur localhost. Si cette règle est ignorée: Le routeur livre sur le port déclaré et personne ne répond. Le visiteur reçoit une 502 alors que le conteneur est sain.
2. Lancez les migrations au démarrage, pas pendant le build: Un migrate deploy avant de démarrer le serveur. Pendant la construction de l’image, il n’y a aucune base à laquelle se connecter. Si cette règle est ignorée: La base reste avec zéro table et l’application renvoie une erreur dès la première requête. C’était le défaut le plus fréquent lors des vraies migrations.
3. Échouez bruyamment quand la migration échoue: Si le migrate échoue, le processus doit s’arrêter avec le message dans le log — et ne pas démarrer quand même. Si cette règle est ignorée: L’application reste en ligne en servant des erreurs, le tableau de bord est vert, et personne ne s’en aperçoit avant qu’un client se plaigne.
4. Les variables NEXT_PUBLIC_* sont des arguments de build: Dans Next.js, elles sont écrites dans le bundle pendant le build. Déclarez chacune comme ARG et promouvez-la en ENV avant la ligne qui construit. Si cette règle est ignorée: La valeur de développement reste intégrée pour toujours. Le site de production continue d’appeler localhost.
5. Rien d’important sur le disque du conteneur: Fichiers envoyés, images, pièces jointes : envoyez-les vers le stockage S3. Le disque du conteneur disparaît quand la copie est recréée. Si cette règle est ignorée: Les fichiers disparaissent au déploiement suivant, sans avertissement et sans moyen de les récupérer.
6. Ne gardez pas l’état uniquement en mémoire: Session, file, cache partagé : placez-les dans la base ou dans Redis. Avec plusieurs copies, chaque processus a sa propre mémoire. Si cette règle est ignorée: L’utilisateur perd sa session dès qu’une requête arrive sur une autre copie, et des écritures disparaissent sans aucune erreur.
7. Un planificateur intégré exige une seule copie: Si l’application a un cron interne, prévenez la personne qui déploie. L’autre solution est de déplacer la tâche dans un service à part. Si cette règle est ignorée: Facturation en double, message envoyé deux fois, client bloqué par erreur.
8. Répondez quelque chose sur /: Toute réponse inférieure à 500 convient — y compris une redirection vers la connexion. C’est ainsi que la plateforme sait que l’application est vivante. Si cette règle est ignorée: L’application est considérée comme hors ligne et le propriétaire reçoit une alerte de panne qui n’existe pas.
9. Logs sur stdout, pas dans un fichier: Écrivez sur la sortie standard. N’ouvrez pas de fichier de log dans le conteneur. Si cette règle est ignorée: Le log reste coincé sur un disque que personne n’atteint, précisément quand vous en avez besoin.
10. Chaque secret vient de l’environnement: Clé d’API, secret de jeton, identifiant tiers : uniquement via des variables d’environnement. Jamais commité, jamais avec une valeur par défaut qui fonctionne. Si cette règle est ignorée: Le secret fuit dans le dépôt et fonctionne pour quiconque clone le code.
11. Monorepo : un service par programme, dans le même projet: Le site et l’API du même dépôt deviennent deux services du même projet, chacun avec son Dockerfile et son port. Ne créez pas deux projets. Si cette règle est ignorée: Avec deux projets, les secrets doivent être recopiés à la main de l’un à l’autre — et le jour où l’un change et pas l’autre, le jeton n’est plus accepté et personne ne comprend pourquoi.
12. Dockerfile : indiquez le chemin, gardez le contexte à la racine: Dans un monorepo, indiquez le chemin complet du Dockerfile du service. Le contexte reste à la racine pour trouver le lockfile partagé. Si cette règle est ignorée: Le build échoue avec « open Dockerfile: no such file or directory » dans un dépôt qui contient pourtant un Dockerfile.

## Limites actuelles
https://devoracloud.com/docs/limites?lang=fr

- Sauvegardes automatiques de MySQL, MariaDB et MongoDB. Seul PostgreSQL en a (et uniquement sur les forfaits avec sauvegarde). Pour les autres, activez l’accès externe de la base et faites le dump depuis votre machine.
- Terminal SQL et changement du mot de passe de la base. Vous pouvez voir les identifiants, pas les modifier dans le tableau de bord.
- Tâches planifiées (cron) par projet. Si votre application a une tâche planifiée, elle doit se trouver dans l’application — qui doit alors tourner avec une seule copie, sinon la tâche s’exécute deux fois.
- Un volume monté sur plusieurs services du même projet. Le volume va au service principal ; monter le même volume sur deux services situés sur des machines différentes du cluster ne fonctionne pas.
- Supprimer les données d’un volume depuis le tableau de bord. Retirer le volume annule le montage ; le contenu reste sur le cluster.
- Choisir un certificat TLS à la main. La plateforme émet et renouvelle les certificats ; les chemins par domaine se règlent dans la configuration de l’adresse.
- Métriques de disque par projet et nombre de requêtes par domaine. CPU, mémoire et trafic réseau RX/TX par projet sont disponibles dans l’inspecteur.
- Alertes d’infrastructure par e-mail. Une panne d’application envoie un e-mail ; un disque qui se remplit, pas encore.