Cómo crear y alojar pequeñas apps internas con Custom App de osFoundry

Es jueves, faltan dos horas para un release y Dari es la única persona que sabe qué pasos del cutover ya están hechos. El checklist vive en una pestaña de una hoja de cálculo, el runbook en una unidad compartida y la discusión en un hilo de chat que nadie encuentra. Lo que el equipo necesita de verdad es una app diminuta con cuatro casillas y dos responsables, justo al lado de los archivos. Escribirla es fácil. Alojarla, darle una base de datos, guardar sus claves de forma segura y conseguirle una URL es la parte que suele atascarse.

Qué es la categoría Custom App

osFoundry agrupa todo lo necesario para crear y ejecutar tus propias apps pequeñas en una sola categoría de la barra lateral de la app de escritorio, llamada CUSTOM APP. Tiene cinco pantallas. Room es el espacio compartido donde las apps viven como pestañas. App Code es el repositorio que hay detrás de una app. Deployed Apps es la lista, a nivel de todo el workspace, de lo que está en producción. Snippets reúne las apps diminutas que nunca necesitaron un repositorio. Domains gestiona las direcciones web desde las que se sirven esas apps. Si conoces Notion, imagina una página cuyas pestañas son apps que funcionan en lugar de documentos, con una pequeña capa de hosting al estilo de Vercel por debajo: cada app tiene su propia base de datos, sus secretos, sus tareas programadas y un subdominio, tal como se describe en la página de la función de apps internas.

Un vistazo a la pantalla de construcción

La forma más rápida de ver cómo nace una app es la vista de construcción de la app de escritorio. Esta captura es del constructor de Websites (proyecto de ejemplo "Hearth Bakery"), que usa el mismo ciclo de describir y construir que ofrece una Room con su cuadro "Describe the app you want".

• Pages, a la izquierda: las partes de la app que ya existen, con Add page abajo.
• La vista previa, en el centro: lo que estás construyendo, con tamaños de escritorio, tablet y móvil encima. La etiqueta "On this computer" indica que todavía no se ha publicado nada.
• El cuadro de descripción: escribes qué hace la app, para quién es y qué sensación debe transmitir, y pulsas Build my site. Maestro, el asistente de IA de la app, escribe los archivos.
• El panel de Maestro, a la derecha: la conversación que construye y modifica la app. Use a folder le indica que use tu propio material en lugar de dejar que adivine.
• Publish needs credits, arriba: construir y previsualizar ocurre en tu ordenador; el hosting es el paso que consume créditos del workspace.

Dentro de una Room la idea es la misma con otra disposición: una tira de pestañas de apps arriba, la app seleccionada en el centro y un panel derecho con dos pestañas, Maestro y Details.

Caso de uso 1: un equipo de release tiene su checklist donde está el trabajo

Quiénes: una release manager y tres compañeros preparando un lanzamiento.

La situación: los pasos del cutover, el runbook y el tracker del release están repartidos en tres herramientas, y el día del release nadie se fía de la hoja de cálculo.

Qué hacen en osFoundry:

1. Crean una room llamada "Launch Ops" con New Room y añaden el tracker del release y los archivos del lanzamiento como pestañas.
2. Pulsan el botón + de la tira de pestañas. El selector New Tab lista las apps instaladas y un catálogo (Incident log, Retro board, On-call rota, Changelog builder), filtrable por All, Forked o Snippets.
3. En "Describe the app you want" hacen clic en Build a snippet y piden un checklist de cutover con un responsable por tarea. Un snippet es una mini-app ejecutable formada por unos pocos archivos. No tiene repositorio, ni versión, ni deploy, y se ejecuta ahí mismo, en la pestaña.
4. Siguen hablando con Maestro en el panel derecho mientras el checklist está abierto, y usan la pestaña Details para ver qué es la room y qué ha pasado en ella.

Con qué terminan: una sola room donde el checklist (en la demo: Freeze the 2.4 branch, Run the order-index migration, Smoke-test the order desk, Post the release note) está junto al runbook y al tracker. Más adelante, la pantalla Snippets lista todos los snippets de todas las rooms. Desde ahí alguien puede exportar uno como JSON con Export para otro workspace, o convertirlo en un repositorio de verdad con Promote cuando se le quede pequeña la pestaña.

Caso de uso 2: un desarrollador le da un backend real a una herramienta interna

Quién: un desarrollador en solitario que construye una herramienta de altas y pedidos para el equipo de soporte.

La situación: la primera versión corría en un portátil con un archivo SQLite. Ahora la necesitan tres equipos, tiene que llamar a una API de pagos y hay una limpieza nocturna que debe ejecutarse sin que nadie tenga que acordarse de pulsar un botón.

Qué hace en osFoundry:

