Apps y bases de datos en ghosty.page

Tu agente publica apps completas (Express, Next, React Router…) en <slug>.ghosty.page. No necesitas cuenta de hosting ni llaves de nada: se lo pides en el chat y él la construye, la publica y te da la liga.

Publicar una app

El agente usa la tool site_publish (desde código, el SDK: publishSite({ title, app: { dir, repo? } })).

• Despliegue azul/verde. La versión nueva se construye aparte y sólo entra cuando quedó lista. Si el build falla, la versión anterior sigue sirviendo.
• Muchas apps por cuenta. Una cuenta puede tener varias apps y varios sitios. El agente los lista todos con site_status y todas: true.
• Respuesta con evidencia. site_publish regresa aplicado y verificado: el código HTTP y el <title> real leídos de la liga en vivo. El agente sólo dice «listo» con esa evidencia.

Con tu repo de GitHub

Con repo, el código vive en tu GitHub. Cada push a la rama principal del repo de esa app la vuelve a publicar en 1–3 minutos. En cualquier otro repo, el agente trabaja con rama y PR.

Estado real: site_status

site_status es la verdad de la plataforma sobre cada app:

• La caja de la app (2 vCPU / 2 GB) y si está despierta.
• El commit que se está sirviendo y el que se está construyendo («redeploy en curso»).
• El error completo del último build fallido (la versión anterior sigue sirviendo).
• La base de datos y sus tablas.
• Los nombres de las variables de entorno (nunca sus valores).
• La fecha de caducidad.
• Con log: true, además, la cola del log del build y del proceso.

Base de datos de cada app

Cada app tiene su propia base libSQL, app-<slug>:

• Llega a la app en DATABASE_URL y DATABASE_AUTH_TOKEN (también con los alias TURSO_*).
• Sobrevive a cada nueva publicación.
• Aparece en /app/dbs.
• El agente que publicó la app la lee y escribe con db_select y db_exec.

Checkpoints: regresar la base a un punto anterior

Antes de la primera escritura de cada turno en cualquier base, la plataforma guarda un checkpoint.

• db_checkpoints {base} lista los checkpoints: hora, motivo y cuántas filas tenía cada tabla.
• db_restore {base, checkpoint} regresa la base a ese punto, después de que tú lo apruebas.
• Restaurar guarda primero otro checkpoint, así que también se puede deshacer.
• Se guardan los últimos 30 por base o los de los últimos 14 días.
• Las bases muy grandes (más de 50 MB) no llevan checkpoint, y el agente te lo dice antes de escribir.

Ejemplo:

Tú: Carga en producción los 40 productos del catálogo que te pasé.

Agente: Listo: 40 filas nuevas en productos de app-tienda-luna. Antes de escribir quedó un checkpoint (12:04, 0 productos).

Tú: Me equivoqué de archivo, deshazlo.

Agente: Voy a regresar app-tienda-luna al checkpoint de las 12:04 (0 productos). ¿Lo apruebas?

Tú: Sí.

Agente: Hecho. productos vuelve a tener 0 filas. Guardé otro checkpoint antes de restaurar, por si quieres recuperar los 40.

También desde otros lados:

Variables de entorno

site_env (en el SDK, setSiteEnv(slug, { set, unset })) agrega o quita variables y reinicia la app sin volver a construirla. Se guardan cifradas y nunca van al repo.

Plan Gratis y Sitios fijos

Las apps siguen la misma regla que los sitios: en el plan Gratis se pausan a los 30 días sin cambios. Sitios fijos ($49 USD al año, incluye hasta 3 sitios) las mantiene publicadas. Detalle en Sitios.