Cómo usar voar

1. Abre la página de la app en GitHub y elige tu organización. Las cuentas personales todavía no funcionan.

   Instalar voar en GitHub

2. Elige qué repositorios pueden usar voar: todos o solo algunos. Puedes cambiarlo después en la configuración de la app en GitHub.

3. En el flujo de trabajo, cambia el runs-on del trabajo por una etiqueta de voar:

   name: CIon: push jobs:  test:    runs-on: voar-2vcpu-ubuntu-2404    steps:      - uses: actions/checkout@v7      - run: npm ci      - run: npm test

   Copiar

4. Haz un push. Después, entra al panel con tu cuenta de GitHub: la página de trabajos muestra cada trabajo, su máquina, cuánto tardó y cuánto costó.

   Abrir el panel

La etiqueta le dice a voar qué máquina quiere el trabajo. Cada tamaño acepta la forma completa y las formas cortas.

• Usa una etiqueta de voar por trabajo.
• Junto a ella puedes poner self-hosted, linux y x64. Cualquier otra etiqueta en el mismo runs-on deja el trabajo esperando.
• Da igual si usas mayúsculas o minúsculas: GitHub compara las etiquetas sin distinguirlas.

Ubuntu 24.04 en x64, con sudo. Ya viene instalado:

• Docker, con Compose y Buildx
• sudo y git
• Node 22 y 24
• Bun
• Python 3
• GitHub CLI (gh)
• AWS CLI

No es la imagen completa de los runners de GitHub. Lo que falte, instálalo en el propio trabajo:

- run: sudo apt-get update && sudo apt-get install -y postgresql-client

Cada trabajo empieza en una máquina nueva. No queda nada del trabajo anterior.

La caché guarda archivos para que el próximo trabajo no tenga que descargarlos o generarlos otra vez. voar usa la caché de GitHub. Si tu flujo de trabajo ya tiene pasos con actions/cache, consérvalos.

Para npm, agrega estos pasos después de actions/checkout. El repositorio debe tener un package-lock.json:

- uses: actions/setup-node@v7  with:    node-version: '24'    cache: npm- run: npm ci

setup-node reutiliza los paquetes descargados, no la carpeta node_modules. Mantén el paso npm ci.

Capas de Docker

Para reutilizar capas entre compilaciones, usa la caché gha de Buildx. Agrega estos pasos después del checkout en un repositorio con Dockerfile:

- uses: docker/setup-buildx-action@v4- uses: docker/build-push-action@v7  with:    push: false    cache-from: type=gha,version=2    cache-to: type=gha,version=2,mode=max

GitHub almacena los archivos de caché. No están alojados en un servicio de voar en São Paulo. Los límites, las reglas de borrado y los cargos de almacenamiento son los que GitHub aplica a tu repositorio.

El primer trabajo guarda la caché. Si aparece Cache not found, deja que termine y ejecútalo de nuevo con la misma clave. Revisa también la ruta y el archivo de dependencias que usas en la clave. No guardes contraseñas ni tokens en la caché.

• Un trabajo puede correr hasta 6 horas. En ese momento la máquina se apaga.
• Solo organizaciones. Las cuentas personales todavía no funcionan.
• Solo Linux x64 (Ubuntu 24.04), en São Paulo (AWS sa-east-1).
• Hasta 2 trabajos a la vez antes de la primera compra, y 10 después. Para más, escribe a [email protected].

Repositorios públicos

Por defecto, solo los repositorios privados usan voar: el grupo de runners predeterminado de GitHub no atiende los públicos. Para habilitarlos, un admin de la organización abre Settings > Actions > Runner groups, entra al grupo Default y marca Allow public repositories.

En un repositorio público, un pull request de alguien de fuera del equipo puede hacer correr un trabajo en voar, y el costo sale de tu saldo. Antes de habilitarlos, revisa en la configuración de Actions de GitHub quién necesita aprobación para correr flujos de trabajo de forks.

La app de voar pide solo lo que necesita para crear runners y enterarse de los trabajos. No pide acceso al contenido de tus repositorios.

• Self-hosted runners (lectura y escritura), en la organización: para crear el runner de cada trabajo y quitarlo al final.
• Members (lectura): para saber quiénes son los admins de la organización.
• Actions (lectura): para recibir los eventos de los trabajos.
• Metadata (lectura): GitHub la pide junto con las demás.
• El correo de quien entra al panel: para los avisos de la cuenta, como el de saldo bajo.

• Cada trabajo se cobra por separado, redondeado hacia arriba al minuto entero, como hace GitHub. Un trabajo de 3 min 10 s cuenta 4 minutos.
• Las máquinas más grandes cuentan más minutos por minuto: en la de 4 vCPU cada minuto cuenta 2, y en la de 16 vCPU, 8.
• Cada organización recibe 3000 minutos gratis al mes, contados en la máquina de 2 vCPU. Vuelven a medianoche del día 1, hora de São Paulo.
• Después, cada trabajo descuenta del saldo. Agrega crédito desde el panel, en paquetes desde 10 €. No hay plan ni suscripción.
• La moneda queda fija con el primer pago de la organización: reales, dólares o euros.
• Sin saldo y sin minutos gratis, los trabajos esperan en la cola de GitHub hasta que agregues crédito. GitHub cancela el trabajo que espera más de 24 horas.
• Los owners y admins de la organización agregan crédito y cambian la configuración. Los miembros ven los trabajos y el saldo.

