# 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 Spanish (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 — Manual de Devora

¿Qué es Devora Cloud?
Devora Cloud es una plataforma brasileña de alojamiento en la nube del grupo Klaup, diseñada para publicar desde sitios sencillos hasta aplicaciones completas. Reúne despliegue de proyectos, bases de datos gestionadas, almacenamiento S3, terminal y monitorización de CPU, memoria y tráfico en un solo panel.
La plataforma ofrece análisis de fallos de compilación con IA y documentación para ayudar a diagnosticar problemas e integrar servicios. Las sugerencias deben revisarse antes de modificar el código.
La expansión por países contempla elegir la región principal, réplicas y escalado automático según el plan, la compatibilidad de la aplicación y la infraestructura disponible. Actualmente la operación está en Estados Unidos; las demás ubicaciones aparecen como previstas en el mapa. Guardar una preferencia de región no ejecuta una migración.
https://devoracloud.com/about?lang=es

Cómo publicar, conectar servicios y resolver problemas en Devora Cloud.
https://devoracloud.com/docs?lang=es

## Cómo se organiza Devora Cloud
https://devoracloud.com/docs/estrutura?lang=es

La organización es tu cuenta. Los proyectos agrupan aplicaciones, servicios, dominios, variables, almacenamiento y bases vinculadas. Un frontend y una API del mismo repositorio pueden ser dos servicios del mismo proyecto.
Devora coordina la publicación. La infraestructura de datos se administra por separado de las aplicaciones; el cliente no instala ni administra un servidor de base de datos. Cada base vinculada tiene sus datos de conexión.

## Ayuda antes de abrir una solicitud
https://devoracloud.com/docs/suporte?lang=es

Describe el problema en Soporte. Las indicaciones aparecen antes del envío; leerlas no abre ninguna solicitud. Si no resuelven el problema, envía proyecto, publicación, hora, error y comprobaciones realizadas.
Para fallos de build, abre Problemas y utiliza el análisis IA disponible. No repara automáticamente el código. Usa Copiar error para la IA cuando esté disponible y comparte el contexto sin contraseñas, tokens ni URLs con credenciales.

## Publicar desde GitHub
https://devoracloud.com/docs/publicar?lang=es

Conecta GitHub, elige repositorio y rama y confirma constructor y puerto. Las opciones son Nixpacks automático, Dockerfile y sitio estático. La detección puede necesitar corrección.
La plataforma construye la imagen, publica la aplicación y conecta un subdominio con HTTPS. Un sitio estático no necesita base de datos. Revisa si ya existe una base vinculada antes de solicitar otra y comprueba el límite del plan.

## Publicar y gestionar con tu IA
https://devoracloud.com/docs/ia?lang=es

