Gestiona tu backend desde tu móvil Android

La producción se rompe y vas en el autobús. Un despliegue necesita un rollback, una variable de entorno está mal, y lo único que llevas en el bolsillo es un móvil, no un portátil con el panel de Vercel, la consola de Cloudflare y la pestaña de Sentry abiertos a la vez. La respuesta de siempre es "espera a llegar a casa". El Backend Manager de Pocket Code elimina esa espera: es un panel unificado para gestionar tu backend desde el móvil, conectado a las APIs reales de los proveedores y alojado dentro del propio IDE, junto a tu editor y tu terminal.

No es un catálogo de enlaces a paneles web. Habla directamente con los proveedores, guarda tus tokens en almacenamiento cifrado del dispositivo y adapta su interfaz exactamente a lo que la API de cada proveedor admite de verdad.

Tres hubs, trece proveedores

El Backend Manager divide todo lo que orbita alrededor de tu proyecto pero vive fuera del código en tres hubs independientes. Eliges uno en la pantalla de bienvenida y aterrizas directamente en su cuadrícula de proveedores.

Hub	Proveedores	La pregunta que responde
Deploy	Vercel, Render, Netlify, Railway, Fly.io, Cloudflare, DigitalOcean	"¿Dónde se ejecuta mi aplicación?"
BaaS	Firebase, Appwrite, Convex, Supabase	"¿Dónde están mis datos y dónde están mis usuarios?"
Observabilidad	Sentry, PostHog	"¿Está funcionando en producción?"

La navegación se basa en gestos: no hay pestañas visibles ni botón de retroceso en la cabecera. El gesto de retroceso te sube un nivel, luego te lleva de vuelta a la pantalla de bienvenida y, por último, cierra el panel.

Deploy: capacidades honestas para cada proveedor

Cada proveedor de hosting expone una porción distinta de su API, y el Backend Manager no finge lo contrario. En vez de mostrar botones en gris, oculta las acciones que un proveedor no puede realizar, de forma que nunca pulses algo que devuelva un "no soportado". Esta es la matriz que se ha publicado, verificada contra el código de dispatch real:

Capacidad	Vercel	Render	Netlify	Railway	Fly.io	Cloudflare	DigitalOcean
Listar proyectos / servicios	Sí	Sí	Sí	Sí	Sí	Pages	Apps
Lanzar despliegue	—	Sí	Sí	—	—	—	Sí
Rollback	Sí	Sí	Sí	Sí	—	Sí	Sí
Variables de entorno (leer + escribir/borrar)	Sí	Sí	Sí	Sí	—	—	—
Dominios personalizados	Sí	—	—	—	—	Zones	—
Escritura de configuración de build	Sí	Sí	—	—	—	—	—
Cancelar despliegue	Sí	—	—	—	—	—	—
Suspender / Reanudar	—	Sí	—	—	—	—	—
Servidores / VMs	—	—	—	—	Apps	—	Droplets

Así que puedes desplegar un backend en Android lanzando una build en Render, Netlify o DigitalOcean; promocionar o revertir en Vercel, Render, Netlify, Railway, Cloudflare o DigitalOcean; editar y borrar variables de entorno en Vercel, Render, Netlify o Railway; y suspender o reanudar un servicio de Render, todo desde el móvil.

Dos apuntes honestos. Crear un proyecto desde cero con el asistente de One-Click Deploy hoy solo resuelve para Vercel — el resto de proveedores aparecen en el asistente pero aún no están conectados a un endpoint real. Y los preview deploys y los deploys por rama/Git tienen sus pantallas hechas pero todavía no disparan; ese wiring es un follow-up, así que el manager mantiene esas acciones apartadas por ahora.

Por debajo, estos son los propios endpoints REST y GraphQL de los proveedores. Un rollback en Render, por ejemplo, llama a POST /v1/services/{id}/rollback; una promoción en Vercel va a POST /v10/projects/{id}/promote/{deploymentId}; las escrituras de variables de entorno en Railway ejecutan un variableUpsert de GraphQL. Borrar una variable de entorno siempre pide confirmación antes.

Ir más a fondo: sub-hubs de capacidades por proveedor

Tres proveedores ofrecen mucha más superficie que un flujo de despliegue básico, y el Backend Manager la expone mediante sub-hubs de capacidades que se cargan de forma perezosa y se cachean por sesión.

• Cloudflare — explora scripts de Workers, namespaces de KV, bases de datos D1, buckets de R2 y Zones. En la lista de Zones hay una acción integrada de Purgar caché (POST /zones/{id}/purge_cache). El ID de cuenta se resuelve automáticamente y se cachea durante la sesión.
• DigitalOcean — lista clústeres de Kubernetes, bases de datos gestionadas, volúmenes y firewalls, con los droplets accesibles a través de la ruta de Servidores.
• Railway — inspecciona los entornos y volúmenes de un proyecto (con alcance de proyecto, así que el estado se reinicia al cambiar de proyecto).

