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 machine — a Mac or Windows desktop app, or a server under systemd/launchd. There is no SaaS tier and no cloud dependency. Its routine outbound calls are a periodic licence check — which confirms your subscription and reports simple job and user counts — and a check for new signed releases; and, only if you switch them on, an outbound connection to Cronable’s hosted relay for inbound webhooks or remote control. Your workload — job definitions, secrets, runs and outputs — stays on the box and is never sent to us. The one exception is an active remote-control session: its dashboard traffic is relayed through our edge (the same trust as any hosted proxy), with end-to-end encryption to your own machine a planned Enterprise option.
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. Passwords must also clear a strength check — a minimum length plus a guessability test — so weak or easily-guessed ones are rejected. Optional two-factor authentication (TOTP) adds a one-time code from an authenticator app such as Google Authenticator, with recovery codes for a lost device; it is required to use remote access, so a machine can only be opened to the hosted dashboard by an operator who has it enabled.
Team access with roles
The web console is multi-user, with four ordered roles — viewer (read-only), editor (author jobs, secrets and runs), admin (manage users, roles and settings), and owner, the install’s first account. Admins add and remove users, set each person’s role, reset a password or two-factor device, and revoke access under Settings → Users — so a departing teammate loses access at once and nobody shares a login. Locked-down installs can opt into more: exec-tiering restricts who may create command-running jobs, and change-approval adds four-eyes review, so a second admin must approve a staged job or secret change before it takes effect.
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
Inbound webhooks reach your daemon through our license-gated relay over a connection your server opens outbound, so you never expose a port — unless you deliberately choose to. Each hook is bound to your license — no other customer can claim it or receive its events, even knowing its URL — and guarded by a per-hook token stored only as a SHA-256 hash and checked in constant time. The URL needs at least 32 unguessable characters plus that token; wrong, missing, disabled or unknown all return the same generic 401, and repeated probes from an IP are temporarily banned — so there is nothing to enumerate and nothing to brute-force. Tokens are revealed once at mint and rotatable in one click. If you would rather inbound payloads never transit our servers at all, you can skip the relay and serve your own HTTPS endpoint instead — that is the one case where you do open a port, and webhooks then arrive straight at your machine.
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. When you link a repository for two-way sync, Cronable accepts only a private one — it refuses a public repo, and stops syncing if a linked repo is later made public — so your job definitions can never become world-readable.
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.
Cronable, and it never leaves your box.