Cualquier IA capaz de leer una página web y llamar a una API — ChatGPT, Claude, Gemini, Cursor, GitHub Copilot, Windsurf y otras — puede crear el proyecto, la base de datos y el almacenamiento, subir tu código y publicarlo por ti. Sin Git y sin Docker: tú conversas, ella hace el trabajo.
El acceso se concede con un token de IA generado en tu panel. Con él, la IA lee el manual escrito para ella en https://devoracloud.com/llms.txt y usa la API de Devora en nombre de tu cuenta.
1. Crea tu cuenta: La prueba gratuita dura 7 días en el plan Hobby y no pide tarjeta.
2. Genera el token de IA: En el menú lateral del panel, abre "Token de IA y API" y haz clic en "Generar token de IA".
3. Pega el texto listo en tu IA: Copia el texto que aparece en pantalla — ya incluye el token y el enlace al manual para IA (https://devoracloud.com/llms.txt) — y pégalo en la conversación con tu IA.
4. Responde a las preguntas de la IA: Antes de publicar, la IA te pregunta el nombre del proyecto, si necesitas base de datos, si necesitas guardar archivos (almacenamiento S3) y la región.
5. Recibe la dirección en línea: La IA sigue la construcción y, cuando termina, te envía la dirección publicada: https://<nombre>.apps.devoracloud.com.
Lo que la IA puede hacer con el token: listar y crear proyectos; crear una base de datos PostgreSQL, MySQL, MariaDB, MongoDB o Redis (la variable DATABASE_URL, o REDIS_URL en Redis, se inyecta en la app); activar el almacenamiento S3 privado (variables S3_*); subir un ZIP con el código y publicarlo; leer los logs de la construcción y el diagnóstico de fallos; leer los logs de ejecución, las métricas de CPU y memoria, los reinicios y el uso de S3 para decirte si necesitas más procesador, memoria o espacio; añadir dominios propios; y configurar variables de entorno.
Lo que la IA no puede hacer: pagar o cambiar tu plan, ni comprar paquetes de almacenamiento — eso lo haces tú en Facturación o Almacenamiento. Tampoco puede crear claves de API: solo tú, con sesión iniciada en el panel. Las apps se ejecutan en EE. UU. y en Alemania; Brasil es solo la caché CDN propia de Devora, no un lugar donde se ejecutan apps.
Ejemplo de texto para pegar en tu IA: "Mi hosting es Devora Cloud. Lee el manual para IA en https://devoracloud.com/llms.txt y usa este token: dc_live_… Publica mi proyecto, preguntándome antes por la base de datos, el almacenamiento S3 y la región."
Si algo sale mal:
- La prueba gratuita terminó o hay una factura impagada: las apps y bases quedan pausadas; paga el plan y usa Iniciar. Una factura vencida hace 9 días lleva a la eliminación definitiva.
- Se alcanzó el límite del plan: la IA te dice qué recurso superó el límite; reduce el uso o elige un plan mayor.
- La publicación falló: la IA lee el diagnóstico de la construcción, corrige el código y vuelve a publicar.
- Almacenamiento lleno: compra un paquete de almacenamiento o elige un plan mayor.
Seguridad del token: El token se muestra una sola vez y da acceso completo a esta organización — y solo a ella. No puede crear otras claves. Nunca lo publiques ni lo compartas en un lugar público. Puedes revocarlo en cualquier momento en la misma pantalla donde lo generaste. Para CI y scripts existe otra opción: las claves para desarrolladores, con acceso limitado.

## Varios servicios por proyecto
https://devoracloud.com/docs/servicos?lang=es

Agrupa frontend, API y worker como servicios del proyecto. Cada uno tiene ruta de Dockerfile, puerto y comando de inicio opcional. Un worker puede reutilizar una imagen con otro comando.
Las variables del proyecto se comparten entre sus servicios; también puede haber variables específicas. Cada publicación pertenece al servicio publicado. No dupliques un proyecto solo para ejecutar otro programa del mismo repositorio.

## Base de datos administrada y conexión
https://devoracloud.com/docs/banco?lang=es

Utiliza la base ya vinculada; no instales PostgreSQL o MySQL en el contenedor de la aplicación. La infraestructura de datos es independiente de las réplicas de la aplicación. Añade una base solo si hace falta y todavía no existe. Motores disponibles: PostgreSQL, MySQL, MariaDB, MongoDB y Redis. Las copias de seguridad automáticas existen solo para PostgreSQL y solo en planes con backup (Pro 7 días, Enterprise 30 días; Hobby no tiene).
Al vincular la base desde el proyecto, la variable cifrada se añade automáticamente y se vuelve a publicar la aplicación para recibirla. Utiliza el host privado y la variable suministrados. Las migraciones y tablas son responsabilidad del proceso de publicación de tu aplicación.
La alta disponibilidad de datos requiere replicación y conmutación en el servicio de base configurado. Las réplicas de la aplicación no replican la base. La aplicación debe reconectarse después de una conmutación. La replicación no sustituye las copias de seguridad ni deshace borrados accidentales. Consulta las condiciones del servicio.
Habilita acceso público solo si necesitas un cliente SQL externo. Exporta los datos antes de borrar la base. No la borres para corregir una conexión.

## Las imágenes y archivos van en S3
https://devoracloud.com/docs/armazenamento?lang=es

Devora Cloud separa la ejecución de la aplicación, la base de datos y el almacenamiento de archivos como recursos conectados al proyecto.
Ejemplo: la foto del producto está en S3. La base guarda nombre, precio y referencia de esa foto.
Guarda el contenido de los archivos en almacenamiento de objetos. La base conserva solo metadatos y la clave o URL. Indica a tu IA que siga este patrón, sin columnas binarias para fotos, vídeos o adjuntos.
Añadir S3 proporciona la conexión. La aplicación debe usar esas variables y un SDK compatible para enviar y consultar archivos. El clic no migra archivos antiguos, modifica el código ni hace copias de la base.
Una aplicación que ya usa R2, IDrive e2 u otro S3 puede conservarlo. Antes de cambiar de proveedor, copia los objetos, revisa permisos y actualiza las referencias.
No guardes uploads permanentes en el disco descartable del contenedor. Para archivos privados usa autenticación y enlaces firmados con caducidad; no publiques todo el bucket para corregir un acceso.
Las nuevas conexiones del panel dependen de credenciales restringidas al proyecto. Las claves administrativas no se entregan a aplicaciones de clientes.
Añadir recurso abre un formulario con nombre y proyecto. Puedes añadir varias bases y vínculos S3 y abrir cada fila. Los S3 adicionales usan carpetas y variables S3_<identificador>_*. Las bases adicionales tienen su propia variable de conexión visible en los detalles, sin sustituir la conexión actual. Los vínculos del propietario comparten credenciales; las carpetas no aíslan las claves.
Abre Bases de datos o Almacenamiento · S3 en el menú de la cuenta. Busca un recurso y pulsa su fila para expandir los detalles debajo de la fila en la misma tabla.
Base de datos: Conexión muestra host y puerto privados. Mostrar credenciales obtiene la URI completa con contraseña solo para usuarios autorizados. No la publiques en Git, páginas públicas o conversaciones sin control de acceso.
Acceso externo: comprueba el estado, solicita acceso por internet y confirma la exposición. El worker debe aplicar las reglas y publicar la dirección. Una solicitud aceptada no significa conexión lista: consulta Actividad y prueba. No uses la IP interna por internet y desactiva el acceso cuando no sea necesario.
S3: el administrador propietario puede seleccionar el proyecto al añadir almacenamiento. Se proporciona un prefijo estable y S3_ENDPOINT, S3_REGION, S3_BUCKET, S3_PREFIX, S3_FORCE_PATH_STYLE, S3_ACCESS_KEY y S3_SECRET_KEY. El SDK debe anteponer S3_PREFIX a las claves de objetos.
La integración del propietario usa sus credenciales. Un prefijo organiza objetos pero no limita esas credenciales. La venta a clientes necesita credenciales restringidas por el proveedor y cuotas efectivas; la contratación automática sigue indisponible. Desconectar conserva los objetos.
IA de desarrollo: configura S3 en el servidor, envía archivos al bucket/prefijo, guarda claves y metadatos en la base y genera enlaces firmados para lectura privada. Nunca expongas claves secretas en NEXT_PUBLIC_*, JavaScript del navegador o Git.
Cifrado en reposo y conexiones HTTPS para almacenamiento administrado. El bucket actual utiliza SSE-KMS por defecto. El acceso depende de credenciales y permisos; los archivos privados deben usar enlaces firmados temporales.
1 TB = 1.000 GB. Cobro separado de la aplicación, en dólares estadounidenses (USD).
Contratación en preparación. No hay cargos ni activación automática disponibles.

## Archivos persistentes y volúmenes
https://devoracloud.com/docs/volumes?lang=es

Los archivos del contenedor son descartables. Usa almacenamiento de objetos para archivos subidos y un volumen cuando el programa necesite una ruta persistente.
El montaje se aplica en la siguiente publicación. Comprueba su confirmación. Un volumen local no es un sistema compartido entre réplicas en máquinas distintas.

## Dominio propio y subdominio del proyecto
https://devoracloud.com/docs/dominio?lang=es

En Dominios del proyecto, añade el dominio sin protocolo ni ruta. Verifica la titularidad con el TXT indicado. El CNAME apunta al subdominio específico del proyecto, no a la zona genérica de la plataforma.
Para www.ejemplo.com, crea un CNAME llamado www cuyo destino sea el subdominio indicado, sin https://. Para el dominio raíz sigue las opciones admitidas por el proveedor y el panel, como ALIAS, ANAME o aplanamiento CNAME. No inventes una IP.
Espera la propagación DNS y comprueba HTTPS. La emisión y renovación del certificado son automáticas. El CNAME del sitio no toca el correo. Si vas a usar el correo empresarial de Devora en este dominio, agrega también los registros de correo (MX, SPF, DMARC y DKIM) que aparecen en Correo; si el correo de tu empresa está en otro servicio, como Google Workspace o Microsoft 365, no cambies el MX.

## Correo empresarial, DNS y aplicaciones
https://devoracloud.com/docs/email?lang=es

1. Corrige el envío bloqueado (Relay access denied): Si recibes mensajes pero al enviar aparece Relay access denied, abre la configuración SMTP. Usa el puerto 587, STARTTLS, Contraseña normal y tu dirección completa como usuario. El puerto 25 es para entrega entre servidores. Comprueba que la cuenta utiliza ese servidor de salida y la contraseña del buzón, que puede ser distinta a la del panel. No compartas contraseñas en la solicitud. La configuración automática en las aplicaciones usa los registros CNAME autoconfig/autodiscover y los SRV del dominio (ver Configura los registros DNS). Funcionan aunque el sitio esté alojado fuera de Devora. Las cuentas existentes pueden necesitar corregir SMTP una vez.
2. Accede desde la cuenta o el proyecto: Abre Correo empresarial en el menú de la cuenta o del proyecto. El proyecto organiza el vínculo y ofrece dominios conectados. Usa un dominio propio; el subdominio gratuito de la aplicación no es tu dominio de correo empresarial.
3. Revisa contratación y pago: El correo es independiente del hosting, con cobro en BRL por cuenta por períodos de 30 días y sin prueba gratuita. Elige cantidad y revisa precio y cuota. Genera y paga Pix: solo la confirmación consultada al proveedor activa las cuentas. Un pago pendiente o un clic no conceden acceso. El administrador propietario tiene una cortesía validada por el servidor, sin factura.
4. Entiende ampliaciones y renovaciones: Al aumentar la cantidad se acredita el tiempo pagado restante proporcionalmente y comienza un nuevo período de 30 días tras el pago. Renovar la misma cantidad añade 30 días al vencimiento actual. Las reducciones deben esperar al fin del período activo.
5. Añade y verifica tu dominio: Añade el dominio y opcionalmente su proyecto. Publica primero solo el TXT de propiedad en _devora-mail.tudominio y verifica. Con servicio activo y prueba correcta, el panel configura el dominio y muestra DKIM. Adoptar un dominio ya existente requiere acción explícita del administrador propietario; no se importan ni sobrescriben cuentas automáticamente.
6. Configura los registros DNS: Pulsa la fila del dominio para ver DNS y crea exactamente estos registros: TXT _devora-mail.tudominio = token de verificación; MX tudominio 10 mail.bytsend.com (recepción); TXT tudominio "v=spf1 mx ~all" (SPF, autoriza el envío); TXT _dmarc.tudominio "v=DMARC1; p=none" (DMARC); y el TXT de DKIM, que aparece tras la verificación (firma los mensajes). Para la configuración automática en Outlook, Thunderbird y móvil: CNAME autoconfig.tudominio y autodiscover.tudominio → 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. Estos registros funcionan aunque el sitio esté alojado fuera de Devora. Mantén un único SPF combinando los servicios autorizados. El CNAME del sitio no configura correo. Planifica la migración antes de cambiar un MX existente.
7. Crea una cuenta de correo: Con el dominio verificado, añade una cuenta, elige dominio, nombre antes de @ y contraseña de al menos 12 caracteres. No puede superarse la cantidad contratada. La API no devuelve contraseñas ni Cloud las guarda en texto. Usa Cambiar contraseña cuando sea necesario. Reintenta una creación fallida con la misma dirección y contraseña.
8. Usa webmail, Outlook o móvil: Abre webmail o configura Outlook, Thunderbird o móvil: dirección de correo completa como usuario, contraseña de la cuenta, entrada IMAP mail.bytsend.com puerto 993 con SSL y salida SMTP mail.bytsend.com puerto 587 con STARTTLS y autenticación. La autoconfiguración depende de la aplicación y versión. La contraseña es independiente de la del panel Cloud.
9. Consulta espacio y vigencia: La cuota es por cuenta y aparece antes del pago. Los cambios de precio y cuota se aplican a nuevas contrataciones y renovaciones. Al vencer, se suspende el acceso de cuentas administradas conservando mensajes; renovar reactiva el servicio. No se modifican cuentas antiguas ajenas a la integración.
10. Gestiona cuentas importadas: Cuentas importadas: cuando el administrador vincula una cuenta existente, aparece en Cuentas de correo. Los mensajes y la contraseña actual permanecen en el servidor; la importación no migra ni recrea la cuenta. El proyecto organiza el vínculo sin cambiar la dirección. La cortesía del administrador propietario no genera cobros.
11. Cambia la contraseña con seguridad: Cambiar contraseña: abre Correo empresarial, localiza la dirección en Cuentas de correo y pulsa Cambiar contraseña. Introduce una nueva contraseña de 12 a 128 caracteres y guarda. No se puede consultar la contraseña anterior. Tras guardar correctamente, actualízala en Outlook, el móvil y las demás aplicaciones; los nuevos accesos al webmail también la usan. El cambio conserva los mensajes y no modifica la contraseña de acceso a Cloud.
12. Resuelve problemas y pide ayuda: Para IA o soporte informa dominio, cuenta afectada, fallo de login/envío/recepción, hora, error, estado del servicio y si funciona webmail. No envíes contraseñas ni mensajes privados. Prueba envío y recepción con una dirección externa tras configurar DNS.
13. Actualiza el apuntado tras una migración: Apuntado y migración: consulta nombre, IP pública y webmail actuales en el panel, sin reutilizar una IP antigua. MX apunta a un nombre DNS, no a una IP. El administrador actualiza las direcciones en Admin → Correo empresarial. Esto actualiza las instrucciones, pero no migra cuentas ni modifica DNS. Con el mismo nombre, el cliente mantiene MX y el administrador actualiza A/AAAA. Si cambia el nombre, actualiza MX y aplicaciones. La conexión privada y la clave se configuran en Admin → Integraciones. Actualiza y vuelve a abrir el dominio para consultar los datos actuales.

## Mapa, variables, métricas y terminal
https://devoracloud.com/docs/painel-projeto?lang=es

El mapa muestra los vínculos reales entre servicios. El inspector muestra CPU, memoria y tasas de red RX/TX. RX es entrada y TX salida; no son una franquicia mensual en GB. Un dato ausente no significa consumo cero.
Terminal y Logs se abren desde el menú del proyecto. Selecciona el servicio y conecta el terminal. Las variables se leen al iniciar el proceso; puede ser necesaria una nueva publicación. No incluyas secretos en logs ni solicitudes.

## Planes, capacidad y pagos
https://devoracloud.com/docs/planos?lang=es

Las cuentas nuevas tienen 7 días de prueba gratuita en el plan Hobby desde el registro, sin tarjeta: 1 proyecto con 0,5 vCPU, 512 MB, 3 GB de disco, 1 base de datos y 1 GB de S3, sin copias de seguridad ni correo empresarial. Cuando termina la prueba, las aplicaciones y las bases se pausan de inmediato. Paga un plan y usa Iniciar para volver. El correo empresarial no tiene prueba gratuita.
Factura impagada: 4 días después del vencimiento, las aplicaciones y las bases se pausan; 9 días después del vencimiento, los proyectos y las bases se eliminan de forma definitiva. Mientras no pagues no puedes crear, publicar ni iniciar nada; las subidas a S3 quedan bloqueadas, pero las descargas siguen permitidas. El panel muestra una franja naranja o roja con el plazo. Paga antes del día 9 y usa Iniciar para recuperarlo todo. En la API estos rechazos son HTTP 402 con details.resource "subscription".
Los precios, la moneda y los límites están en Precios y Plan y pagos. Revisa los recursos por aplicación, la capacidad total, las copias incluidas y la cuota de bases antes de contratar. Guardar una preferencia de región no crea una réplica. Los contratos existentes mantienen sus condiciones.
La capacidad se comparte en la cuenta. Suma cada aplicación multiplicada por sus réplicas, bases y servicios. El número de réplicas incluye la primera. Una mejora de plan amplía los límites; después configura los recursos del proyecto.
Pix es prepago y se activa tras la confirmación verificada del proveedor. Generar el código no activa el servicio ni autoriza cobros mensuales automáticos. Comprueba el estado antes de volver a pagar.

## Réplicas y escalado automático
https://devoracloud.com/docs/replicas?lang=es

Una réplica es una copia activa. El escalado automático ajusta la cantidad dentro del mínimo, máximo y capacidad contratados. El failover viene incluido en todo plan (una copia en espera, apagada, en otro país); la autoescala y el load balance son opcionales y se cobran por hora. Copias encendidas a la vez: Hobby hasta 2, Pro hasta 3, Enterprise hasta 5; cada copia extra se cobra por hora mientras funciona. Más copias no corrigen errores de código.
Guarda sesiones, colas y datos mutables en servicios compartidos. SQLite, archivos locales y tareas programadas dentro del proceso requieren atención: las copias pueden divergir o ejecutar una tarea dos veces.
Hay tres modos: Escalabilidad (autoescala), Load balance o Failover. El failover viene incluido en todo plan: tu proyecto no queda fuera de línea cuando un servidor cae, porque la copia en espera en otro país toma el control sola. La autoescala y el load balance son opcionales, existen en todos los planes y se cobran por hora solo mientras las copias extra funcionan.
Escalabilidad (autoescala) — la activas en el panel: cuando la CPU supera el límite, un clon arranca solo y reparte la carga; cuando el uso baja, se apaga y deja de cobrarse.
Load balance: una o más copias extra quedan encendidas 24 horas y reparten el tráfico con la principal. Cada copia extra se cobra por hora mientras está encendida. Las copias comparten la misma base de datos y el mismo S3, así que guarda sesiones, colas y archivos en servicios compartidos, no en la memoria ni en el disco del contenedor.
Failover — incluido: la copia en espera está lista pero APAGADA en otro país — no consume CPU y su imagen ya está descargada; en cada deploy recibe la versión nueva. Si la principal falla, un vigilante enciende la copia en espera en la otra región (EE. UU. ↔ Alemania) y el proyecto vuelve solo en segundos.
Copias encendidas a la vez: Hobby hasta 2, Pro hasta 3, Enterprise hasta 5. Cada copia tiene el tamaño del plan. Precio por hora de cada copia extra (precio del plan ÷ 30 días ÷ 24 h): Hobby US$ 0.0069 (≈ US$ 5/mes si queda siempre encendida), Pro US$ 0.0278 (≈ US$ 20/mes), Enterprise US$ 0.0819 (≈ US$ 59/mes). Load balance: copia siempre encendida, precio completo por hora. Autoescala: la 1.ª copia extra a precio completo y, desde la siguiente, 10% de descuento: Hobby US$ 0.0063, Pro US$ 0.0250, Enterprise US$ 0.0738.
Las copias extra requieren un plan pago y al día; durante la prueba, la app funciona con 1 copia. La factura de uso se emite el día 1 de cada mes y se paga por Pix (Brasil, PAGUEO) o tarjeta (Stripe). Una factura de uso impaga sigue la misma regla que las demás: pausa a los 4 días y eliminación a los 9. Uso, precios y facturas están en Facturación → Copias extra.

## Disponibilidad, distribución y copias
https://devoracloud.com/docs/disponibilidade?lang=es

El escalado vertical aumenta CPU o RAM; el horizontal añade copias. Protegerse de un fallo de máquina requiere copias en máquinas distintas, enrutamiento y capacidad. Las aplicaciones se ejecutan en EE. UU. y en Alemania; Brasil es solo caché CDN y no ejecuta apps.
La replicación y conmutación de la base son independientes. Una copia de seguridad recupera datos anteriores; la replicación mantiene copias operativas. Ninguna de estas medidas por sí sola garantiza ausencia total de interrupciones.

## Logs de build y aplicación
https://devoracloud.com/docs/logs?lang=es

El log de publicación muestra instalación, compilación y errores de despliegue. El de aplicación muestra la salida del programa en ejecución, errores de conexión y excepciones.
Abre Problemas para el análisis IA disponible. Copiar error para la IA reúne contexto cuando está disponible. Revisa el diagnóstico antes de cambiar el código y comparte logs sin secretos con tu desarrollador o soporte.

## Publicación automática por push
https://devoracloud.com/docs/push?lang=es

Un push a la rama configurada publica si la automatización está activada. Revisa si el repositorio usa main, master u otra rama.
Sigue el resultado y prueba la URL publicada. Lee el log del fallo antes de repetir el mismo código sin cambios.

## Qué ocurre al publicar
https://devoracloud.com/docs/funcionamento?lang=es

Devora lee los metadatos para sugerir la configuración. El motor clona el código con su credencial, construye la imagen y publica contenedores con variables, recursos y réplicas.
Conecta el subdominio y verifica HTTPS. Un build correcto no demuestra que la aplicación responda. Consulta el resultado y los logs. Las migraciones y los datos persistentes deben prepararse en tu aplicación.

## Constructor, Dockerfile y puerto
https://devoracloud.com/docs/construtor?lang=es

Abre Configuración del proyecto → Build y publicación → Constructor. Elige Nixpacks automático, Dockerfile o sitio estático. También está en Recursos. Indica la ruta de Dockerfile relativa al repositorio, como apps/web/Dockerfile.
El puerto está en Red y verificación de salud → Puerto de la aplicación. Debe coincidir con el proceso que escucha en 0.0.0.0. Guarda y vuelve a publicar; guardar no sustituye la aplicación en ejecución.

## API de la plataforma
https://devoracloud.com/docs/api?lang=es

La base es https://api.devoracloud.com/v1. Crea una clave con permisos limitados en las herramientas de cuenta y envía Authorization: Bearer TU_CLAVE. La clave pertenece a una sola organización y solo da acceso a ella. Una clave no puede crear otra: POST /v1/api-keys hecho con una clave responde 403 FORBIDDEN; solo una persona con sesión iniciada crea claves, desde el panel. No expongas la clave en el navegador.
Se verifican pertenencia, permisos y capacidad. PLAN_LIMIT_EXCEEDED (HTTP 402) requiere reducir recursos reservados o mejorar el plan; details trae resource, limit y used. Con resource "subscription", la prueba terminó o hay una factura impagada. POST /v1/projects/:id/scale acepta hasta el tope del plan (el failover en espera viene incluido y queda apagado); las copias extra para autoescala o load balance se cobran por hora hasta el tope (Hobby 2, Pro 3, Enterprise 5) y requieren un plan pago y al día; en la prueba o con una factura impaga la API responde 402. Repetir la petición no aumenta la capacidad.

## Notificaciones e integraciones
https://devoracloud.com/docs/webhooks?lang=es

Configura el receptor HTTPS en Webhooks de la cuenta. Procesa eventos repetidos de manera idempotente y consulta el estado actual antes de acciones importantes.
Los webhooks de pagos son internos de Devora. No necesitas configurarlos en tu aplicación para activar el plan.

## Región principal y destinos de réplicas
https://devoracloud.com/docs/localizacao?lang=es

La principal y cada copia deben ejecutarse en máquinas físicas distintas, incluso dentro del mismo país. Dos registros de servidor o dos máquinas virtuales en un mismo host no protegen contra su caída. Sin suficientes destinos independientes, la distribución debe permanecer pendiente y nunca mostrarse como protegida.
En el proyecto, abre Configuración → Escalabilidad → Ubicación del proyecto. La pantalla separa el principal en ejecución de la región deseada y muestra el estado de cada destino. No se pueden seleccionar regiones próximas o en mantenimiento.
El total del plan incluye el principal y todas las copias adicionales. Cada réplica usa los mismos límites de CPU y memoria, en otra máquina; distribuir réplicas no aumenta la potencia individual. El escalado automático solo puede elegirse si está incluido en el plan.
Guardar registra una preferencia, no una migración: el proyecto en marcha no se mueve en ese momento. Si el servidor principal falla, un vigilante enciende la réplica de failover en la otra región (EE. UU. ↔ Alemania) en segundos, sin que tengas que hacer nada. Brasil no aparece como lugar de ejecución porque es solo caché CDN.
Protección ante fallos, balanceo y escalado automático son objetivos distintos. La recuperación depende de copias saludables, entrada de tráfico y servicios de datos disponibles. La aplicación necesita sesiones compartidas, archivos en S3 y tareas coordinadas; las réplicas de aplicación no replican automáticamente la base.

## Consumo de CPU, memoria y revisión de recursos
https://devoracloud.com/docs/recursos?lang=es

El panel muestra el porcentaje de la cuota de la aplicación, no el uso total del servidor. En una aplicación de 0,5 vCPU, 100 % significa que esa cuota está ocupada, no que toda la máquina esté al límite.
La tarjeta roja y la campana muestran avisos de CPU y memoria. El aviso requiere al menos tres minutos por encima del 85 %, con muestras recientes y continuas. Al 100 % es crítico. Los datos antiguos o ausentes no se muestran como consumo cero.
El aviso permanece mientras la condición esté activa y desaparece al normalizarse. El gráfico utiliza el historial medido cuando existe. El tráfico, tareas exigentes o problemas de código pueden causar consumo alto; revisa los logs antes de contratar recursos.
Revisar recursos abre la configuración. Consultar planes abre facturación. El aviso no activa réplicas, cambia CPU/RAM ni confirma una compra. Los adicionales por hora están en preparación y no se cobran automáticamente en esta versión.
CPU, memoria, almacenamiento local y S3 son recursos distintos. Guarda imágenes y vídeos en S3; el disco local no se comparte entre réplicas. La frecuencia real del colector determina la actualización de las lecturas.

## Preparar tu aplicación
https://devoracloud.com/docs/preparar?lang=es

1. Lee el puerto de process.env.PORT: No fijes el puerto en el código. Escucha en 0.0.0.0, nunca en localhost. Si se ignora: El enrutador entrega en el puerto declarado y nadie responde. El visitante recibe un 502 con el contenedor sano.
2. Ejecuta las migraciones al iniciar, no durante el build: Un migrate deploy antes de arrancar el servidor. Mientras se construye la imagen no hay base de datos a la que conectarse. Si se ignora: La base queda con cero tablas y la app da error en la primera consulta. Fue el fallo más común en las migraciones reales.
3. Falla de forma visible cuando falle la migración: Si el migrate da error, el proceso debe terminar con el mensaje en el log, no arrancar de todos modos. Si se ignora: La app sigue en línea sirviendo errores, el panel se ve en verde y nadie lo nota hasta que un cliente se queja.
4. Las variables NEXT_PUBLIC_* son argumentos de build: En Next.js se graban dentro del paquete durante el build. Declara cada una como ARG y promuévela a ENV antes de la línea que construye. Si se ignora: El valor de desarrollo queda incrustado para siempre. La web de producción sigue apuntando a localhost.
5. Nada importante en el disco del contenedor: Subidas, imágenes, adjuntos: envíalos al almacenamiento S3. El disco del contenedor desaparece cuando se recrea la copia. Si se ignora: Los archivos desaparecen en la siguiente publicación, sin aviso y sin forma de recuperarlos.
6. No guardes estado solo en la memoria del proceso: Sesión, cola, caché compartida: ponlas en la base de datos o en Redis. Con más de una copia, cada proceso tiene su propia memoria. Si se ignora: El usuario pierde la sesión cada vez que una petición cae en otra copia, y las escrituras desaparecen sin ningún error.
7. Un planificador integrado exige una sola copia: Si la app tiene un cron interno, díselo a quien vaya a publicarla. La alternativa es mover la tarea a un servicio propio. Si se ignora: Cobros duplicados, mensajes enviados dos veces, clientes bloqueados por error.
8. Responde algo en /: Cualquier respuesta por debajo de 500 sirve, incluso una redirección al login. Así sabe la plataforma que la app está viva. Si se ignora: La app se considera caída y el dueño recibe un aviso de caída que no existe.
9. Logs en stdout, sin archivo: Escribe en la salida estándar. No abras un archivo de log dentro del contenedor. Si se ignora: El log queda atrapado en un disco al que nadie llega, justo cuando lo necesitas.
10. Todo secreto viene del entorno: Clave de API, secreto de token, credencial de terceros: solo desde variables de entorno. Nunca en el repositorio, nunca con un valor por defecto que funcione. Si se ignora: El secreto se filtra en el repositorio y sirve para cualquiera que clone el código.
11. Monorepo: un servicio por programa, en el mismo proyecto: La web y la API del mismo repositorio entran como dos servicios del mismo proyecto, cada uno con su Dockerfile y su puerto. No crees dos proyectos. Si se ignora: Con dos proyectos, los secretos hay que copiarlos a mano de uno a otro, y el día en que se cambia uno y no el otro, el token deja de aceptarse y nadie entiende por qué.
12. Dockerfile: indica la ruta y deja el contexto en la raíz: En un monorepo, indica la ruta completa del Dockerfile del servicio. El contexto sigue en la raíz para encontrar el lockfile compartido. Si se ignora: El build muere con "open Dockerfile: no such file or directory" en un repositorio que sí tiene Dockerfile.

## Limitaciones actuales
https://devoracloud.com/docs/limites?lang=es

- Copias de seguridad automáticas de MySQL, MariaDB y MongoDB. Solo PostgreSQL las tiene (y solo en planes con backup). Para los demás, activa el acceso externo de la base y genera el dump desde tu equipo.
- Terminal SQL y cambio de contraseña de la base. Puedes ver las credenciales, pero no cambiarlas desde el panel.
- Tareas programadas (cron) por proyecto. Si tu app tiene una rutina programada, debe estar dentro de ella, y entonces debe ejecutarse con una sola copia; si no, la rutina se ejecuta dos veces.
- Un volumen montado en más de un servicio del mismo proyecto. El volumen va al servicio principal; montar el mismo volumen en dos servicios en máquinas distintas del clúster no funciona.
- Borrar los datos de dentro de un volumen desde el panel. Quitar el volumen deshace el montaje; el contenido sigue en el clúster.
- Elegir a mano un certificado TLS. La plataforma emite y renueva los certificados; las rutas por dominio se definen en la configuración de la dirección.
- Métricas de disco por proyecto y número de peticiones por dominio. CPU, memoria y tráfico de red RX/TX por proyecto están en el inspector.
- Alertas de infraestructura por correo. Una caída de la aplicación avisa por correo; un disco que se llena, todavía no.