Secrets encrypted with Vault Transit

Cron jobs you can trust to run — and to fail safely.

CronDrive encrypts your secrets, fires only where you've proven you own the host, and disables jobs that keep failing — so a broken endpoint never quietly becomes an incident.

Ownership-verified SSRF-safe firing Distributed fleet
01Secrets

Your headers never sit in plaintext.

Authorization headers and API keys are encrypted with HashiCorp Vault Transit and decrypted only at the moment a job fires. We can't read them — and neither can anyone with database access.

Envelope-encrypted Decrypted just-in-time 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 → Transit envelope → opaque ciphertext.
02Destinations

We only fire where you've proven you own.

Verify a destination once with a DNS TXT record or a .well-known file. Sub-minute jobs require a verified host — there's no firing at endpoints you don't control.

DNS-TXT challenge .well-known file Re-checked periodically
Add to DNS for api.acme.co
_crondrive-verify  TXT
"cdv=8f3c2a91d4e7b05c"
Ownership verifiedapi.acme.co · checked 2 min ago
PASS
02 — DNS-TXT challenge resolves to a passing ownership seal.
03Network

No firing into private networks.

Every target is resolved, then checked against private, loopback, and cloud-metadata ranges. The connection is pinned to the resolved address — closing the DNS-rebinding window between check and fire.

Resolve-then-pin Metadata IP blocked No DNS rebinding
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 — Resolved address checked against deny-ranges, then 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, and when. No more silent runaway retries against a dead endpoint.

Auto-disable threshold Last-failure detail One-click re-enable
daily-report Auto-disabled
attempt 1tls · handshake failed
attempt 2tls · handshake failed
attempt 3tls · handshake failed
attempt 4tls · handshake failed
attempt 5tls · handshake failed
Threshold reached → disabled 3h ago
04 — Repeated failures cross the threshold and disable the job.
Standard provisions

Everything a scheduler should already do.

Built into the engine — not a paid add-on, not a roadmap promise.
A distributed fleet that owns its jobs.
Jobs are partitioned across runners by ownership hash — exactly one runner fires each job. No double-fires, no coordination overhead.
● owns this job○ standby

a. Cron & interval

5-field cron with IANA timezones, or simple intervals down to the second.

b. Quotas & rate limits

Per-account ceilings keep a runaway job from starving the fleet.

c. PII redaction

Sensitive values are scrubbed from stored error snippets — never kept in the clear.

d. Near-real-time changes

Enable, disable, or edit a job and the fleet picks it up in seconds via the change-feed.

Procedure

From zero to firing — safely.

Three steps. The hard parts are handled by the runner.

Create a job

URL, method, headers, and a cron or interval schedule.

Verify the destination

Prove you own the host once — a DNS-TXT record or a well-known file.

CronDrive fires safely

On schedule, from the fleet — and it watches for failures so you don't have to.

Good to know

Questions, answered.

Honest about what ships today versus what's reserved.
How are my secrets kept safe?
Request headers — API keys, bearer tokens — are encrypted with HashiCorp Vault Transit and decrypted only at fire time. They're never stored or logged in plaintext, so nobody with database access can read them.
What is destination verification, and do I always need it?
You prove you own a host once with a DNS TXT record or a .well-known file. It's required for sub-minute jobs (interval < 60s); jobs that run less often can fire at any reachable public host.
What happens when an endpoint keeps failing?
CronDrive auto-disables the job so it stops burning attempts against a dead endpoint, and records the last failure — error type, response status, and when. You fix the endpoint and re-enable it in one click.
Can CronDrive call internal or private URLs?
No — and that's deliberate. Every target is resolved and checked against private, loopback, and cloud-metadata ranges, then pinned to the resolved address. It only fires at public endpoints you control.
What schedules are supported?
Standard 5-field cron expressions with IANA timezones, or fixed intervals down to the second.
Do you keep a history of every run?
Today we surface the next run and the last failure for each job. A full run-history timeline is on the roadmap — the dashboard already reserves space for it.
What does it cost?
CronDrive is free during early access — no card required. Start with one job.
Early access · no card required

Start with one job.

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