La sua infrastruttura. I suoi dati. Le sue chiavi.
Cronable è pensato per funzionare come una parte fidata del suo stack. Ecco esattamente come tiene le sue automazioni, i suoi segreti e la sua cronologia sotto il suo controllo.
On-premises per progettazione
Cronable si installa sulla sua macchina — un'app desktop per Mac o Windows, oppure un server sotto systemd/launchd. Non esiste alcun livello SaaS né alcuna dipendenza dal cloud. Le sue chiamate in uscita di routine sono un controllo periodico della licenza — che conferma il suo abbonamento e riporta semplici conteggi di job e utenti — e un controllo di nuove release firmate; e, solo se li attiva lei, una connessione in uscita verso il relay in hosting di Cronable per i webhook in entrata o il controllo remoto. Il suo carico di lavoro — definizioni dei job, segreti, esecuzioni e output — resta sulla macchina e non ci viene mai inviato. L'unica eccezione è una sessione di controllo remoto attiva: il traffico della dashboard di quella sessione viene instradato attraverso il nostro edge (la stessa fiducia di un qualsiasi proxy in hosting), con la cifratura end-to-end fino alla sua macchina come opzione Enterprise pianificata.
Segreti e credenziali cifrati a riposo
I valori segreti sono cifrati con AES-256-GCM con una chiave derivata dalla sua chiave di cifratura (scrypt con un salt casuale per ogni installazione). Le credenziali tipizzate — chiavi API, bearer token, basic auth, header personalizzati e stringhe di connessione a Postgres — vivono nello stesso archivio cifrato e vengono referenziate per nome, mai incollate nei file dei job. Nulla viene scritto su git, e nulla lascia la sua macchina. Faccia il backup della chiave separatamente — la perda e i segreti diventano irrecuperabili per progettazione.
Mascherati in ogni log e stream
I valori risolti di segreti e credenziali vengono oscurati in “***” attraverso i file di log, l'output dei job e lo stream di log dal vivo — anche quando un valore è suddiviso tra più blocchi in streaming. Ciò che viene eseguito sulla sua macchina resta sulla sua macchina.
Autenticato e a privilegio minimo
La console web richiede accessi per utente con hashing delle password argon2id e blocco anti brute-force. Il motore si lega a localhost per impostazione predefinita ed è pensato per essere eseguito come utente dedicato a basso privilegio. I chiamanti server-to-server usano un bearer token privato; i browser usano un cookie di sessione di breve durata — e la disconnessione, o la scadenza di una sessione, chiude anche gli stream di log dal vivo aperti entro pochi secondi. Le password devono inoltre superare un controllo di robustezza — una lunghezza minima più un test di prevedibilità — così che quelle deboli o facili da indovinare vengano rifiutate. L'autenticazione a due fattori (TOTP) opzionale aggiunge un codice monouso da un'app di autenticazione come Google Authenticator, con codici di recupero in caso di smarrimento del dispositivo; è obbligatoria per usare l'accesso remoto, così una macchina può essere aperta alla dashboard ospitata solo da una persona che l'ha attivata.
Accesso del team con ruoli
La console web è multiutente, con quattro ruoli ordinati — visualizzatore (sola lettura), editor (crea job, segreti ed esecuzioni), amministratore (gestisce utenti, ruoli e impostazioni) e proprietario, il primo account dell'installazione. Gli amministratori aggiungono e rimuovono utenti, assegnano il ruolo di ciascuno, reimpostano una password o un dispositivo a due fattori e revocano l'accesso in Impostazioni → Utenti — così un collega in uscita perde l'accesso all'istante e nessuno condivide le credenziali di accesso. Le installazioni più blindate possono attivare ulteriori controlli: la suddivisione in livelli di esecuzione limita chi può creare job che eseguono comandi, e l'approvazione delle modifiche aggiunge una revisione a quattro occhi, così un secondo amministratore deve approvare una modifica in sospeso a un job o a un segreto prima che abbia effetto.
Single sign-on tramite OIDC
Porti il suo identity provider — Okta, Entra ID, Google, Keycloak — tramite il flusso OIDC authorization-code con PKCE e verifica completa dell'ID token. Gli accessi SSO devono corrispondere a un account locale esistente: nulla viene provisionato automaticamente, e gli errori del provider emergono come messaggi fissi e cordiali invece che come redirect grezzi.
Una traccia di audit che puoi davvero leggere
Accessi e tentativi falliti, modifiche a segreti e credenziali, modifiche ai job, aggiornamenti delle impostazioni e sincronizzazioni git vengono registrati in una traccia di audit ad append-only — solo nomi e metadati, mai valori — consultabile e filtrabile direttamente nella console in Impostazioni → Audit.
Webhook in entrata induriti
I webhook in entrata raggiungono il suo daemon attraverso il nostro relay vincolato alla licenza su una connessione che il suo server apre verso l'esterno, così non espone mai una porta, a meno che non scelga deliberatamente di farlo. Ogni hook è vincolato alla sua licenza — nessun altro cliente può reclamarlo o riceverne gli eventi, nemmeno conoscendone l'URL — e protetto da un token per hook memorizzato solo come hash SHA-256 e verificato a tempo costante. L'URL richiede almeno 32 caratteri non indovinabili più quel token; sbagliato, mancante, disabilitato o sconosciuto restituiscono tutti lo stesso generico 401, e i tentativi ripetuti da un IP vengono bannati temporaneamente — così non c'è nulla da enumerare e nulla da forzare. I token vengono rivelati una sola volta alla creazione e sono rotabili con un clic. Se preferisce che i payload in entrata non transitino mai dai nostri server, può saltare il relay e servire un proprio endpoint HTTPS: è l'unico caso in cui apre davvero una porta, e i webhook arrivano poi direttamente alla sua macchina.
Cronologia auditata con git e reversibile
Ogni definizione di job è un file in un repository git di sua proprietà. Ogni modifica è un commit — pienamente confrontabile, attribuibile e reversibile. La sua cronologia dei job è auditabile con gli strumenti che il suo team già usa. Quando colleghi un repository per la sincronizzazione bidirezionale, Cronable accetta solo un repository privato — rifiuta un repository pubblico e interrompe la sincronizzazione se un repository collegato viene reso pubblico in seguito — così le tue definizioni dei job non potranno mai diventare leggibili pubblicamente.
Onesti sul confine di fiducia
Il compito di Cronable è eseguire comandi, agenti AI e HTTP per suo conto, quindi lo tratti come una shell sulla macchina. Le espressioni vengono eseguite in una sandbox di protezione dagli errori, non in un confine indurito — non gli dia mai in pasto input non fidato. La aiutiamo a distribuirlo con privilegio minimo e un sensato isolamento di rete.
Eseguilo dietro il tuo firewall.
Ha requisiti di sicurezza da rispettare? Ci descriva il suo ambiente e affronteremo insieme deployment, hardening e controlli di accesso.
Cronable, e non lascia mai la sua macchina.