Databases, cron, and timelines

The new Deno Deploy is organized around apps, revisions, timelines, and contexts. Production, Git branches, and previews can serve different revisions with separate environment values and logical databases.

Databases

The platform currently supports associated PostgreSQL or Deno KV databases. Production, branch, and preview timelines receive isolated logical databases for each app.

const kv = await Deno.openKv();

Deno.serve(async () => {
  await kv.set(["health", "lastSeen"], new Date().toISOString());
  return Response.json({ ok: true });
});

PostgreSQL connections inject standard DATABASE_URL, PGHOST, PGPORT, PGDATABASE, PGUSER, and PGPASSWORD. A migration task can run as a pre-deploy command before a revision serves traffic.

Cron

Deno.cron("daily cleanup", "0 3 * * *", async () => {
  await runCleanup();
});

Cron schedules use UTC. Deploy discovers jobs during deployment, handles scheduling, and exposes runs in dashboard logs and traces. Failures are not retried by default; opt in per job with backoffSchedule (up to 5 attempts, each delay capped at 1 hour). Jobs must be idempotent; when a retry overlaps the next scheduled run, the later invocation may be skipped.

Context and environment

• Production: the production timeline.
• Development: branch and preview timelines.
• Build: visible only during builds, not automatically at runtime.
• Secrets are hidden in the UI after creation; never echo them through logs.

Use DENO_TIMELINE, DENO_DEPLOY_APP_ID, and deployment identifiers as observability dimensions, not access-control decisions.

Official sources: Databases, Cron, Timelines, and Environment contexts.