Skip to main content
No. Cuando lees o escribes una tabla no se ejecuta ninguna función, así que no es una edge function.En InsForge tu código habla con el backend de tres formas distintas, y es fácil confundirlas:Llamada a la base de datos. Defines una tabla y InsForge te da al instante un conjunto de endpoints REST (como GET /api/database/records/{table}) y un SDK tipado. Llamar a select o insert lee y escribe la base de datos directamente, sin nada que desplegar y sin nada en ejecución. Es todo lo que necesitas para el CRUD normal. Consulta Base de datos.Edge Function. Úsala cuando la API autogenerada no basta y quieres tu propia lógica de servidor: un webhook de pago, un auth hook, código que se dispara cuando una fila se INSERTa, UPDATEa o DELETEa, o un trabajo programado. La clave es que se ejecuta una vez por petición o evento y luego termina. Consulta Edge Functions.Custom Compute. Úsalo cuando necesitas un proceso que se mantenga activo, como un worker de cola o un bucle de inferencia de IA. Una edge function no puede hacerlo porque no se ejecuta de forma continua. Consulta Custom Compute.Regla rápida: ¿solo mueves datos de entrada y salida? Es la base de datos (REST automática). ¿Escribes lógica que se ejecuta y termina? Edge function. ¿Necesitas algo funcionando todo el tiempo? Custom compute.
Por defecto todas tus tablas están en public. Solo tienes otro schema si creaste uno tú mismo con CREATE SCHEMA (los schemas internos de InsForge, como auth y storage, no están expuestos a la API de datos, así que .schema() y ?schema= no pueden alcanzarlos; como project admin todavía puedes leerlos con SQL directo, por ejemplo insforge db query o el editor SQL del dashboard). Una vez que tienes uno, puedes leerlo y escribirlo desde el dashboard, la REST API, la CLI y el SDK.Los ejemplos de abajo usan un schema que creaste llamado my_schema.Dashboard. Abre Database y usa el selector de schema en la parte superior de la barra lateral. Cualquier schema que creaste aparece junto a public, y al elegirlo navegas por las tablas de ese schema.REST API. El endpoint de records acepta el schema destino como parámetro de query o como cabecera de perfil de PostgREST. Las lecturas usan Accept-Profile; las escrituras y RPC usan Content-Profile:
CLI. La CLI lee y escribe cualquier schema con db query, solo cualifica la tabla con el schema:
SDK. Encadena .schema() antes del constructor de consultas (compatible con @insforge/sdk). Se traduce a la misma cabecera Accept-Profile / Content-Profile, así que lecturas, escrituras y RPC se enrutan al schema que indiques:
Un paso más para el acceso por API: un schema propio solo es enrutable, no legible. Los roles anon y authenticated no tienen privilegios sobre él hasta que se los concedes, sin importar quién sea el propietario de las tablas, así que las llamadas devuelven vacío o permiso denegado hasta que lo hagas. Concede privilegios a cada rol que expongas y luego añade RLS:
La visibilidad de filas queda gobernada por RLS como siempre. Que el project-admin sea propietario solo le permite gestionar y consultar las tablas directamente (por ejemplo desde el editor SQL del dashboard); no da acceso a los roles de la API.
Las tablas nuevas tienen RLS activado por defecto. Cuando creas una tabla (desde el dashboard, POST /api/database/tables o el SDK), RLS queda habilitado a menos que pases explícitamente rlsEnabled: false.El endpoint update-table-schema (PATCH /api/database/tables/{table}/schema) no tiene ningún campo para alternar RLS: solo gestiona columnas, claves foráneas y renombrados. Para cambiar RLS en una tabla existente, ejecuta una sola sentencia SQL:
Ejecuta ese SQL de cualquier forma en que ejecutes SQL de administrador; todas requieren acceso de project owner / admin:
También puedes ejecutarlo desde el editor SQL del dashboard, la herramienta run-raw-sql de MCP, o el endpoint REST de SQL directo (POST /api/database/advance/rawsql/unrestricted).
Desactivar RLS elimina todo el filtrado a nivel de fila: cualquier rol con privilegios sobre la tabla (como authenticated, y anon donde se le haya concedido) puede leer y escribir todas las filas a través de la API de datos. Es preferible escribir políticas RLS antes que desactivar RLS. Las solicitudes de administrador hechas con la API Key (ik_...) omiten RLS de todos modos.Activar RLS en una tabla que no tiene políticas aplica el rechazo por defecto de PostgreSQL: anon y authenticated pierden todo acceso a ella a través de la API de datos (se bloquea cada SELECT/INSERT/UPDATE/DELETE) hasta que agregues al menos una política. Crea las políticas que necesites antes de activar RLS, o justo después.
No con ese nombre. El equivalente en InsForge es la API Key de tu proyecto (empieza por ik_), la clave de administrador con acceso total. Cada proyecto tiene dos claves:
  • Anon Key: pública, para el navegador. Las peticiones se ejecutan con el rol anon, limitadas por RLS. Es la que provoca permission denied for schema storage.
  • API Key: clave de administrador con acceso total, solo para el servidor. Omite RLS.
