Every job CronDrive fires is encrypted, ownership-checked, and watched for failure — on every plan, from the very first run. This page is the honest, code-backed account of how that works: what we enforce, where we enforce it, and what we don't claim.
We can't read your secretsHeaders are sealed with Vault Transit and opened only at fire time — never in our database, never in our logs.
We fire only where you've proven you ownSub-minute jobs require a verified destination, and every target is resolved and range-checked before a single byte leaves the fleet.
A failing job stops itselfRepeated failures auto-disable the job and record the last error — so a dead endpoint never becomes a silent incident.
Included on every planNo security paywall. No "enterprise add-on."The same enforcement runs for every account — it's the engine, not a SKU.
01/Secrets
Your headers never sit in plaintext.
Request headers — the place your Authorization tokens and API keys live — are encrypted with HashiCorp Vault Transit envelope encryption and decrypted only at the moment a job fires. The key never leaves Vault, so a database dump is opaque ciphertext, and we can't read your secrets either.
Envelope-encrypted via Vault Transit Decrypted just-in-time at fire Never logged in clear
Prove you control a host once with a DNS TXT record or an HTTPS .well-known file. Sub-minute schedules (interval under 60 seconds) require a verified destination — there's no high-frequency firing at endpoints you don't control. The verification fetch itself runs through the same SSRF egress checks as a real fire.
DNS-TXT challenge HTTPS .well-known file Required for sub-minute jobs
02 — A crondrive-verify token, resolved to a passing ownership seal.
03/Network
No firing into private networks.
Every target is resolved, then each resolved address is checked against private, loopback, link-local, and cloud-metadata ranges — including 169.254.169.254. If it passes, the connection is pinned to the exact resolved address, closing the DNS-rebinding window between the check and the fire. The control plane checks at write time; the runner re-checks and pins at fire time.
Resolve-then-pin Metadata IP blocked Re-checked at fire time
resolve api.acme.co→203.0.113.7A record
203.0.113.7 — public rangeALLOW
10.0.0.0/8 — privateDENY
127.0.0.1 — loopbackDENY
169.254.169.254 — metadataDENY
Connection pinned to 203.0.113.7 for this fire.
03 — Each resolved address checked against deny-ranges, then the dial is pinned.
04/Reliability
A failing job disables itself — and tells you why.
When a job fails repeatedly, CronDrive disables it automatically and records the last failure: error type, response status, latency, and when. Permanent errors — a blocked SSRF target, a TLS verification failure, a hard client error — disable on the spot. No more silent runaway retries against a dead endpoint.
Auto-disable on threshold Last-failure detail recorded One-click re-enable
daily-report Auto-disabled
attempt 18tls · handshake failed
attempt 19tls · handshake failed
attempt 20tls · handshake failed
Threshold reached → disabled 3h ago
04 — Consecutive failures cross the threshold; the last failure is kept on record.
05/Redaction
Error snippets are scrubbed before they're stored.
When a fire fails, we keep a short, bounded slice of the response so you can debug it. Before it's stored — and before anything reaches our logs — sensitive values are redacted: bearer and basic credentials, API keys, tokens, URL passwords, and other secret-shaped strings. Redaction runs first, then truncation, so a secret straddling the cut is still removed.
Secret-shaped values scrubbed Redacted in logs and at rest Bounded snippet, redact-then-truncate
Raw failure response
status 401 Unauthorized authorization:Bearer acme_live_4f9c2a8e1b… message:"token rejected for tenant acme"
What we store
status 401 Unauthorized authorization: Bearer [REDACTED] message:"token rejected for tenant acme"
05 — Credentials redacted; the useful, non-sensitive context is preserved.
06/Isolation
Your account is walled off — and bounded.
Every row carries an account key, and every query is scoped to it: a job from another account is indistinguishable from one that doesn't exist (you get a 404, not a leak). Per-account quotas and rate limits keep any single account — runaway or hostile — from starving the fleet. Jobs are partitioned across runners by an ownership hash, so exactly one runner fires each job: no double-fires.
Account key on every row Per-account quotas & rate limits One runner owns each job
Jobs per account quotaup to 100
Aggregate fire rate quotacapped per account
API requests · write rate30 / min
API requests · auth rate10 / min
Job ownership runnerhash(jobId) % N
query · scoped readaccount = you
SELECT job WHERE owner = you200 · OK
SELECT job WHERE owner = someone else404 · NOT FOUND
A cross-account row is indistinguishable from a missing one.
06 — Account scoping turns a cross-tenant probe into an ordinary 404.
Honest scope
What's enforced today — and what we don't claim.
Security marketing should be falsifiable. Here's the line, drawn plainly.
Enforced in code, today
Vault-encrypted header secrets
Envelope encryption via Vault Transit; decrypted only at fire time, never logged.
SSRF range-checks with connection pinning
Private, loopback, link-local and metadata ranges blocked; the dial is pinned to the resolved address.
Ownership verification for sub-minute jobs
DNS-TXT crondrive-verify or an HTTPS well-known file, gated at job create and update.
Auto-disable, redaction & per-account isolation
Failure auto-disable with last-failure detail, scrubbed snippets, account-scoped queries, quotas and rate limits.
Not claimed (yet)
No compliance certifications
We make no SOC 2, ISO, PCI, or HIPAA claims — none exist. We won't pretend otherwise.
No uptime SLA
CronDrive is in early access. There's no contractual uptime or availability guarantee today.
Verification is one-time, not continuous
Once a host is verified it stays verified; we don't yet re-poll for ownership changes.
Redirects aren't re-validated on the fire path
The egress check runs on the target you set. A target that returns an HTTP redirect is followed by the client — so point jobs at endpoints you trust.
Responsible disclosure
Found something? Tell us first.
If you believe you've found a vulnerability, email us before disclosing it publicly and give us a reasonable window to fix it. We read every report, we won't pursue good-faith research, and we'll keep you posted on the fix.
No bug-bounty program or formal SLA yet — just a real inbox and a commitment to act on what you send.