Ver los precios

Los owners y admins crean claves de API de la organización (voar_...) en la Configuración del panel. Cada organización puede tener hasta 10 claves activas, todas de solo lectura.

curl -H "Authorization: Bearer voar_..." https://api.voar.dev/v1/account

Endpoints y herramientas

• GET /v1/account (herramienta MCP get_account, permiso account:read): resumen de la organización, saldo, unidades gratis del mes y cuántas ya se usaron, límite de concurrencia, máquinas activas y trabajos en cola.
• GET /v1/jobs (herramienta MCP list_jobs, permiso jobs:read): últimos trabajos de la organización (limit de 1 a 100 y before en ISO 8601), con tamaño de máquina, duración, costo y el motivo si algún trabajo no arrancó.
• GET /v1/usage (herramienta MCP get_usage, permiso usage:read): trabajos terminados, unidades cobradas y costo pagado en el mes (month como AAAA-MM en America/Sao_Paulo), día por día. costMicros está en la moneda que devuelve get_account.
• GET /v1/openapi.json (o ?lang=pt-BR): especificación OpenAPI 3.1 pública.

Una unidad es un minuto en la máquina de 2 vCPU. Las máquinas de 4, 8 y 16 vCPU cuentan 2, 4 y 8 unidades por minuto. Los campos de dinero terminan en Micros: un millón de micros es 1,00 de la moneda.

Conectar por MCP

Apunta Claude, ChatGPT o Codex a https://api.voar.dev/mcp. La aplicación abre la pantalla de autorización de voar para que elijas la organización, y recibe su propia clave voar_.

En un agente de terminal sin navegador local, inicia el acceso por código (RFC 8628) y apruébalo en https://app.voar.dev/device:

curl -X POST https://api.voar.dev/oauth/device_authorization \  -d "client_id=voar-agent"

Cuando conectas una aplicación de IA a voar por OAuth o con un código de terminal, recibe una clave de API de solo lectura vinculada a la organización que elegiste.

• La aplicación solo lee el resumen de la organización (account:read), la lista de trabajos (jobs:read) y el consumo mensual (usage:read). No cambia límites, no compra paquetes de crédito y no crea otras claves.
• La app de voar en GitHub no tiene permiso para leer el contenido de tus repositorios, y lo que devuelve la API no incluye código fuente, logs de trabajos ni secretos de flujos de trabajo.
• Tus trabajos corren en las máquinas de voar. Mientras un trabajo corre, su máquina guarda el código y los secretos que usa tu flujo de trabajo, como en cualquier runner. Cuando el trabajo termina, la máquina y su disco se borran.
• Los datos de la tarjeta van a Stripe, no a voar.
• Cada aplicación conectada aparece en la lista de claves de API en la Configuración de la organización, donde cualquier owner o admin puede rotar o revocar la clave al instante.
• Si la persona que autorizó la aplicación sale de la organización en GitHub o deja de ser owner o admin, la clave deja de funcionar de inmediato.

Cambia el runs-on de vuelta a ubuntu-latest, o al runner de GitHub que usabas. Nada más cambia.

Para cambiar todos los flujos de trabajo a la vez, lee el runner de una variable de la organización:

runs-on: ${{ vars.CI_RUNNER || 'ubuntu-24.04' }}

Crea la variable CI_RUNNER en tu organización (Settings > Secrets and variables > Actions > Variables) con el valor voar-2vcpu-ubuntu-2404. Sin la variable, los trabajos corren en el ubuntu-24.04 de GitHub.

El trabajo se quedó en Queued

Abre la página de trabajos del panel. Dice por qué cada trabajo en espera todavía no tiene máquina. Los motivos posibles:

• La etiqueta está mal escrita, como voar-3vcpu. Revisa la tabla de etiquetas.
• El runs-on tiene otra etiqueta además de la de voar. Solo self-hosted, linux y x64 pueden ir con ella.
• Se acabaron el saldo y los minutos gratis del mes. Agrega crédito y el trabajo empieza.
• La organización ya tiene el máximo de trabajos a la vez. El trabajo espera su turno.
• voar no pudo arrancar la máquina. Vuelve a correr el trabajo. Si se repite, escribe a [email protected].
• La app se desinstaló o se suspendió en GitHub. Instala voar otra vez en la organización.

Si el repositorio es público, revisa también que el grupo de runners habilite repositorios públicos.

El trabajo ni aparece en el panel

La app no está instalada en ese repositorio. Agrégalo en la configuración de la app en GitHub y vuelve a correr el trabajo.