Encuentra la API Key en el panel, en Project Settings → General (la fila API Key, marcada con “acceso total… no la expongas en tu frontend”), o ejecuta npx @insforge/cli secrets get API_KEY.Úsala desde código de servidor de confianza a través de createAdminClient, nunca desde el navegador:
Mantenla en una variable de entorno solo de servidor, nunca una expuesta al navegador (sin prefijo NEXT_PUBLIC_, VITE_ ni PUBLIC_).
El acceso se comparte a nivel de organización, no por proyecto. Invitas a alguien a la organización propietaria de tus proyectos y obtiene acceso a todos los proyectos que contiene. No existe un flujo aparte para “compartir solo este proyecto”.Para invitar a alguien:
  1. En el dashboard, abre la organización propietaria del proyecto usando el selector de organización en la esquina superior izquierda.
  2. Haz clic en Members en la barra lateral izquierda.
  3. Haz clic en Invite Member, introduce su email y elige un rol:
    • Administrator tiene control total: gestionar proyectos, además de invitar, eliminar y cambiar los roles de otros miembros.
    • Developer tiene acceso normal a los proyectos de la organización, pero no puede gestionar miembros.
  4. Reciben una invitación por email válida durante 7 días. Cuando inician sesión en InsForge con esa misma dirección de email y la aceptan, se unen a la organización con el rol que elegiste.
Para añadir otro administrador en concreto, elige el rol Administrator al invitar, o cambia su rol más tarde desde la lista de Members. Solo los Administrators pueden invitar o gestionar miembros.Transferir la organización por completo a un nuevo Owner es una acción distinta de invitar miembros. Para hacerlo, abre Organization Settings y usa Transfer Ownership (solo el owner actual puede iniciarlo, y el destinatario debe ser un usuario verificado de InsForge que acepte la solicitud enviada por email).
La pausa solo ocurre en el plan Free, por dos motivos:
  • Inactividad. Un proyecto free se pausa tras 7 días sin ninguna petición. Te avisamos por correo antes, y cualquier petición reinicia el contador de 7 días.
  • Límite de uso. Si tu organización supera los límites de uso del plan Free, sus proyectos siguen pausados hasta que la actualices.
En ambos casos tus datos quedan intactos. Para que los proyectos no se pausen nunca, actualiza la organización a Pro. Consulta Pricing.
Abre el proyecto en el dashboard y haz clic en Restore Project. Vuelve en unos minutos con tus datos intactos. Ten en cuenta un par de casos:
  • Puedes restaurar un proyecto free desde el dashboard hasta 30 días después de que se pause. Pasado ese plazo se archiva y solo puedes descargar la copia de la base de datos y los archivos de Storage (sin pérdida de datos).
  • Si se pausó porque la organización alcanzó su límite de uso, haz Upgrade to Pro para restaurarlo.
¿Sigues atascado? Pregunta en nuestro Discord para la respuesta más rápida.
npx @insforge/cli login abre un navegador para iniciar sesión. En una máquina sin interfaz, un servidor remoto o CI, usa una user API key en su lugar. No hace falta navegador.La forma más rápida es el prompt de configuración del dashboard, que inicia sesión y vincula el proyecto por ti:
1

Abre la página Install

Abre tu proyecto en el dashboard y ve a la página Install.
2

Elige tu coding agent

En Install in Agent, haz clic en el agent que usas y abre la pestaña CLI.
3

Copia el prompt

