Votre infrastructure. Vos données. Vos clés.
Cronable est conçu pour fonctionner comme une partie de confiance de votre propre stack. Voici exactement comment il garde votre automatisation, vos secrets et votre historique sous votre contrôle.
Sur site par conception
Cronable s’installe sur votre propre machine — une application de bureau Mac ou Windows, ou un serveur sous systemd/launchd. Il n’y a pas de niveau SaaS ni de dépendance cloud. Ses appels sortants réguliers sont une vérification périodique de licence — qui confirme votre abonnement et rapporte de simples décomptes de jobs et d’utilisateurs — et une vérification de nouvelles versions signées ; et, uniquement si vous les activez, une connexion sortante vers le relay hébergé de Cronable pour les webhooks entrants ou le contrôle à distance. Votre charge de travail — définitions de jobs, secrets, exécutions et sorties — reste sur la machine et ne nous est jamais envoyée. La seule exception est une session de contrôle à distance active : son trafic de tableau de bord est relayé par notre edge (au même niveau de confiance que n’importe quel proxy hébergé), le chiffrement de bout en bout jusqu’à votre propre machine étant une option Enterprise à venir.
Secrets et identifiants chiffrés au repos
Les valeurs secrètes sont chiffrées en AES-256-GCM avec une clé dérivée de votre propre clé de chiffrement (scrypt avec un sel aléatoire par installation). Les identifiants typés — clés d’API, jetons bearer, authentification basique, en-têtes personnalisés et chaînes de connexion Postgres — vivent dans le même magasin chiffré et sont référencés par nom, jamais collés dans les fichiers de job. Rien n’est écrit dans git, et rien ne quitte votre machine. Vous sauvegardez la clé séparément — perdez-la et les secrets sont irrécupérables, par conception.
Masqués dans chaque journal et flux
Les valeurs de secrets et d’identifiants résolues sont caviardées en « *** » dans les fichiers journaux, la sortie des jobs et le flux de journaux en direct — même lorsqu’une valeur est répartie sur plusieurs fragments du flux. Ce qui s’exécute sur votre machine reste sur votre machine.
Authentifié et à moindre privilège
La console web exige des connexions par utilisateur avec hachage de mot de passe argon2id et verrouillage anti-force brute. Le moteur se lie à localhost par défaut et est destiné à s’exécuter comme un utilisateur dédié à faible privilège. Les appelants serveur-à-serveur utilisent un jeton bearer privé ; les navigateurs utilisent un cookie de session de courte durée — et la déconnexion, ou l’expiration d’une session, ferme même les flux de journaux en direct ouverts en quelques secondes. Les mots de passe doivent également passer un contrôle de robustesse — une longueur minimale plus un test de prévisibilité — afin que les mots de passe faibles ou faciles à deviner soient refusés. L'authentification à deux facteurs (TOTP) facultative ajoute un code à usage unique issu d'une application d'authentification comme Google Authenticator, avec des codes de récupération en cas de perte de l'appareil ; elle est obligatoire pour utiliser l'accès à distance, de sorte qu'une machine ne peut être ouverte au tableau de bord hébergé que par une personne qui l'a activée.
Accès d’équipe avec rôles
La console web est multi-utilisateur, avec quatre rôles hiérarchisés — observateur (lecture seule), éditeur (crée des jobs, des secrets et des exécutions), administrateur (gère les utilisateurs, les rôles et les paramètres) et propriétaire, le premier compte de l’installation. Les administrateurs ajoutent et retirent des utilisateurs, définissent le rôle de chacun, réinitialisent un mot de passe ou un appareil à deux facteurs et révoquent l’accès sous Paramètres → Utilisateurs — ainsi un coéquipier sur le départ perd l’accès aussitôt et personne ne partage d’identifiants. Les installations verrouillées peuvent activer davantage de contrôles : le cloisonnement des droits d’exécution restreint qui peut créer des jobs qui lancent des commandes, et l’approbation des changements ajoute une revue à quatre yeux, de sorte qu’un second administrateur doit approuver une modification de job ou de secret en attente avant qu’elle ne prenne effet.
Authentification unique via OIDC
Apportez votre fournisseur d’identité — Okta, Entra ID, Google, Keycloak — via le flux OIDC authorization-code avec PKCE et vérification complète du jeton d’identité. Les connexions SSO doivent correspondre à un compte local existant : rien n’est provisionné automatiquement, et les erreurs du fournisseur apparaissent sous forme de messages fixes et clairs plutôt que de redirections brutes.
Une piste d’audit vraiment lisible
Connexions et tentatives échouées, changements de secrets et d’identifiants, modifications de jobs, mises à jour de paramètres et synchronisations git sont enregistrés dans une piste d’audit en ajout seul — noms et métadonnées uniquement, jamais les valeurs — consultable et filtrable directement dans la console sous Paramètres → Audit.
Webhooks entrants durcis
Les webhooks entrants atteignent votre daemon via notre relais protégé par licence, sur une connexion que votre serveur ouvre vers l’extérieur, de sorte que vous n’exposez jamais de port — sauf si vous choisissez délibérément de le faire. Chaque hook est lié à votre licence — aucun autre client ne peut le revendiquer ni recevoir ses événements, même en connaissant son URL — et protégé par un jeton par hook stocké uniquement sous forme de hachage SHA-256 et vérifié en temps constant. L’URL nécessite au moins 32 caractères indevinables plus ce jeton ; incorrect, manquant, désactivé ou inconnu renvoient tous la même 401 générique, et les sondages répétés depuis une IP sont temporairement bannis — il n’y a donc rien à énumérer et rien à forcer. Les jetons sont révélés une seule fois à la création et rotables en un clic. Si vous préférez que les charges utiles entrantes ne transitent jamais par nos serveurs, vous pouvez ignorer le relais et exposer votre propre point de terminaison HTTPS — c’est le seul cas où vous ouvrez effectivement un port, et les webhooks arrivent alors directement sur votre machine.
Historique audité dans git, réversible
Chaque définition de job est un fichier dans un dépôt git qui vous appartient. Chaque changement est un commit — entièrement comparable, attribuable et réversible. Votre historique de jobs est auditable avec les outils que votre équipe utilise déjà. Lorsque vous liez un dépôt pour la synchronisation bidirectionnelle, Cronable n'accepte qu'un dépôt privé — il refuse un dépôt public et arrête la synchronisation si un dépôt lié devient public par la suite — afin que vos définitions de tâches ne puissent jamais devenir lisibles publiquement.
Honnête sur la frontière de confiance
Le rôle de Cronable est d’exécuter des commandes, des agents IA et du HTTP en votre nom, alors traitez-le comme un shell sur la machine. Les expressions s’exécutent dans un bac à sable garde-fou, pas dans une frontière durcie — ne lui donnez jamais d’entrée non fiable. Nous vous aidons à le déployer avec le moindre privilège et une isolation réseau raisonnable.
Exécutez-le derrière votre pare-feu.
Des exigences de sécurité à respecter ? Décrivez-nous votre environnement et nous parcourrons ensemble le déploiement, le durcissement et les contrôles d’accès.
Cronable, et il ne quitte jamais votre machine.