Labsco
denoland logo

deno-deploy

87

by denoland · part of denoland/skills

Use when deploying Deno apps to production, asking about Deno Deploy, or working with `deno deploy` CLI commands. Covers deployment workflows, environment…

🔥🔥🔥✓ VerifiedFreeQuick setup
🧩 One of 7 skills in the denoland/skills package — works on its own, and pairs well with its siblings.

Use when deploying Deno apps to production, asking about Deno Deploy, or working with `deno deploy` CLI commands. Covers deployment workflows, environment…

Inspect the full instructions your agent will receiveExpand

This is the exact playbook injected into your agent when the skill activates — shown here so you can audit it before installing. You don't need to read it to use the skill.


name: deno-deploy description: Use when deploying Deno apps to production, asking about Deno Deploy, or working with deno deploy CLI commands. Covers deployment workflows, environment variables, KV database access, custom domains, the --tunnel flag for local development, and the deno deploy command reference. license: MIT metadata: author: denoland version: "1.5"

Deno Deploy

This skill provides guidance for deploying applications to Deno Deploy.

Scope Boundaries

This skill applies only to Deno Deploy questions. Follow these rules:

  • If the user asks about AWS Lambda, Vercel, Netlify, Google Cloud Run, Docker, Kubernetes, or any other deployment platform, answer using that platform directly. Do not mention Deno Deploy at all — not as an alternative, not as a comparison, not as a suggestion.
  • If the user asks about running a local Deno script (not deploying), answer the local question directly. Do not mention Deno Deploy, deployment, or the --tunnel flag.
  • Do not include deno deploy commands, Deno KV, or Deno Deploy environment variable configuration in responses about other platforms or local-only scripts.
  • Only discuss Deno Deploy when the user explicitly asks about Deno Deploy or deploying a Deno application to production.

When Unsure About CLI Flags

Always run --help before guessing at flags. The deno deploy subcommand has many flags, and they change between versions. When you're unsure what a command accepts:

Copy & paste — that's it
# See all subcommands
deno deploy --help

# See flags for a specific subcommand
deno deploy create --help
deno deploy env --help
deno deploy database --help

This takes seconds and prevents repeated trial-and-error failures. Never assume a flag exists — check first.

Core Commands

Production Deployment

Copy & paste — that's it
deno deploy --prod

Preview Deployment

Copy & paste — that's it
deno deploy

Preview deployments create a unique URL for testing without affecting production.

Targeting Specific Apps

Copy & paste — that's it
deno deploy --org my-org --app my-app --prod

Configuring an Entrypoint

Set the entrypoint in your deno.json (this is used by deno deploy create during app creation):

Copy & paste — that's it
{
  "deploy": {
    "entrypoint": "main.ts"
  }
}

Note: --entrypoint is a flag on deno deploy create, not on deno deploy itself.

Additional Flags

These flags are available on deno deploy create (and apply during the initial deploy):

FlagPurpose
--allow-node-modulesInclude node_modules directory in upload
--no-waitSkip waiting for the build to complete

Creating Apps (Non-Interactive Reference)

When any flag beyond --org is provided, deno deploy create runs in non-interactive mode — all required flags must be specified. This is the recommended approach for AI agents and CI/CD pipelines.

Required Flags

FlagDescription
--org <name>Organization name
--app <name>Application name (becomes your URL: <app>.deno.dev)
--source <local|github>Deploy from local files or a GitHub repo
--build-timeout <minutes>Build timeout: 5, 10, 15, 20, 25, or 30
--build-memory-limit <MB>Memory limit: 1024, 2048, 3072, or 4096
--region <region>Deployment region: us, eu, or global

GitHub Source Flags

When using --source github, you also need:

FlagDescription
--owner <name>GitHub repository owner
--repo <name>GitHub repository name

Build Configuration Flags

FlagDescription
--app-directory <path>Path to app directory (for monorepos)
--framework-preset <preset>Framework preset (see Frameworks)
--install-command <cmd>Custom install command
--build-command <cmd>Custom build command
--pre-deploy-command <cmd>Command to run before deploy
--do-not-use-detected-build-configSkip auto-detection of framework config

