Equipos y accesos
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 con privilegios. El mismo modelo de acceso opera en el panel de control, la API, la CLI, Terraform y nuestro servidor MCP. Disponibilidad: el proveedor de Terraform está en desarrollo activo y aún no está disponible. Todo lo demás descrito aquí ya está disponible.
El acceso no es un simple interruptor de encendido y apagado. Toda organización cliente incluye cuatro roles, cada uno con un paquete fijo de permisos granulares de módulo.acción, de modo que un contacto financiero nunca toca un servidor y un desarrollador nunca ve una factura.
Control total de la organización y sus subcuentas: crear organizaciones subordinadas, invitar y eliminar miembros, cambiar roles, gestionar claves de API, aprovisionar, reiniciar, suspender y eliminar sitios, gestionar facturas y métodos de pago, y leer el registro de auditoría. Dos cosas quedan deliberadamente fuera de su alcance: cerrar una organización y emitir reembolsos son acciones del personal, no de 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. Sin ningún acceso al sitio: un contacto financiero o un contable externo no pueden reiniciar, suspender ni eliminar nada.
Trabaja en sitios sin tocar dinero: visualiza y aprovisiona sitios, reinicia servicios, limpia cachés, gestiona claves de API y abre o responde a tickets de soporte. Sin vista de facturación, sin gestión de miembros, sin suspensión y sin eliminación: las acciones destructivas y comerciales se quedan con el propietario.
Una vista completa sin posibilidad de modificar nada: miembros, sitios, facturación, planes, tickets, estado de traducción y el registro de auditoría. El rol perfecto para un cliente interesado, un auditor interno o un nuevo empleado que aún está adaptándose.
La multinquilinaje es un árbol, no una lista plana. Una organización de revendedores se sitúa por encima de sus organizaciones cliente, y los sitios web se ubican por debajo de estas. Un miembro del equipo es una membresía —un usuario, una organización, un rol—, de modo que el mismo elemento primitivo impulsa a un equipo de dos personas, a una agencia que gestiona cien cuentas de clientes y a un revendedor que opera subcuentas bajo su propia marca.
Los roles se otorgan por organización y su aplicación también es por organización. Un rol en una organización no otorga acceso en otra organización separada y sin relación; un contratista puede ser Desarrollador en la cuenta de un cliente y de Solo lectura en una segunda, desde el mismo inicio de sesión. Sin embargo, el acceso fluye hacia abajo en su propia jerarquía: un rol en una organización matriz se aplica a las organizaciones anidadas debajo de ella, que es como los revendedores 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 limita cada consulta de inquilino al subárbol del invocador, y cualquier elemento fuera de ese subárbol devuelve un resultado de no encontrado en lugar de un error de permiso, por lo que la plataforma ni siquiera confirma que la organización o el sitio de otro inquilino exista.
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 permiso, por lo que no hay ninguna puerta trasera que se salte sus reglas de acceso.
Sitios, facturación, tickets, avisos, notificaciones, claves de API y gestión de equipos en un solo entorno. La interfaz muestra lo que el rol del miembro con sesión iniciada permite, para que no se muestren controles que no pueden usar.
La API publicada es el mismo motor de API que utiliza el panel de control. Las claves de API se emiten por organización con ámbitos granulares vinculados a los permisos de RBAC, y los modos independientes de prueba y producción (sandbox y live) permiten probar integraciones sin afectar la facturación o el aprovisionamiento real.
Administra sitios, dominios, DNS, buzones y planes como infraestructura como código y ejecuta terraform apply para aprovisionar el alojamiento, gobernado por los mismos ámbitos que todo lo demás.
Conecta Claude Code, Cursor, ChatGPT, Claude Desktop o cualquier herramienta compatible con MCP. Los tokens están limitados 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 una pista de auditoría completa.
Solo se almacena un hash de cada clave de API, nunca la clave sin procesar. Las claves tienen un nombre y un prefijo visible para que puedas distinguirlas, registrar cuándo se usaron por última vez y se pueden revocar individualmente sin afectar al resto.
La identidad funciona con Keycloak, por lo que la autenticación utiliza OIDC y SAML estándar en lugar de un formulario de inicio de sesión personalizado adaptado a un panel de alojamiento.
Cada acción con privilegios genera un registro de auditoría de solo adición: quién la realizó, qué hizo, sobre qué lo hizo, la evidencia de respaldo y la dirección IP de origen. El registro es de solo adición —los eventos se añaden, no se editan en el lugar— y en producción está particionado por tiempo para mantenerse rápido a medida que crece.
Leer ese registro es en sí mismo un permiso. Los propietarios y los miembros de solo lectura lo tienen, por lo que la persona responsable de la cuenta y la persona que la audita pueden ver el historial completo sin necesidad de privilegios elevados para hacerlo.
Alrededor de eso se encuentran los controles que los equipos más grandes solicitan: políticas de sesión, listas de permitidos de IP opcionales por organización y autenticación reforzada para acciones confidenciales, de modo que una sesión activa por sí sola no sea suficiente para realizar algo grave.
El catálogo de permisos son datos, no lógica codificada de forma rígida, por lo que se puede ampliar sin necesidad de rediseñar la plataforma.
El propietario tiene control total de la organización y sus subcuentas, incluidos los miembros, las claves de API, los sitios y los métodos de pago. El gestor de facturación ve las facturas, las suscripciones, los métodos de pago y los planes, sin acceso a los sitios. El desarrollador gestiona los sitios y las claves de API y se encarga de los tickets, sin control de facturación ni de miembros. El usuario de solo lectura puede ver los miembros, los sitios, la facturación, los planes, los tickets y el registro de auditoría sin cambiar nada.
Aún no está disponible como configuración por sitio; restringir una única membresía a sitios específicos es una mejora planificada. Hoy en día se logra la misma separación con el árbol de tenencia: coloque esos sitios en una organización secundaria y asigne a la persona un rol allí. Debido a que los roles se conceden por organización, ese acceso no se extiende a nada más en su cuenta.
No — las claves de API se emiten por organización, con permisos granulares vinculados a los mismos permisos de RBAC, y modos separados de prueba (sandbox) y producción. Úsalas como credenciales de servicio para integraciones, CI o Terraform, y usa las membresías para las personas. Solo se almacena un hash de cada clave, cada clave registra cuándo se usó por última vez y cualquier clave se puede revocar de forma independiente.
El rol de Desarrollador incluye ver y aprovisionar sitios, reiniciar servicios, vaciar cachés, gestionar claves de API y encargarse de los tickets. No otorga derechos de publicación en un sitio en vivo, por lo que si deseas que alguien pueda promocionar cambios, ese acceso debe recaer en un propietario. Los roles son por organización, por lo que puedes tener uno diferente en otra cuenta.
Sí. La identidad funciona con Keycloak mediante OIDC y SAML, por lo que el inicio de sesión único SAML está disponible para clientes de grandes empresas y agencias, junto con el acceso por enlace mágico, correo electrónico y contraseña, proveedores sociales, llaves de paso y autenticación de doble factor TOTP, la cual se aplica por directiva. Una sola sesión cubre el panel, el sitio público, la base de conocimientos y los tickets de soporte.
Cada acción con privilegios se registra en un registro de auditoría de solo adición que guarda el autor, la acción, el objetivo, la evidencia de respaldo y la dirección IP. Su lectura es un permiso independiente, que poseen tanto el rol de Propietario como el de Solo lectura, por lo que el propietario de una cuenta y un auditor pueden revisar el mismo historial.
Los planes se tarifican por capacidad de alojamiento en lugar de por 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 siempre se muestran a partir del catálogo activo, en su divisa, por lo que lo que ve en la página de precios es lo que se le cobra realmente.
Sí. La prueba de Footprint-Free dura 14 días, no requiere datos de tarjeta y cubre hasta 5 sitios, por lo que puedes configurar tu organización, invitar a tu equipo y probar los roles con trabajo real antes de pagar nada. Hay una garantía de devolución de dinero de 30 días que respalda los planes de pago.
Inicia una prueba de 14 días sin tarjeta en la línea Footprint-Free, invita a tu equipo y observa los roles funcionando en sitios reales antes de pagar nada.
Empieza gratis