CLI

zenavo despliega y opera tus proyectos desde un terminal o desde CI. Se comunica con la API REST mediante una clave de API, y sus comandos siguen los de la CLI de Zeabur (auth, workspace, context, project, service, deployment), así que el cambio es sencillo.

Instalación

Compílala desde el repositorio zenavo-cli con Go 1.26 o posterior:

make build            # ./zenavo para esta máquina
make dist             # dist/zenavo_<os>_<arch> para macOS, Linux y Windows, con SHA256SUMS

Iniciar sesión

zenavo auth login                          # muestra un código y abre <console>/device
zenavo auth login --scope deploy           # pide una clave que puede desplegar pero no hacerlo todo
zenavo auth login --with-token < key.txt   # una clave de API existente, leída de stdin
zenavo auth status                         # con quién has iniciado sesión y qué puede hacer la clave

auth login muestra un código y abre la página /device de la consola: inicia sesión, escribe el código y apruébalo. Comprueba el nombre del dispositivo y la red que muestra la página antes de aprobar. Por SSH, abre la dirección que se imprime en cualquier dispositivo. La CLI recibe entonces su propia clave de API, llamada "CLI on <computer>" y válida durante 90 días. En la página de aprobación puedes bajar su permiso y limitarla a algunos proyectos.

--scope elige el permiso que pide la CLI: read (Read only), deploy (Deploy) o full (Full access, el valor por defecto). Pide lo mínimo que necesites, sobre todo en máquinas compartidas. Quien aprueba aún puede bajarlo o limitarlo a algunos proyectos, nunca subirlo. La CLI guarda lo que se aprobó, y zenavo auth status lo muestra:

https://zenavo.app as dev@example.com (saved key)
Access: deploy (deploy and configure existing projects), limited to 1 project(s): proj_…

Cuando un comando necesita más de lo que puede hacer la clave, la API responde 403 y la CLI explica qué hacer: volver a iniciar sesión con un alcance mayor (zenavo auth login --scope full), aprobar la clave para todos los proyectos o, para lo que ninguna clave de API puede hacer (facturación, miembros, la cuenta), usar la consola. Con --with-token, el permiso de la clave se eligió al crearla, así que auth status no puede mostrarlo; --scope no se aplica.

La clave se guarda en ~/.config/zenavo/config.json (o $ZENAVO_CONFIG) con modo 0600, y solo se envía a la consola para la que se creó. auth logout la olvida en local; elimínala en API Keys para revocarla.

CI y scripts

Define ZENAVO_TOKEN con una clave de API (y ZENAVO_API_URL cuando no sea https://zenavo.app) en lugar de iniciar sesión, y pasa -i=false para que ningún comando pregunte. --json imprime JSON en stdout para jq; el progreso va a stderr. Una tarea seguida que falla sale con estado 1.

export ZENAVO_TOKEN=zv_pat_…
zenavo deploy web -p blog -i=false

Contexto

zenavo team switch y zenavo context set project|service guardan el equipo, el proyecto y el servicio que usarán los comandos siguientes. --team (o --workspace), --project/-p y --service/-s los sustituyen en un solo comando. Sin un proyecto o servicio guardado o indicado, la CLI usa el único que haya, pregunta cuando puede y, si no, indica qué pasar.

Recorrido rápido

zenavo team ls                                # tus equipos; * marca el actual
zenavo team switch acme
zenavo project create blog --git https://github.com/acme/blog
zenavo env set PORT=3000 DATABASE_PASSWORD    # una KEY sola pide el valor sin mostrarlo
zenavo deploy                                 # todos los servicios; sigue el registro de compilación
zenavo deploy web                             # un servicio; los demás quedan como están
zenavo service ls                             # estado, disponibilidad, reinicios, CPU y memoria
zenavo logs web -f                            # registros de ejecución en directo
zenavo logs --build                           # el último registro de compilación y despliegue
zenavo domain add blog                        # blog.zenavo.app, o un dominio completo tuyo
zenavo rollback                               # elige un despliegue anterior correcto
zenavo template deploy -f zeabur.yaml --var DOMAIN=blog

Comandos

Comando	Qué hace
auth login | logout | status	Inicia sesión por el navegador o con una clave de API; olvida la clave; muestra quién eres
team ls | current | switch | clear	Equipos (alias workspace). Cambiar de equipo borra el proyecto y el servicio guardados
context show | set project | set service | clear	Los valores por defecto que usan los comandos siguientes
server ls | get	Los servidores del equipo. Los servidores se añaden en la consola
project ls | get | create | delete	Proyectos. create --git <url> o --image <image> añade un primer servicio; delete te pide escribir el nombre
service ls | deploy | restart | suspend | resume | exec	Servicios. exec -- <command> se ejecuta en el contenedor con sh -c, hasta 60 segundos
deploy [service] [--dir <path>]	Despliega el proyecto o un servicio y sigue la compilación. --dir sube un directorio local como origen del servicio y crea el servicio si hace falta. --detach vuelve al momento
logs [service] [-f] [--build]	Las últimas 200 líneas de registro de ejecución, en directo con -f; --build imprime el último registro de compilación
shell [service]	Un terminal interactivo (bash o sh) en el contenedor del servicio; sale con el estado del shell
job ls | get | log | wait	Tareas: despliegues, reinicios, copias de seguridad (alias deployment)
rollback [job-id]	Revierte el proyecto a un despliegue anterior correcto
env ls | set | unset	Variables de un servicio. Los valores quedan ocultos salvo con --reveal; set --file .env; --deploy despliega tras guardar
domain ls | add | rm	Un nombre sin puntos (blog) recibe un dominio generado; un nombre completo es tu propio dominio
template deploy -f <file>	Crea un proyecto a partir de una plantilla de Zeabur (YAML) o una exportación de Zenavo (JSON); --var KEY=value, --deploy
backup ls | create	Copias de seguridad. create --engine postgres|mysql|volume:<id>. Descárgalas y restáuralas en la consola
version	La versión de la CLI

Todos los comandos aceptan --help. Opciones globales: --team (--workspace), --project/-p, --service/-s, --json, --yes/-y, -i=false y --api.

Lo que aún no está en la CLI

Añadir y configurar servidores, la gestión del equipo, la GitHub App, y descargar o restaurar copias de seguridad se hacen en la consola.