Ihre Infrastruktur. Ihre Daten. Ihre Schlüssel.
Cronable ist darauf ausgelegt, wie ein vertrauter Teil Ihres eigenen Stacks zu laufen. Hier steht genau, wie es Ihre Automatisierung, Geheimnisse und Historie unter Ihrer Kontrolle hält.
On-premises von Grund auf
Cronable installiert sich auf Ihrem eigenen Rechner — als Mac- oder Windows-Desktop-App oder als Server unter systemd/launchd. Es gibt keine SaaS-Stufe und keine Cloud-Abhängigkeit. Seine routinemäßigen ausgehenden Aufrufe sind eine periodische Lizenzprüfung — die Ihr Abonnement bestätigt und einfache Job- und Benutzerzahlen meldet — sowie eine Prüfung auf neue signierte Releases; und, nur wenn Sie diese aktivieren, eine ausgehende Verbindung zu Cronables gehostetem Relay für eingehende Webhooks oder Fernsteuerung. Ihre Arbeitslast — Job-Definitionen, Geheimnisse, Läufe und Ausgaben — bleibt auf dem Rechner und wird nie an uns gesendet. Die einzige Ausnahme ist eine aktive Fernsteuerungs-Sitzung: Deren Dashboard-Verkehr wird über unsere Edge weitergeleitet (dasselbe Vertrauen wie bei jedem gehosteten Proxy), wobei Ende-zu-Ende-Verschlüsselung bis zu Ihrem eigenen Rechner eine geplante Enterprise-Option ist.
Geheimnisse & Zugangsdaten im Ruhezustand verschlüsselt
Geheimniswerte werden mit AES-256-GCM verschlüsselt, mit einem Schlüssel, der aus Ihrem eigenen Verschlüsselungsschlüssel abgeleitet wird (scrypt mit einem pro Installation zufälligen Salt). Typisierte Zugangsdaten — API-Schlüssel, Bearer-Tokens, Basic Auth, benutzerdefinierte Header und Postgres-Verbindungsstrings — liegen im selben verschlüsselten Speicher und werden per Namen referenziert, nie in Job-Dateien eingefügt. Nichts wird in git geschrieben, und nichts verlässt Ihren Rechner. Den Schlüssel sichern Sie separat — verlieren Sie ihn, sind die Geheimnisse konstruktionsbedingt unwiederbringlich.
Maskiert in jedem Log und Stream
Aufgelöste Geheimnis- und Zugangsdatenwerte werden über Log-Dateien, Job-Ausgabe und den Live-Log-Stream hinweg auf „***“ geschwärzt — selbst wenn ein Wert über Streaming-Chunks verteilt ist. Was auf Ihrem Rechner läuft, bleibt auf Ihrem Rechner.
Authentifiziert und mit minimalen Rechten
Die Web-Konsole erfordert Logins pro Benutzer mit argon2id-Passwort-Hashing und Brute-Force-Sperre. Die Engine bindet standardmäßig an localhost und ist dafür gedacht, als dedizierter Benutzer mit geringen Rechten zu laufen. Server-zu-Server-Aufrufer nutzen ein privates Bearer-Token; Browser nutzen ein kurzlebiges Session-Cookie — und das Abmelden oder eine ablaufende Session schließt selbst offene Live-Log-Streams binnen Sekunden. Passwörter müssen zudem eine Stärkeprüfung bestehen — eine Mindestlänge plus einen Erratbarkeitstest — sodass schwache oder leicht zu erratende Passwörter abgelehnt werden. Optionale Zwei-Faktor-Authentifizierung (TOTP) ergänzt einen Einmalcode aus einer Authenticator-App wie Google Authenticator, mit Wiederherstellungscodes für ein verlorenes Gerät; sie ist für den Fernzugriff erforderlich, sodass ein Rechner nur von einer Person für das gehostete Dashboard geöffnet werden kann, die sie aktiviert hat.
Teamzugriff mit Rollen
Die Web-Konsole ist mehrbenutzerfähig, mit vier gestuften Rollen — Betrachter (nur Lesen), Bearbeiter (erstellt Jobs, Geheimnisse und Ausführungen), Administrator (verwaltet Benutzer, Rollen und Einstellungen) und Eigentümer, das erste Konto der Installation. Administratoren fügen Benutzer hinzu und entfernen sie, legen die Rolle jeder Person fest, setzen ein Passwort oder ein Zwei-Faktor-Gerät zurück und entziehen unter Einstellungen → Benutzer den Zugang — sodass ein ausscheidendes Teammitglied sofort den Zugriff verliert und niemand sich ein Login teilt. Streng abgesicherte Installationen können mehr aktivieren: Gestufte Ausführungsrechte regeln, wer Jobs anlegen darf, die Befehle ausführen, und eine Änderungsfreigabe ergänzt das Vier-Augen-Prinzip, sodass ein zweiter Administrator eine vorgemerkte Änderung an einem Job oder Geheimnis genehmigen muss, bevor sie wirksam wird.
Single Sign-on über OIDC
Bringen Sie Ihren Identity-Provider mit — Okta, Entra ID, Google, Keycloak — über den OIDC-Authorization-Code-Flow mit PKCE und vollständiger ID-Token-Verifizierung. SSO-Anmeldungen müssen einem bestehenden lokalen Konto zugeordnet sein: Nichts wird automatisch bereitgestellt, und Anbieterfehler erscheinen als feste, freundliche Meldungen statt als rohe Weiterleitungen.
Ein Audit-Trail, den Sie tatsächlich lesen können
Anmeldungen und fehlgeschlagene Versuche, Änderungen an Geheimnissen und Zugangsdaten, Job-Bearbeitungen, Einstellungsänderungen und git-Synchronisierungen werden in einem Append-only-Audit-Trail erfasst — nur Namen und Metadaten, nie Werte — direkt in der Konsole unter Einstellungen → Audit einsehbar und filterbar.
Gehärtete eingehende Webhooks
Eingehende Webhooks erreichen Ihren Daemon über unser lizenzgesteuertes Relay, und zwar über eine Verbindung, die Ihr Server nach außen öffnet, sodass Sie nie einen Port freigeben – es sei denn, Sie entscheiden sich bewusst dafür. Jeder Hook ist an Ihre Lizenz gebunden — kein anderer Kunde kann ihn beanspruchen oder seine Ereignisse empfangen, selbst wenn er die URL kennt — und durch ein Token pro Hook geschützt, das nur als SHA-256-Hash gespeichert und in konstanter Zeit geprüft wird. Die URL benötigt mindestens 32 nicht erratbare Zeichen plus dieses Token; falsch, fehlend, deaktiviert oder unbekannt liefern alle denselben generischen 401, und wiederholte Anfragen von einer IP werden vorübergehend gesperrt — es gibt also nichts aufzuzählen und nichts per Brute-Force zu knacken. Tokens werden bei der Erstellung einmal angezeigt und sind mit einem Klick rotierbar. Wenn Ihnen lieber ist, dass eingehende Nutzdaten unsere Server gar nicht erst passieren, können Sie das Relay überspringen und stattdessen einen eigenen HTTPS-Endpunkt betreiben – das ist der eine Fall, in dem Sie tatsächlich einen Port öffnen, und die Webhooks kommen dann direkt bei Ihrer Maschine an.
Git-auditierte, umkehrbare Historie
Jede Job-Definition ist eine Datei in einem git-Repository, das Ihnen gehört. Jede Änderung ist ein Commit — vollständig diffbar, zuordenbar und umkehrbar. Ihre Job-Historie ist mit den Tools auditierbar, die Ihr Team ohnehin nutzt. Wenn Sie ein Repository für die bidirektionale Synchronisierung verknüpfen, akzeptiert Cronable nur ein privates — ein öffentliches Repository wird abgelehnt, und die Synchronisierung stoppt, wenn ein verknüpftes Repository später öffentlich gemacht wird — sodass Ihre Job-Definitionen niemals öffentlich lesbar werden können.
Ehrlich über die Vertrauensgrenze
Cronables Aufgabe ist es, Befehle, KI-Agenten und HTTP in Ihrem Namen auszuführen, behandeln Sie es also wie eine Shell auf dem Rechner. Ausdrücke laufen in einer Sandbox mit Fehlerschutz, keiner gehärteten Grenze — füttern Sie es nie mit nicht vertrauenswürdigen Eingaben. Wir helfen Ihnen, es mit minimalen Rechten und sinnvoller Netzwerkisolation bereitzustellen.
Führen Sie es hinter Ihrer Firewall aus.
Müssen Sie Sicherheitsanforderungen erfüllen? Nennen Sie uns Ihre Umgebung, und wir gehen Bereitstellung, Härtung und Zugriffskontrollen gemeinsam durch.
Cronable, und es verlässt nie Ihren Rechner.