Referencia

Solución de problemas

Ordenados, más o menos, de más a menos frecuente.

La consola dice que el acceso está restringido

Tu cuenta de GitHub no es miembro activo de ninguna organización de Codara Cloud ni tiene una invitación que coincida.

Pide a una persona propietaria o administradora de la organización que invite al correo verificado que aparece en tu cuenta de GitHub y abre el enlace de un solo uso que te envíe.
Si formas parte del equipo de Codara, confirma que tu pertenencia al equipo platform-users está activa. Ser miembro de la organización de GitHub no basta.
Un enlace caducado, revocado, ya usado o dirigido a otra dirección no se puede reutilizar; pide una invitación nueva.

Consulta Obtener acceso.

Google me lleva a la pantalla de «sin organización»

Google te ha verificado correctamente, pero esa identidad de Google todavía no está conectada a tu cuenta actual, vinculada a GitHub. Cierra sesión, inicia sesión con GitHub y abre Cuenta y organización → Cuenta → Conectar Google. No cuentes con que ambos proveedores devuelvan el mismo correo: Codara, a propósito, no fusiona cuentas solo porque coincida el texto del correo.

La consola parece tener la sesión iniciada, pero todo está vacío

Lo más probable es que tu sesión haya caducado: las sesiones duran 7 días. Cierra sesión y vuelve a entrar.

Mi app se creó, pero nunca arrancó

Si creaste la app en cualquier sitio que no sea el asistente de deploy de la consola, no se lanzó ningún build y la app apunta a una imagen provisional. Lanza el primer build:

bash

$ codaracloud deploy my-api --source

Mi deploy no hizo nada

codaracloud deploy <app> sin flags reinicia la imagen actual; no hace ningún build. Pasa --source, --branch o --commit.

Hago push a GitHub y no se despliega

Revisa estos puntos por orden:

¿Está instalada la GitHub App en el propietario del repositorio? Instálala en github.com/apps/codara-cloud.
¿Has hecho push a la rama que sigue la app? Revisa la rama configurada en la app.
¿Están activados los deploys automáticos? Se pueden desactivar en cada app.
¿El push tocó alguna ruta vigilada? Si no, se registra como un deploy omitido (skipped); búscalo en la lista de deploys.
¿Ha llegado la organización a un límite del plan? Cada plan incluye un número de builds iniciados al mes, y los builds fallidos cuentan; cuando se agotan, no se pueden iniciar builds hasta el mes siguiente. Una suscripción cancelada o vencida no permite nuevos deploys y pausa las cargas de trabajo en marcha.

El build ha fallado

«Could not detect a build strategy»

No se encontró nada reconocible en la raíz del build. Añade un Dockerfile o comprueba que el directorio raíz apunta donde crees.

La detección del Dockerfile distingue mayúsculas y minúsculas

Solo se detecta un archivo que se llame exactamente Dockerfile en la raíz del build. Un dockerfile en minúsculas, o uno dentro de un subdirectorio, se ignora; en ese caso, indica la ruta del Dockerfile de forma explícita.

Se ejecutó el builder equivocado

El orden de detección es Dockerfile, luego nixpacks.toml, luego Railpack y, por último, archivos estáticos. Nixpacks hay que pedirlo expresamente: sin ese archivo, un repositorio de Node o Python va a Railpack.

Faltaba una variable de entorno durante el build

Las variables de entorno son solo de ejecución y el build no las ve, a propósito. Si tu build de verdad necesita un valor público, guárdalo en el repositorio, en un archivo que tu framework lea durante el build (en Next.js, .env.production), o haz el build con tu propio Dockerfile y pásalo como argumento de build. Los argumentos de build no llegan a los builds con Railpack, Nixpacks o de sitios estáticos. Nunca pongas un secreto en ninguno de los dos. Consulta Build y deploy.

Se agotó el tiempo del build

Los builds tienen un límite de 30 minutos. Reduce el trabajo del build: mejor caché de capas, un contexto más pequeño y menos dependencias compiladas desde el código fuente.

El build salió bien, pero la app no está en marcha

Que el build salga bien solo significa que la imagen existe. Si el rollout nunca llegó a estar sano, la release se marca como fallida y tu versión anterior sigue sirviendo tráfico.

Puerto equivocado. Es la causa más habitual. Codara envía el tráfico al puerto 8080 salvo que le indiques otro, e inyecta el puerto como PORT. Escucha en ese puerto, y en 0.0.0.0 en lugar de 127.0.0.1: un contenedor que solo escucha en loopback es inalcanzable.
Fallo al arrancar. Revisa los logs. La salida de un contenedor que ya se reemplazó está en Logs → Historial.
Health check que falla. Si la ruta que configuraste no devuelve un estado de éxito, el pod nunca pasa a estar listo.
Un contador de reinicios que no para de subir en la pestaña Métricas confirma un bucle de fallos.

