Tu infraestructura. Tus datos. Tus claves.
Cronable está hecho para funcionar como una parte de confianza de tu propio stack. Aquí tienes exactamente cómo mantiene tu automatización, tus secretos y tu historial bajo tu control.
On-premises por diseño
Cronable se instala en tu propia máquina — una app de escritorio para Mac o Windows, o un servidor bajo systemd/launchd. No hay nivel SaaS ni dependencia de la nube. Sus llamadas salientes rutinarias son una verificación periódica de licencia — que confirma tu suscripción e informa recuentos simples de trabajos y usuarios — y una comprobación de nuevas versiones firmadas; y, solo si los activas, una conexión saliente al relay alojado de Cronable para webhooks entrantes o control remoto. Tu carga de trabajo — definiciones de trabajos, secretos, ejecuciones y resultados — se queda en la máquina y nunca se nos envía. La única excepción es una sesión de control remoto activa: su tráfico del panel de control se transmite a través de nuestro edge (la misma confianza que cualquier proxy alojado), con el cifrado de extremo a extremo hasta tu propia máquina como una opción prevista para Enterprise.
Secretos y credenciales cifrados en reposo
Los valores secretos se cifran con AES-256-GCM con una clave derivada de tu propia clave de cifrado (scrypt con una sal aleatoria por instalación). Las credenciales tipadas — claves de API, tokens bearer, autenticación básica, cabeceras personalizadas y cadenas de conexión de Postgres — viven en el mismo almacén cifrado y se referencian por nombre, nunca se pegan en los archivos de los trabajos. Nada se escribe en git, y nada sale de tu máquina. La clave la respaldas por separado — piérdela y los secretos son irrecuperables por diseño.
Enmascarado en cada registro y flujo
Los valores de secretos y credenciales resueltos se redactan a «***» en los archivos de registro, la salida de los trabajos y el flujo de registro en vivo — incluso cuando un valor se reparte entre fragmentos de streaming. Lo que se ejecuta en tu equipo se queda en tu equipo.
Autenticado y con privilegios mínimos
La consola web requiere inicios de sesión por usuario con hash de contraseñas argon2id y bloqueo ante fuerza bruta. El motor se vincula a localhost por defecto y está pensado para ejecutarse como un usuario dedicado de bajo privilegio. Las llamadas de servidor a servidor usan un token bearer privado; los navegadores usan una cookie de sesión de corta duración — y cerrar sesión, o que una sesión caduque, cierra incluso los flujos de registro en vivo abiertos en segundos. Las contraseñas también deben superar una comprobación de robustez — una longitud mínima más una prueba de previsibilidad — de modo que se rechazan las débiles o fáciles de adivinar. La autenticación de dos factores (TOTP) opcional añade un código de un solo uso de una app de autenticación como Google Authenticator, con códigos de recuperación por si pierdes el dispositivo; es obligatoria para usar el acceso remoto, así que una máquina solo puede abrirse al panel alojado desde una persona que la tenga activada.
Acceso de equipo con roles
La consola web es multiusuario, con cuatro roles ordenados — lector (solo lectura), editor (crea trabajos, secretos y ejecuciones), administrador (gestiona usuarios, roles y configuración) y propietario, la primera cuenta de la instalación. Los administradores añaden y quitan usuarios, asignan el rol de cada persona, restablecen una contraseña o un dispositivo de dos factores, y revocan el acceso en Configuración → Usuarios — así, un compañero que se marcha pierde el acceso de inmediato y nadie comparte un inicio de sesión. Las instalaciones más restringidas pueden activar más controles: la división por niveles de ejecución restringe quién puede crear trabajos que ejecutan comandos, y la aprobación de cambios añade una revisión a cuatro ojos, de modo que un segundo administrador debe aprobar un cambio pendiente de un trabajo o un secreto antes de que surta efecto.
Inicio de sesión único vía OIDC
Trae tu proveedor de identidad — Okta, Entra ID, Google, Keycloak — mediante el flujo de código de autorización OIDC con PKCE y verificación completa del ID token. Los inicios de sesión con SSO deben corresponder a una cuenta local existente: nada se aprovisiona automáticamente, y los errores del proveedor aparecen como mensajes fijos y amables en lugar de redirecciones en crudo.
Un rastro de auditoría que de verdad puedes leer
Los inicios de sesión y los intentos fallidos, los cambios de secretos y credenciales, las ediciones de trabajos, las actualizaciones de configuración y las sincronizaciones de git se registran en un rastro de auditoría de solo anexado — solo nombres y metadatos, nunca valores — consultable y filtrable directamente en la consola en Configuración → Auditoría.
Webhooks entrantes endurecidos
Los webhooks entrantes llegan a tu daemon a través de nuestro relé condicionado por licencia, sobre una conexión que tu servidor abre hacia fuera, así que nunca expones un puerto, salvo que decidas hacerlo deliberadamente. Cada webhook está vinculado a tu licencia — ningún otro cliente puede reclamarlo ni recibir sus eventos, aun conociendo su URL — y protegido por un token por webhook almacenado solo como un hash SHA-256 y comprobado en tiempo constante. La URL necesita al menos 32 caracteres imposibles de adivinar más ese token; incorrectos, ausentes, desactivados o desconocidos, todos devuelven el mismo 401 genérico, y los sondeos repetidos desde una IP se prohíben temporalmente — así que no hay nada que enumerar ni nada que forzar por fuerza bruta. Los tokens se revelan una vez al generarse y son rotables con un clic. Si prefieres que las cargas entrantes no pasen nunca por nuestros servidores, puedes prescindir del relé y servir tu propio endpoint HTTPS: ese es el único caso en el que sí abres un puerto, y los webhooks llegan entonces directamente a tu máquina.
Historial auditado con git y reversible
Cada definición de trabajo es un archivo en un repositorio de git que es tuyo. Cada cambio es un commit — totalmente comparable, atribuible y reversible. Tu historial de trabajos es auditable con las herramientas que tu equipo ya usa. Cuando vinculas un repositorio para la sincronización bidireccional, Cronable solo acepta uno privado — rechaza un repositorio público y detiene la sincronización si un repositorio vinculado se hace público más adelante — de modo que tus definiciones de trabajos nunca puedan quedar expuestas públicamente.
Honestos sobre el límite de confianza
El trabajo de Cronable es ejecutar comandos, agentes de IA y HTTP en tu nombre, así que trátalo como un shell en el equipo. Las expresiones se ejecutan en un sandbox de protección básica, no en un límite endurecido — nunca le des entrada no confiable. Te ayudamos a desplegarlo con privilegios mínimos y un aislamiento de red sensato.
Ejecútalo detrás de tu firewall.
¿Tienes requisitos de seguridad que cumplir? Cuéntanos tu entorno y repasaremos juntos el despliegue, el endurecimiento y los controles de acceso.
Cronable, y nunca sale de tu equipo.