The CLI auto-detects your framework and build configuration. If a framework is detected, you can skip --install-command, --build-command, --pre-deploy-command, and --runtime-mode — they'll be inferred from the preset. Use --do-not-use-detected-build-config to override detection. When using this flag, all three build commands (--install-command, --build-command, --pre-deploy-command) plus --runtime-mode become required — omitting any of them causes exit code 2.

Runtime Mode Flags

You must pick a runtime mode with --runtime-mode <dynamic|static> (unless a framework preset handles it).

Dynamic mode (for apps with a server):

FlagDescription
--entrypoint <path>Entry file (required for dynamic mode)
--arguments <args>Arguments passed to entrypoint (repeatable)
--working-directory <cwd>Working directory for the process

Static mode (for static sites):

FlagDescription
--static-dir <dir>Directory to serve static files from (required)
--single-page-appServe index.html for routes that don't match a file

Other Flags

FlagDescription
--dry-runValidate everything without actually creating the app
--no-waitDon't wait for the build to complete
--allow-node-modulesInclude node_modules in the upload

Examples

Simple Deno server:

Copy & paste — that's it
deno deploy create \
  --org my-org --app my-api \
  --source local \
  --runtime-mode dynamic --entrypoint main.ts \
  --build-timeout 5 --build-memory-limit 1024 --region us

Fresh app (framework auto-detected):

Copy & paste — that's it
deno deploy create \
  --org my-org --app my-fresh-app \
  --source local \
  --build-timeout 5 --build-memory-limit 1024 --region us

Next.js from GitHub:

Copy & paste — that's it
deno deploy create \
  --org my-org --app my-next-app \
  --source github --owner my-github-user --repo my-next-repo \
  --framework-preset Next \
  --build-timeout 15 --build-memory-limit 2048 --region us \
  --allow-node-modules

Static site:

Copy & paste — that's it
deno deploy create \
  --org my-org --app my-static-site \
  --source local \
  --runtime-mode static --static-dir dist --single-page-app \
  --build-command "deno task build" \
  --build-timeout 5 --build-memory-limit 1024 --region us

Environment Variables

Contexts

Deno Deploy has three "contexts" - logical environments where your code runs, each with its own set of variables:

ContextPurpose
ProductionLive traffic on your production URL
DevelopmentPreview deployments and branch URLs
BuildOnly available during the build process

You can set different values for the same variable in each context. For example, you might use a test database URL in Development and the real one in Production.

Predefined Variables

These are automatically available in your code:

VariableDescription
DENO_DEPLOYAlways 1 when running on Deno Deploy
DENO_DEPLOYMENT_IDUnique ID for the current deployment
DENO_DEPLOY_ORG_IDYour organization's ID
DENO_DEPLOY_APP_IDYour application's ID
CISet to 1 during builds only

Accessing Variables in Code

Copy & paste — that's it
const dbUrl = Deno.env.get("DATABASE_URL");
const isDenoDeploy = Deno.env.get("DENO_DEPLOY") === "1";

Managing Variables via CLI

Copy & paste — that's it
# Add a plain text variable
deno deploy env add DATABASE_URL "postgres://..."

# Add a secret variable (hidden after creation, only readable in code)
deno deploy env add API_KEY "sk-..." --secret

# List all variables
deno deploy env list

# Update just the value (keeps contexts and secret status)
deno deploy env update-value DATABASE_URL "postgres://new-url..."

# Update which contexts a variable applies to
deno deploy env update-contexts DATABASE_URL production development

# Delete a variable
deno deploy env delete DATABASE_URL

# Load from .env file (all values treated as secrets by default)
deno deploy env load .env.production

# Load from .env file, marking specific keys as non-secrets
deno deploy env load .env.production --non-secrets PUBLIC_URL APP_NAME

Variable Types

  • Plain text - Visible in the dashboard, good for feature flags and non-sensitive config
  • Secrets - Hidden after creation, only readable in your code, use for API keys and credentials

Limits

  • Key names: max 128 bytes
  • Values: max 16 KB
  • Keys cannot start with DENO_, LD_, or OTEL_

Viewing Logs

Copy & paste — that's it
# Stream live logs
deno deploy logs

# Filter by date range
deno deploy logs --start 2026-01-15 --end 2026-01-16

Databases & Storage

Deno Deploy provides built-in database support with automatic environment isolation. Each environment (production, preview, branch) gets its own isolated database automatically.

Available Options

EngineUse Case
Deno KVKey-value storage, simple data, counters, sessions
PostgreSQLRelational data, complex queries, existing Postgres apps