Mi dominio propio no funciona

Para un hostname que debería funcionar:

Revisa el estado del DNS y del certificado en la pestaña Dominios de la app. La CLI no lo muestra.
Confirma que el CNAME apunta a customers.codara.cloud y que ya se ha propagado.
En un dominio externo, confirma que está publicado el registro TXT _codara-verify que te muestra Codara. Cuando la verificación sale bien, cert-manager solicita el certificado TLS automáticamente; no hace falta ningún dominio de Codara.
Un estado unknown suele ser una consulta DNS lenta más que un fallo; vuelve a comprobarlo en un momento.

Una app dormida no se despierta

Hay tres situaciones en las que una petición no la despierta:

La petición llegó a un dominio propio. Solo una petición a la dirección codara.cloud de la app la despierta. Deja un servicio con dominio propio en Siempre activo.
La petición venía de otra app, por la red interna. El tráfico privado no pasa por la capa que despierta las apps, así que una dependencia privada no debe dormirse.
Su entorno está en pausa, o Codara lo ha suspendido (por ejemplo, por superar un límite de gasto).

Despiértala a mano con codaracloud apps wake <app>.

No encuentro mis logs

Los logs en directo solo muestran lo que todavía guardan los contenedores en marcha. La salida de contenedores anteriores, entre reinicios y deploys, está en Logs → Historial durante el tiempo que la conserve tu plan: 1 día en Starter, 7 días en Standard y 30 días en Pro y Scale. Los logs de build se eliminan a las 24 horas. Para conservar los logs más tiempo, envíalos a tu propio servicio desde dentro de la app. Consulta Logs y métricas.

Las métricas no se remontan lo suficiente

Puedes ver las métricas de, como mucho, los últimos 30 días: 30d es la ventana más larga que puedes pedir.

Se rechazan los deploys

Un 402 significa que el plan de la organización no permite la petición. El cuerpo del error explica por qué:

plan_limit_exceeded indica el límite, con el valor permitido y el actual. Elimina los recursos que ya no necesites o elige un plan mayor en Cuenta y organización → Facturación y uso.
subscription_not_active significa que la suscripción o la prueba gratuita ha terminado, o que hay un pago vencido. Mientras haya un pago vencido, la creación de recursos se rechaza de inmediato; los deploys y el despertar de servicios siguen funcionando durante 14 días.

Llegar a un límite del plan nunca detiene lo que ya está en marcha; una suscripción terminada sí lo pausa. Consulta Planes y capacidad.

«Refusing to guess» al crear una app o un job

El espacio de trabajo tiene más de un proyecto y no has dicho cuál usar. Es a propósito: Codara no coloca un servicio en un proyecto por ti, porque así es como acaban amontonados en un mismo espacio de trabajo servicios que no tienen nada que ver.

O indicas el proyecto:

bash

$ codaracloud projects list --client my-workspace$ codaracloud apps create my-api --client my-workspace --project storefront --repo my-org/api

…o, lo que suele ser más acertado, creas un proyecto para él. Un proyecto suele ser un producto con su propio repositorio.

El error relacionado no_workspace significa que el espacio de trabajo todavía no tiene ningún proyecto: crea uno antes de añadir servicios.

Un comando dice que el nombre de mi app es ambiguo

El mismo nombre existe en más de un proyecto o entorno. Indica el ámbito de forma explícita cuando el comando lo permita. Ten en cuenta que env, domains, logs, metrics y apps get no aceptan ningún flag de ámbito y siempre usan tu espacio de trabajo por defecto y production. Para esos casos, usa la consola.

«namespace too long» al crear una app

Los slugs del espacio de trabajo, el proyecto y el entorno se combinan y el total no puede pasar de 63 caracteres. El error indica cuál hay que acortar. Los slugs no se pueden renombrar sin romper las URL, así que normalmente esto es motivo para crear un proyecto nuevo con un nombre más corto.

Un token ha dejado de funcionar

Comprueba que no ha pasado su fecha de caducidad.
Comprueba que sus scopes cubren lo que estás llamando: un 403 indica el scope que hacía falta.
Un token creado sin scopes solo puede acceder a /v1/me.
Un token vinculado a un espacio de trabajo no puede tocar los recursos de otro.
Si se creó en la consola y necesitas db:connect o scopes de buckets, vuelve a crearlo con la CLI: la lista de la consola no los incluye.

¿Sigues sin resolverlo?

Ten a mano el nombre de la app, el espacio de trabajo, el ID del deploy y el error exacto. Si falló un build, copia su salida antes de que caduque: a las 24 horas desaparece y el fallo es mucho más difícil de diagnosticar.

Última actualización: 26 de septiembre de 2026