1. Mientras la app todavía corre en local, abre el proyecto en el IDE y hace clic en la pestaña Database. Encuentra los archivos .db y .sqlite de la app y abre una tabla en solo lectura, 200 filas por página (datos de ejemplo arriba), para que veas qué guardó realmente la app antes de mover nada.
2. Mueve la app a una room compartida. El diálogo Move to cloud copia la app a una Cloud room para que todos sus miembros puedan usarla, e informa de qué tablas se copiaron y cuáles se quedaron en el dispositivo. La app y sus datos siguen también en este dispositivo.
3. Abre la configuración de la pestaña de la app. En Secrets, App Runtime Secrets lista las claves que declara la app; Add a custom secret guarda una nueva y Rotate reemplaza un valor. La app muestra entonces "Secrets updated. Redeploy to apply changes."
4. Declara la limpieza en container.cron dentro del manifiesto de la app, abre Scheduled jobs y hace clic en Sync from manifest. Cada tarea se puede pausar, reanudar o lanzar una vez con Run now.

Con qué termina: una app con su propia base de datos Postgres. En osFoundry cada Room App tiene una, con pgvector y TimescaleDB instalados, y la cadena de conexión llega como secreto en tiempo de ejecución (Postgres por app). El explorador de la base de datos tiene un editor de filas con filtros y una vista SQL solo para SELECT, y Database snapshots ofrece New snapshot, Restore y un enlace de descarga. Los cambios de código se hacen en App Code, donde el desarrollador puede trabajar en una versión como version/2.4 sin tocar main, revisar el Manifest (punto de entrada, visibilidad, conectores requeridos) y seguir el árbol de Versions antes de publicar.

Caso de uso 3: la dueña de una tienda publica una página y la tiene vigilada

Quién: alguien que lleva una pequeña panadería y no programa.

La situación: quiere una web sencilla con la carta y el horario, en su propia dirección, y quiere saber cuánto cuesta mantenerla en línea.

Qué hace en osFoundry:

1. Abre Websites, pulsa New Website, describe la panadería y pulsa Build my site. La primera versión (arriba, de ejemplo) usa textos de relleno, y Maestro lo dice claramente.
2. Pulsa Use a folder, elige la carpeta con la carta y las fotos reales y pide cambios con palabras normales, como "Make the headline bigger."
3. Cuando queda bien, la publica. El hosting usa créditos del workspace. Who can open it ofrece Workspace members only, Anyone with the link o el inicio de sesión propio de la app; una web pública de panadería usa Anyone with the link.
4. En Domains registra un dominio o añade uno que ya tiene, y edita sus registros DNS. Events muestra quién cambió cada registro, y Settings contiene la renovación, la privacidad y el código de transferencia.

Con qué termina: una web con sus propios textos y fotos, servida en su propio dominio. Deployed Apps responde luego a las preguntas que de verdad se hace una dueña. Apps muestra cada app y dónde se sirve, Activity muestra qué ha cambiado, Usage muestra el coste de build y almacenamiento por app, y Previews lista las versiones de vista previa que siguen en marcha.

Cómo encaja con el resto de osFoundry

Custom App casi nunca trabaja sola. Maestro es el asistente del panel derecho de cada Room y de las vistas de construcción; escribe y edita el código contigo. El IDE te da la pestaña Database, el control de versiones y el editor para las apps que empiezan como una carpeta en tu ordenador. Websites es un camino más rápido cuando la "app" es en realidad una web pública. Los Snippets solo se conectan con App Code a través de Promote, así que una herramienta de usar y tirar puede convertirse en un repositorio mantenido sin reescribirla. El trabajo programado dentro de una app lo cubren los cron jobs de app, descritos en la página de la plataforma sobre app cron.

Preguntas que hace quien empieza

¿Una Room es una sala de chat?
No. El núcleo de una Room son sus pestañas de apps. El chat de Maestro está en el panel de acompañamiento de la derecha, junto a los Details de la room.

¿Cuándo conviene crear un snippet en lugar de una app?
Cuando la herramienta son unos pocos archivos y solo tiene que funcionar dentro de una room, como un formateador de fechas o una comprobación de webhooks. Guardar un snippet no instala nada ni despliega nada. Si más adelante necesita versiones, secretos o una base de datos, conviértelo en repositorio con Promote.

¿Pueden dos apps compartir una base de datos?
Cada app tiene su propio Postgres. Compartir pasa por permisos explícitos: la pestaña Database de la room muestra Incoming Requests, Active Grants y Outgoing Access, y cada solicitud se puede aprobar o rechazar.

¿Cuesta algo probarlo?
Construir y previsualizar en tu ordenador no necesita créditos. Publicar, desplegar y registrar dominios usa créditos del workspace. Puedes descargar la app de escritorio en osfoundry.io/es/download.