Deno KV Quick Start

No configuration needed - just use the built-in API:

Copy & paste — that's it
const kv = await Deno.openKv();

// Store data
await kv.set(["users", "alice"], { name: "Alice", role: "admin" });

// Retrieve data
const user = await kv.get(["users", "alice"]);
console.log(user.value); // { name: "Alice", role: "admin" }

// List by prefix
for await (const entry of kv.list({ prefix: ["users"] })) {
  console.log(entry.key, entry.value);
}

Deno Deploy automatically connects to the correct database based on your environment.

PostgreSQL

For PostgreSQL, Deno Deploy injects environment variables (DATABASE_URL, PGHOST, etc.) that most libraries detect automatically:

Copy & paste — that's it
// Recommended: npm:pg (best PostgreSQL driver for Deno Deploy)
import pg from "npm:pg";
const pool = new pg.Pool(); // Reads DATABASE_URL from environment automatically

Provisioning

Use the deno deploy database command to provision and manage databases:

Copy & paste — that's it
# Provision a Deno KV database
deno deploy database provision my-database --kind denokv

# Provision a Prisma PostgreSQL database
deno deploy database provision my-database --kind prisma --region us-east-1

# Assign to your app
deno deploy database assign my-database --app my-app

For detailed CLI commands, see Databases.

Local Development

Use --tunnel to connect to your hosted development database locally:

Copy & paste — that's it
deno task --tunnel dev

See Databases and Deno KV for detailed documentation.

Local Development Tunnel

The tunnel feature lets you expose your local development server to the internet. This is useful for:

  • Testing webhooks - Receive webhook callbacks from external services
  • Sharing with teammates - Let others preview your local work
  • Mobile testing - Access your local server from other devices

Basic Usage

Add the --tunnel flag when running your app:

Copy & paste — that's it
deno run --tunnel -A main.ts

The first time you run this, it will:

  1. Ask you to authenticate with Deno Deploy (opens a browser)
  2. Ask you to select which app to connect the tunnel to
  3. Generate a public URL that forwards requests to your local server

Using with Tasks

You can use --tunnel with your existing tasks in deno.json:

Copy & paste — that's it
deno task --tunnel dev

This runs your dev task with the tunnel enabled.

What the Tunnel Provides

Beyond just forwarding requests, the tunnel also:

  • Syncs environment variables - Variables set in your Deno Deploy app's "Local" context become available to your local process
  • Sends logs and metrics - OpenTelemetry data goes to the Deno Deploy dashboard (filter with context:local)
  • Connects to databases - Automatically connects to your assigned local development databases

Managing Tunnels

  • View active tunnels in the Deno Deploy dashboard under the "Tunnels" tab
  • Stop a tunnel by terminating the Deno process (Ctrl+C)

Command Reference

CommandPurpose
deno deploy --prodDeploy to production (app must exist first)
deno deployPreview deployment
deno deploy create --org <name>Create new app (interactive)
deno deploy create --org <name> --app <name> ...Create new app (non-interactive, see full flags above)
deno deploy create ... --no-waitCreate app without waiting for build to complete
deno deploy create ... --allow-node-modulesCreate app including node_modules
deno deploy env add <var> <value>Add plain text environment variable
deno deploy env add <var> <value> --secretAdd secret environment variable
deno deploy env listList environment variables
deno deploy env update-value <var> <value>Update variable value (keeps contexts/secret status)
deno deploy env update-contexts <var> <contexts...>Update which contexts a variable applies to
deno deploy env delete <var>Delete environment variable
deno deploy env load <file>Load variables from .env file (defaults to secret)
deno deploy env load <file> --non-secrets <keys...>Load .env file, marking specific keys as non-secrets
deno deploy database provision <name> --kind <type>Provision a new database
deno deploy database assign <name> --app <app>Assign database to an app
deno deploy logsView deployment logs
deno run --tunnel -A <file>Start local tunnel
deno task --tunnel <task>Run task with tunnel

Edge Runtime Notes

Deno Deploy runs in one or many regions (globally distributed). Keep in mind:

  • Environment variables - Must be set via deno deploy env, not .env files at runtime
  • Global distribution - Code runs at the region closest to users
  • Cold starts - First request after idle may be slightly slower

Additional References

Documentation