Primeros pasos
Despliega tu primera app
De un repositorio de GitHub a una URL HTTPS en marcha. La primera vez, cuenta con unos diez minutos, casi todos esperando al build inicial.
Antes de empezar
1. Instala la GitHub App
Codara lee tu código mediante una instalación de la GitHub App, no con tu cuenta personal. Instálala en la organización o el usuario propietario del repositorio:
Dale acceso a los repositorios que quieres desplegar. Si te saltas este paso, el primer build falla con un mensaje que te indica que la app no está instalada en la cuenta de ese propietario.
La instalación necesita estos permisos sobre el repositorio:
- Contents: solo lectura, para clonar tu código.
- Commit statuses: lectura y escritura, para que las releases informen de su estado en el commit.
- Pull requests: solo lectura, para los entornos de preview.
Las imágenes que se construyen van al registro de contenedores propio de Codara en la UE, no a GitHub, así que la GitHub App no necesita permisos sobre paquetes.
2. Crea tu primer proyecto
Al crear tu cuenta, Codara crea un espacio de trabajo cloud por defecto. Crea un proyecto dentro de él; el proyecto recibe automáticamente un entorno production listo para usar.
En la consola, elige Nuevo proyecto. Crea un espacio de trabajo adicional, que es opcional, solo si quieres un lugar aparte para un grupo de proyectos relacionados, con su propio acceso y su propio uso; los espacios de trabajo adicionales empiezan vacíos.
$ codaracloud projects create website \ --client my-workspace \ --name "Website"--client recibe el slug de tu espacio de trabajo; el flag conserva el nombre antiguo que la API usa para un espacio de trabajo.
Los slugs se convierten en nombres DNS: mantenlos cortos
3. Crea la app
Usa el asistente de deploy de la consola: Todos los servicios → Nuevo servicio. Recorre todo el proceso en una sola pantalla y es el único sitio que crea la app y lanza su primer build a la vez.
Elige dónde va a estar
Elige el espacio de trabajo, después el proyecto y después el entorno, que normalmente es production.
Da a cada producto nuevo su propio proyecto
Elige el origen
Selecciona Repositorio de GitHub y elige el repositorio y la rama. El asistente te muestra qué builder se va a ejecutar antes de que te comprometas a nada. También puedes desplegar una imagen de contenedor que ya tengas.
Define el puerto
Por defecto, Codara envía el tráfico al puerto 8080 e inyecta el puerto elegido en tu contenedor como PORT. Si tu app escucha en otro puerto, indícalo aquí, o lee PORT en tu código, que es lo más portable.
Añade las variables de entorno
Todo lo que tu app necesite en runtime. Si tu repositorio tiene un .env.example, el asistente te ofrece sus claves para que las rellenes. Son solo valores de runtime: no están disponibles durante el build, y es intencionado.
Despliega
Envía el formulario. La app se crea y el primer build entra en cola de inmediato.
Crear una app por otra vía no lanza el build
codaracloud deploy <app> --source o haciendo push a la rama.4. Sigue el build
La página de la release muestra los pasos (En cola, Inicio, Build, Push, Rollout y Activo) con la salida del build debajo, en directo. Un primer build suele tardar unos minutos; los siguientes son más rápidos porque las capas quedan en caché.
Codara elige la estrategia de build inspeccionando tu repositorio, en este orden:
| Si tu repositorio tiene | Codara usa |
|---|---|
| Dockerfile | Tu Dockerfile, tal cual está escrito. Tiene que llamarse Dockerfile y estar en la raíz del build, o indicarse de forma explícita. |
| nixpacks.toml | Nixpacks. Es opcional: solo se usa cuando existe este archivo. |
| Un lenguaje reconocido | Railpack, el buildpack por defecto. Detecta Node, Python, Go, Ruby, PHP, Java y otros a partir de sus archivos de manifiesto. |
| Solo archivos estáticos | Una imagen de nginx generada que sirve esos archivos. |
| Nada de lo anterior | El build falla y te indica que no ha podido detectar una estrategia. |
5. Abre tu app
Cuando la release pasa a estar activa, la app es accesible por HTTPS en su hostname gestionado, asociado al espacio de trabajo. La etiqueta exacta depende de si el entorno tiene un servicio o varios; por ejemplo:
https://<managed-label>-<workspace>.codara.cloudEl hostname exacto aparece en la página de la app, y codaracloud open <app> lo abre en tu navegador. Si prefieres usar tu propio dominio, consulta Dominios propios.
6. Haz push para desplegar
Los deploys automáticos están activados por defecto. A partir de aquí, cada push a la rama que elegiste hace el build y publica una versión nueva. Codara envía a GitHub un estado del commit con un enlace a la release.
$ git push origin main# → build starts automaticallyPara publicar sin hacer push, o para volver a hacer el build de una revisión concreta:
# Build the app's configured branch$ codaracloud deploy my-api --source # Build a specific branch or commit$ codaracloud deploy my-api --branch staging$ codaracloud deploy my-api --commit a1b2c3ddeploy sin flags no vuelve a hacer el build
codaracloud deploy <app> por sí solo se limita a reiniciar los pods con la imagen que ya está desplegada. Tienes que pasar --source, --branch o --commit para generar un build nuevo.Monorepos
Si tienes varias apps en un mismo repositorio, define un directorio raíz para que cada app haga el build desde su propio subdirectorio, y define unas rutas vigiladas para que un push solo vuelva a hacer el build de las apps que ha tocado de verdad. Un push que no coincide con ninguna ruta vigilada queda registrado como deploy omitido, en lugar de ignorarse sin avisar.
Siguientes pasos
- Conceptos básicos: el modelo que hay detrás de los espacios de trabajo, los proyectos y los entornos.
- Variables de entorno: configuración y secretos.
- Bases de datos: añade Postgres y conéctalo a tu app.
- Dominios propios: sirve tu app en tu propio dominio.
Última actualización: