Security posture Vault Transit SSRF-safe

Security is standard, not a tier.

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.
01Secrets

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
What you enter
AuthorizationBearer acme_live_4f••
X-Api-Keycdk_9a2c••••
What we store
vault:v1:k8Hd2Qpf6rLm9cIp…h3rTeXtZ
Ciphertext at rest
01 — Plaintext header map → Transit envelope → opaque ciphertext in Postgres.
02Destinations

We fire only where you've proven you own.

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
Add to DNS for api.acme.co
api.acme.co  TXT
"crondrive-verify=8f3c2a91d4e7b05c…"
Ownership verifiedapi.acme.co · confirmed once
PASS
02 — A crondrive-verify token, resolved to a passing ownership seal.
03Network

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.co203.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.
04Reliability

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.
05Redaction

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.
06Isolation

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
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.

Please includesteps · impact · scope
Our commitmentacknowledge, then update you
Early access · no card required

Encrypted, verified, and watched — from the first fire.

Start with one job. The security model isn't an upgrade you unlock later.