Todo esto se ejecuta bajo una única pantalla de lista reutilizable, y por eso el módulo puede ofrecer 21 vistas de capacidades distintas sin una interfaz a medida para cada una.

Backend como servicio: datos y usuarios

El hub de BaaS es donde vigilas tu stack de backend como servicio.

• Appwrite — lista tus proyectos y luego profundiza en los usuarios de un proyecto (GET /v1/users, autenticado con X-Appwrite-Key).
• Convex — lista tus equipos, introduce una URL de deployment y carga sus tablas mediante la consulta de sistema tables. También puedes ejecutar cualquier consulta de Convex contra el deployment en vivo y recibir el resultado resumido.
• Supabase — lista proyectos y luego profundiza en las tablas de un proyecto. El Backend Manager obtiene la clave anon del proyecto bajo demanda, llama al endpoint de esquema de PostgREST y extrae los nombres de las tablas del esquema public a partir de la definición OpenAPI. Esa clave anon nunca se persiste: vive solo en memoria durante lo que dura la llamada.

Una nota honesta: Firebase es hoy un placeholder de solo lectura. Listar proyectos de Firebase requiere un scope de OAuth que el módulo todavía no ha integrado, así que al seleccionarlo se muestra un mensaje informativo que te dirige a la Firebase Console en lugar de fingir que lista proyectos.

Observabilidad: ¿está funcionando de verdad?

• Sentry — lista todos los proyectos a los que tu token puede acceder y luego abre sus issues sin resolver, codificados por color según el nivel (fatal, error, warning, info, debug). Desde ahí puedes cargar de forma perezosa releases, reglas de alerta, replays y feedback de usuarios.
• PostHog — lista proyectos y sus insights, y luego profundiza en eventos, cohortes, experimentos, grabaciones de sesión, dashboards y anotaciones. El host de PostHog es configurable, así que el mismo cliente funciona para PostHog Cloud y para una instancia autoalojada, útil si te autoalojas desde el móvil y apuntas el manager a tu propio deployment.

Un generador de manifiestos de Kubernetes en el bolsillo

El hub de Deploy también incluye un generador de YAML de Kubernetes local. Rellenas un nombre de aplicación, imagen, número de réplicas, puertos, namespace, y las requests y limits de CPU/memoria, y genera un único documento YAML que contiene un Deployment y un Service a juego, listo para pegar en kubectl apply -f -. Es puramente un generador: no se conecta a un clúster, no aplica nada ni valida contra una API en vivo. Simplemente te ahorra escribir a mano el boilerplate en una pantalla táctil.

Tus tokens se quedan bloqueados en el dispositivo

Cada token de proveedor se guarda con SecureTokenStorage: EncryptedShared­Preferences respaldado por el Android Keystore, usando AES256-GCM para las claves y AES256-SIV para los valores. No se envía nada a nuestros servidores.

Antes de cualquier llamada a un proveedor, el Backend Manager comprueba si existe un token. Si no existe, hace cero llamadas a la API y en su lugar muestra un estado vacío "Conectar proveedor" con un botón para abrir las integraciones. Ese deep link está protegido por una barrera biométrica (BIOMETRIC_STRONG | DEVICE_CREDENTIAL), de modo que alguien con tu móvil desbloqueado no puede saltar desde el Backend Manager a tus claves de API guardadas sin autenticarse primero.

Qué es gratis y qué es Pro

La documentación es específica sobre las restricciones, así que nosotros también lo seremos. Algunas capacidades están detrás de una feature de plan:

Acción	Feature de plan
Abrir la pantalla de Dominios personalizados	CUSTOM_DOMAINS
Hacer Rollback de un despliegue	PREVIEW_DEPLOYS
Feature Flags de PostHog	COLLABORATION

En el plan gratuito, maxActiveDeploys es 1, así que lanzar un segundo despliegue concurrente (contando los despliegues que estén listos, construyendo o desplegando) es lo que activa la barrera de PREVIEW_DEPLOYS. Listar proyectos, leer variables de entorno, explorar los sub-hubs de Cloudflare y DigitalOcean, generar YAML de Kubernetes y ver los issues de Sentry y los insights de PostHog forman parte de la experiencia base.

Integrado en el IDE, no acoplado por encima

Como el Backend Manager vive dentro de Pocket Code, el asistente de IA puede comunicarse con él a través del bus de eventos de la aplicación. Pregúntale por un despliegue y puede lanzar uno, informar del estado del despliegue, resumir los despliegues recientes como líneas de log o listar tus proyectos a través de los hubs de Deploy y Observabilidad, todo basado en el estado que ya estás viendo.

---

Gestionar un backend solía significar un escritorio, un portátil y un puñado de pestañas del navegador. Ya no. Pocket Code pone el hosting, el BaaS y la observabilidad (trece proveedores, llamadas reales a la API, tokens cifrados) en la misma app donde escribes y publicas el código.

Pocket Code llegará pronto a Google Play. Apúntate al preregistro para estar entre los primeros en ejecutar tu backend desde el móvil.