Copia el prompt de configuración y pégalo en tu agent. Inicia sesión en la CLI y vincula el proyecto en un solo paso.
El prompt rellena un comando de login limitado a tu cuenta, seguido del comando de vinculación:
Si solo necesitas la key, por ejemplo para ejecutar la CLI en CI, abre el menú de tu cuenta y ve a Profile → API Keys, luego crea una key (ponle una caducidad, o Never). Guárdala como secreto de CI y ejecuta login --user-api-key con ella. Añade --json para una salida legible por máquina.La key da acceso completo a tu cuenta, así que mantenla en secreto y rótala si se filtra.
Es una variable de entorno que solo defines cuando alojas InsForge por tu cuenta (self-hosting) y quieres usar Custom Compute. Custom Compute ejecuta tus contenedores de larga duración en Fly.io, así que una instancia autoalojada necesita tu propia cuenta de Fly: define FLY_API_TOKEN (un token de la API de Fly creado con fly tokens create org) y FLY_ORG (el slug de tu organización de Fly, obtenido con fly orgs list) en tu .env y reinicia. Ambos son obligatorios y, hasta que se definan, los endpoints de compute devuelven 503 COMPUTE_NOT_CONFIGURED.En InsForge Cloud nunca tocas esto. El compute está gestionado por nosotros, y el resto de la plataforma (base de datos, autenticación, Storage, edge functions) no necesita ningún token de Fly.
En realidad no. Este asistente responde a partir de la documentación pública de InsForge, así que no puede ver tu proyecto: no puede depurar un error, leer tus datos ni revisar tu configuración. Lleva cualquier cosa específica de tu propio proyecto a tu agente de programación. Conectado a InsForge a través de la CLI o MCP, tu agente puede leer tu backend en vivo, el esquema, los datos y los logs, y depurar el problema directamente. Solo descríbelo con tus propias palabras. Para un informe de salud y errores que puedes ejecutar tú mismo, usa npx @insforge/cli diagnose. Consulta Diagnostics & advisor.
Cada proyecto cloud tiene una cadena de conexión de Postgres directa, útil para psql, un GUI de base de datos, un ORM (Prisma, Drizzle) o un servicio externo como Better Auth que necesita su propio Postgres. Imprímela con la CLI:
También puedes obtenerla desde el dashboard, en Project Settings → Connect → Connection String (solo para proyectos cloud).Devuelve una URL con esta forma:
Añade --json para obtener { "connectionURL": "..." } en scripts. El comando funciona solo para proyectos cloud: en una instancia autoalojada Postgres queda expuesto directamente por tu configuración de docker-compose, así que usa las credenciales de Postgres locales (los valores DATABASE_URL / POSTGRES_* de tu .env) en su lugar.La cadena se conecta con el rol privilegiado postgres, por lo que no está limitada por row-level security e incluye la contraseña de ese rol. Trátala como un secreto: mantenla en el servidor y nunca la envíes al navegador.
Restaura tu base de datos existente sobre la cadena de conexión de Postgres de tu proyecto (la misma URL de la pregunta anterior). Las herramientas cliente estándar de PostgreSQL —pg_dump, pg_restore y psql— se conectan a ella directamente, así que importar es un simple «volcar y restaurar» (dump-then-restore). No interviene ningún comando especial de InsForge.
  1. Vuelca tu base de datos local (u otra):
  1. Obtén tu cadena de conexión de InsForge (solo para proyectos cloud):
  1. Restaura en InsForge:
Algunas cosas a tener en cuenta:
  • Pasa --no-owner para que los objetos restaurados pertenezcan al rol postgres en lugar de a roles que solo existen en tu base de datos de origen.
  • La cadena de conexión se conecta con el rol privilegiado postgres (omite row-level security), así que trátala como un secreto y ejecuta estos comandos solo en el servidor.
  • Esto funciona solo para proyectos cloud. En una instancia autoalojada, restaura contra tus credenciales de Postgres locales (los valores DATABASE_URL / POSTGRES_* de tu .env).
  • Una restauración escribe en tu base de datos en vivo y puede sobrescribir objetos existentes. Haz primero una copia de seguridad manual — consulta Copias de seguridad y restauración de la base de datos.
  • --single-transaction ejecuta el restore como una sola transacción, así que si alguna sentencia falla (un objeto en conflicto, una extensión o rol que falta, un error de restricción) toda la importación se revierte en lugar de dejar la base de datos a medio restaurar.
  • Las tablas importadas no obtienen el acceso gestionado de InsForge automáticamente. Un restore directo se salta los permisos de los roles anon / authenticated y la seguridad a nivel de fila (RLS) que InsForge aplica, así que las tablas importadas no son accesibles a través de la API REST ni del SDK —y las reglas de acceso de tu volcado de origen no llevan la protección RLS de InsForge— hasta que concedas acceso y añadas políticas de RLS a cada tabla (consulta Base de datos). Si prefieres versionar los cambios de esquema en git, consulta Migraciones de base de datos.
Por ahora no hay una forma autoservicio de dar de baja un Site desplegado: no existe un comando deployments delete ni una acción en el dashboard para ello. Los sitios desplegados se alojan de forma externa, así que incluso eliminar tu proyecto (npx @insforge/cli projects delete --project <id>) borra tus recursos de backend —base de datos, Storage y backend branches— pero no quita el sitio alojado.En la práctica esto rara vez importa. Si de verdad necesitas dar de baja un sitio desplegado, escríbele al equipo de InsForge en Discord.Dos acciones relacionadas que no son lo mismo que eliminar un sitio en vivo:
  • Cancelar una compilación en curso: npx @insforge/cli deployments cancel <id> detiene un despliegue en progreso; no da de baja un sitio que ya está en vivo.
  • Reemplazar lo que está en vivo: vuelve a desplegar sobre el mismo sitio con npx @insforge/cli deployments deploy ./frontend — el despliegue ready más reciente sirve la URL.