Skip to main content
Usa Computación personalizada de InsForge para ejecutar contenedores de larga duración junto a tu proyecto: workers de cola, procesadores en segundo plano, bucles de inferencia de IA, servidores websocket, scrapers, cualquier proceso que deba permanecer activo.
¿Solo necesitas atender una petición? Usa Edge Functions para trabajo de petición/respuesta y tareas cortas. La Computación personalizada es para procesos que deben ejecutarse de forma continua.

​
Características

​
Despliegue de contenedores

Entrega cualquier imagen de Docker a InsForge y se ejecuta. Apunta a una imagen ya construida en un registry, o sube un contexto de construcción y deja que InsForge la construya desde tu Dockerfile. No hay que aprender ningún pipeline propietario.

​
Acceder a tu proyecto

Las credenciales que necesite tu contenedor las defines tú como variables de entorno del servicio: la URL del proyecto, una API key, credenciales de S3, lo que use esa carga de trabajo. InsForge no inyecta nada por ti, así que tú decides exactamente a qué puede llegar el contenedor. Cuando te autoalojas, los contenedores de compute se unen por defecto a la red del propio proyecto, de modo que postgres:5432 y postgrest:3000 se resuelven por nombre desde dentro del contenedor igual que en las edge functions, sin dar una vuelta por la red pública.

​
Recursos

La memoria y la CPU se configuran por servicio. Cada servicio ejecuta una instancia; crea varios servicios si necesitas varios workers.

​
Logs

Logs estructurados por contenedor, consultables por servicio y rango de tiempo. Míralos en el dashboard, la CLI o MCP sin hacer kubectl exec en nada.

​
Secretos y variables de entorno

Define variables de entorno y secretos por servicio, aparte de los secretos de tus edge functions. Rótalos sin volver a desplegar.
Todavía no hay volúmenes persistentes. El estado del contenedor sobrevive a los reinicios y al reinicio del host, pero cambiar la imagen, las variables de entorno o el puerto recrea el contenedor y descarta lo que se haya escrito dentro. Usa el Postgres o el Storage de tu proyecto para los datos que necesites conservar.

​
Autoalojamiento: activar compute

En InsForge Cloud, compute está totalmente gestionado y no configuras nada. Cuando te autoalojas, tú eliges dónde se ejecutan los contenedores. Hay dos proveedores disponibles y, hasta que configures uno, los endpoints de compute devuelven 503 COMPUTE_NOT_CONFIGURED.
Los contenedores se ejecutan en el mismo daemon de Docker que ejecuta InsForge, como hermanos del contenedor de InsForge. No hay que registrarse en nada, ni hay factura por contenedor.Activarlo es un acto deliberado: monta el socket de Docker en el contenedor de InsForge. En tu archivo compose, descomenta la línea que ya está ahí para esto:
Esa es toda la edición. El socket es 660 root:docker en Linux y root:root en Docker Desktop, y el id de grupo cambia según el host, así que el contenedor lo lee del propio socket al arrancar y se une a ese grupo antes de bajar al usuario de la aplicación. Nada que buscar y nada que configurar.Reinicia el stack. El driver se registra solo cuando el socket es accesible y escribe Compute provider "docker" ready.
El socket de Docker equivale a root en el host. Cualquiera que pueda alcanzarlo puede arrancar un contenedor que lea todo el sistema de archivos, así que montarlo es una decisión que hay que tomar de forma deliberada. InsForge construye la especificación de cada contenedor por su cuenta y nunca reenvía opciones suministradas por quien llama, así que una API key de InsForge filtrada no puede pedir un contenedor privilegiado ni un bind mount del host, pero el socket en sí sigue siendo tan poderoso como la cuenta que lo posee.
Ajustes opcionales:
Si configuras los dos, los servicios existentes se quedan con el proveedor que los creó y los nuevos van a Fly. Define COMPUTE_PROVIDER como fly, docker u off para ser explícito.

​
Elegir cómo se alcanza un servicio

Cada servicio elige un modo de ingress. Qué modos existen depende del proveedor, y el valor por defecto también: en un solo host es none, porque la mayor parte del compute —workers de cola, procesadores, bucles de inferencia— no recibe tráfico entrante en absoluto, mientras que Fly da un nombre de host a cada app y por eso solo ofrece host. Si omites el campo se aplica el valor por defecto del proveedor activo; si pides un modo que el proveedor no puede dar, se ajusta a uno que sí. Los puertos publicados se enlazan a 127.0.0.1 por defecto. Cambia eso con COMPUTE_BIND_ADDRESS: el propio valor por defecto de Docker publica en todas las interfaces, IPv6 incluido, lo que pondría tu contenedor en la internet pública en un host accesible. Define el valor por defecto de todo el despliegue con COMPUTE_DEFAULT_INGRESS. En modo host, InsForge anuncia el nombre de host pero no termina TLS ni enruta tráfico: ejecuta tu propia pasarela (Caddy, Traefik, nginx) por delante, como ya haces con el dashboard.

​
Construir desde el código fuente

Desplegar una imagen ya construida no necesita nada especial: crea el servicio con una referencia de imagen y se descarga y arranca. Para que InsForge construya tu Dockerfile, reserva el servicio y luego sube el contexto de construcción como un tarball:
Añade ?dockerfile=docker/Dockerfile si tu Dockerfile no está en la raíz del contexto; la ruta debe permanecer dentro del contexto. Solo se ejecuta una construcción a la vez: una segunda subida recibe 429 en lugar de almacenarse. En macOS, empaqueta con --no-xattrs (o COPYFILE_DISABLE=1): los atributos extendidos que el daemon de Linux no puede aplicar hacen que rechace todo el contexto.

​
Soporte de plataformas

​
Diferencias entre proveedores

Pide a GET /api/metadata la sección compute: informa de los proveedores configurados y de lo que puede hacer cada uno, para que las herramientas dejen de ofrecer opciones que se ignorarían.

​
Próximos pasos

  • Configura la CLI para vincular tu proyecto (la ruta recomendada).
  • Consulta Edge Functions si solo necesitas petición/respuesta.