Equipos y acceso
Cuatro roles de cliente, subcuentas que reflejan la estructura real de su empresa, claves de API por organización, inicio de sesión único y un registro de auditoría detrás de cada acción privilegiada. El mismo modelo de acceso funciona en el panel de control, la API, la CLI, Terraform y nuestro servidor MCP. Disponibilidad: el proveedor de Terraform se encuentra en desarrollo activo y aún no está disponible. Todo lo demás descrito aquí está activo a partir de hoy.
El acceso no es un simple interruptor de encendido/apagado. Cada organización de cliente incluye cuatro roles, cada uno de ellos con un paquete fijo de permisos granulares module.action, de modo que un contacto de finanzas nunca toque un servidor y un desarrollador nunca vea una factura.
Control total de la organización y sus subcuentas: crear organizaciones secundarias, invitar y eliminar miembros, cambiar roles, administrar claves de API, aprovisionar, reiniciar, suspender y eliminar sitios, administrar facturas y métodos de pago, y leer el registro de auditoría. Hay dos acciones que quedan deliberadamente fuera de su alcance: cerrar una organización y emitir reembolsos son tareas del personal, no un rol de cliente.
Todo lo financiero y nada más: facturas, suscripciones, métodos de pago y el catálogo de planes, además de una vista de la organización y su lista de miembros. Ningún acceso al sitio en absoluto — un contacto financiero o un contable externo no puede reiniciar, suspender ni eliminar nada.
Trabaje en los sitios web sin gestionar aspectos económicos: visualice y aprovisione sitios, reinicie servicios, vacíe cachés, gestione claves API y cree o responda a solicitudes de asistencia. Sin acceso a la facturación, sin gestión de miembros, sin suspensiones ni eliminaciones: las acciones destructivas y comerciales permanecen reservadas al propietario.
Una vista completa sin posibilidad de cambiar nada: miembros, sitios, facturación, planes, tickets, estado de la traducción y el registro de auditoría. El rol adecuado para una parte interesada del cliente, un auditor interno o un nuevo integrante que todavía se está adaptando.
El arrendamiento múltiple es un árbol, no una lista plana. Una organización de revendedor se sitúa por encima de las organizaciones de sus clientes, y los sitios web se sitúan bajo estas. Un miembro del equipo es una membresía —un usuario, una organización, un rol—, por lo que el mismo elemento básico da servicio a un equipo de dos personas, a una agencia que gestiona cien cuentas de clientes y a un revendedor que administra subcuentas bajo su propia marca.
Los roles se conceden por organización y la aplicación también es por organización. Un rol en una organización no otorga acceso en una organización independiente y no relacionada; un contratista puede ser Developer en la cuenta de un cliente y Read-only en una segunda, desde el mismo inicio de sesión. Sin embargo, el acceso se transmite hacia abajo en su propia jerarquía: un rol en una organización principal se aplica a las organizaciones anidadas bajo ella, que es la forma en que los distribuidores y las agencias gestionan a sus clientes.
El aislamiento se aplica en la base de datos, no solo en el código de la aplicación. La seguridad a nivel de fila de Postgres restringe cada consulta de inquilino al subárbol del emisor, y todo lo que esté fuera de ese subárbol devuelve un resultado de no encontrado en lugar de un error de permisos; de este modo, la plataforma ni siquiera confirma que la organización o el sitio de otro inquilino existan.
Los roles no son una simple comodidad del panel de control. Cada vía de acceso a la plataforma se resuelve con las mismas claves de permisos, por lo que no existe ninguna puerta trasera que eluda sus reglas de acceso.
Sitios, facturación, tíquets, avisos, notificaciones, claves de API y gestión de equipos en un único entorno. La interfaz muestra lo que permite el rol del miembro que ha iniciado sesión, de modo que no se muestran controles que no se puedan utilizar.
La API publicada es la misma API de motor que utiliza el panel de control. Las claves de API se emiten por organización con alcances granulares vinculados a los permisos de RBAC, y los modos sandbox y en vivo independientes le permiten probar integraciones sin afectar la facturación o el aprovisionamiento reales.
Gestione sitios, dominios, DNS, buzones de correo y planes como infraestructura como código y ejecute terraform apply para aprovisionar el alojamiento, gobernado por los mismos alcances que todo lo demás.
Conecte Claude Code, Cursor, ChatGPT, Claude Desktop o cualquier herramienta compatible con MCP. Los tokens están delimitados a una organización y a sus permisos de RBAC, son revocables por herramienta, con confirmación en acciones destructivas, límites de gasto y un registro de auditoría completo.
Solo se almacena un hash de cada clave de API, nunca la clave sin procesar. Las claves llevan un nombre y un prefijo visible para que pueda distinguirlas, registran cuándo se utilizaron por última vez y se pueden revocar individualmente sin afectar al resto.
La gestión de identidades se ejecuta en Keycloak, por lo que la autenticación es OIDC y SAML auténtico, en lugar de un formulario de inicio de sesión a medida superpuesto en un panel de alojamiento.
Cada acción con privilegios escribe un registro de auditoría de solo adición: quién la realizó, qué hizo, sobre qué la hizo, las pruebas que la respaldan y la dirección IP de origen. El registro es de solo adición —los eventos se agregan, no se editan in situ— y en producción está particionado por tiempo para que mantenga su rapidez a medida que crece.
Leer ese registro es en sí mismo un permiso. Los propietarios y los miembros con acceso de solo lectura disponen de él, de modo que la persona responsable de la cuenta y la persona que la audita puedan ver el historial completo sin necesidad de privilegios elevados para hacerlo.
En torno a esto se encuentran los controles que solicitan los equipos más grandes: directivas de sesión, listas de IP permitidas opcionales por organización y autenticación reforzada en acciones confidenciales, de modo que una sesión activa por sí sola no baste para realizar una acción crítica.
El catálogo de permisos son datos, no lógica codificada de forma fija, razón por la cual se puede ampliar sin tener que reestructurar la plataforma.
El propietario tiene control total sobre la organización y sus subcuentas, incluidos miembros, claves de API, sitios y métodos de pago. El gestor de facturación visualiza facturas, suscripciones, métodos de pago y planes, sin acceso a los sitios. El desarrollador administra los sitios y las claves de API y gestiona los tickets, sin control sobre la facturación ni los miembros. El rol de solo lectura puede ver miembros, sitios, facturación, planes, tickets y el registro de auditoría sin modificar nada.
Todavía no como una configuración por sitio; limitar una sola membresía a sitios específicos es una mejora planificada. Hoy en día, puede lograr la misma separación con el árbol de inquilinos: coloque esos sitios en una organización secundaria y asígnele un rol a la persona allí. Como los roles se otorgan por organización, ese acceso no se transfiere a ningún otro elemento de su cuenta.
No: las claves de API se emiten por organización, con alcances granulares vinculados a los mismos permisos de RBAC, y modos de pruebas (sandbox) y producción independientes. Utilícelas como credenciales de servicio para integraciones, CI o Terraform, y utilice membresías para personas. Solo se almacena un hash de cada clave, cada clave registra cuándo se utilizó por última vez y cualquier clave se puede revocar de forma independiente.
El rol de Desarrollador abarca la visualización y el aprovisionamiento de sitios, el reinicio de servicios, el vaciado de cachés, la gestión de claves de API y el tratamiento de incidencias. No confiere permisos de publicación en un sitio activo, por lo que, si desea que alguien pueda aplicar cambios, dicho acceso debe corresponder a un propietario. Los roles se definen por organización, de modo que usted puede tener uno diferente en una cuenta distinta.
Sí. La gestión de identidades se ejecuta en Keycloak con OIDC y SAML, por lo que el inicio de sesión único (SSO) SAML está disponible para clientes corporativos y agencias junto con el inicio de sesión mediante enlace mágico, correo electrónico y contraseña, proveedores sociales, llaves de acceso (passkeys) y autenticación de dos factores mediante TOTP, la cual se aplica por directiva. Una sola sesión cubre el panel de control, el sitio público, la base de conocimientos y los tickets de soporte.
Cada acción con privilegios se escribe en un registro de auditoría de solo anexado que registra el autor, la acción, el destino, las pruebas de respaldo y la dirección IP. Leerlo es un permiso por derecho propio, en posesión tanto del rol de Propietario como del de Solo lectura, de modo que el propietario de una cuenta y un auditor puedan revisar el mismo historial.
Los planes tienen un precio basado en la capacidad de alojamiento y no en el número de personas. En la línea Footprint-Free, por ejemplo, los 42 niveles comparten exactamente el mismo conjunto de derechos y solo se diferencian por el número de sitios que permiten. Los precios se obtienen siempre del catálogo en tiempo real, en su moneda, por lo que lo que ve en la página de precios es lo que realmente se cobra.
Sí. La prueba de Footprint-Free dura 14 días, no requiere datos de tarjeta y cubre hasta 5 sitios, por lo que puede configurar su organización, invitar a su equipo y probar los roles con trabajo real antes de pagar nada. Los planes de pago cuentan con una garantía de devolución de dinero de 30 días.
Comience una prueba de 14 días sin tarjeta en la línea Footprint-Free, invite a su equipo y compruebe cómo funcionan los roles en sitios reales antes de pagar nada.
Empiece gratis