Your infrastructure. Your data. Your keys.
Cronable is built to run like a trusted part of your own stack. Here’s exactly how it keeps your automation, secrets and history under your control.
On-premises by design
Cronable installs on your own server or VM and runs under systemd like any other service. There is no SaaS tier and no cloud dependency — the engine never phones home, and no usage or telemetry is collected.
Secrets & credentials encrypted at rest
Secret values are AES-256-GCM encrypted with a key derived from your own encryption key (scrypt with a per-install random salt). Typed credentials — API keys, bearer tokens, basic auth, custom headers and Postgres connection strings — live in the same encrypted store and are referenced by name, never pasted into job files. Nothing is written to git, and nothing leaves your machine. You back up the key separately — lose it and secrets are unrecoverable by design.
Masked in every log and stream
Resolved secret and credential values are redacted to “***” across log files, job output and the live log stream — even when a value is split across streaming chunks. What runs on your box stays on your box.
Authenticated and least-privilege
The web console requires per-user logins with argon2id password hashing and brute-force lockout. The engine binds to localhost by default and is meant to run as a dedicated low-privilege user. Server-to-server callers use a private bearer token; browsers use a short-lived session cookie — and logging out, or a session expiring, closes even open live-log streams within seconds.
Single sign-on via OIDC
Bring your identity provider — Okta, Entra ID, Google, Keycloak — over the OIDC authorization-code flow with PKCE and full ID-token verification. SSO sign-ins must map to an existing local account: nothing is auto-provisioned, and provider errors surface as fixed, friendly messages rather than raw redirects.
An audit trail you can actually read
Logins and failed attempts, secret and credential changes, job edits, settings updates and git syncs are recorded in an append-only audit trail — names and metadata only, never values — viewable and filterable right in the console under Settings → Audit.
Hardened inbound webhooks
Each inbound trigger URL is guarded by a per-hook token stored only as a SHA-256 hash and compared in constant time. Tokens are revealed once at mint and rotatable in one click — and wrong, missing or unknown tokens all get the same generic 401, so there is nothing to probe.
Git-audited, reversible history
Every job definition is a file in a git repository you own. Each change is a commit — fully diffable, attributable and reversible. Your job history is auditable with the tools your team already uses.
Honest about the trust boundary
Cronable’s job is to run commands, AI agents and HTTP on your behalf, so treat it like a shell on the box. Expressions run in a footgun-guard sandbox, not a hardened boundary — never feed it untrusted input. We help you deploy it with least privilege and sensible network isolation.
Run it behind your firewall.
Have security requirements to meet? Tell us your environment and we’ll walk through deployment, hardening and access controls together.