Deploy to Deno Deploy

Goal: push a NetScript workspace to Deno Deploy with a single first-class command — netscript deploy deno-deploy <op> — preflighting it for the hosted platform, pushing a preview, promoting to production, and reading status and logs, without hand-rolling a deno deploy invocation.

This is the one runnable managed-platform path in NetScript today. It is a thin router over the native deno deploy CLI: NetScript resolves your deploy.targets['deno-deploy'] config, layers any flags on top, runs an unstable-API guard, and shells out to deno deploy. Authentication, upload, and the platform itself are all owned by the deno deploy CLI — NetScript adds the preflight and the config-to-argv wiring, nothing more.

Before you start

Configure the target (deploy.targets['deno-deploy'])

Set defaults once in netscript.config.ts under deploy.targets['deno-deploy']. Every field is optional — you can pass everything as flags instead — but config keeps a repeatable push to one line.

// netscript.config.ts
export default {
  deploy: {
    targets: {
      "deno-deploy": {
        org: "my-org",          // Deno Deploy organization slug  → deno deploy --org
        app: "my-app",          // application / project name      → deno deploy --app
        entrypoint: "main.ts",  // default "main.ts"               → positional arg to deno deploy
        prod: false,            // default false; true adds --prod
        envFile: ".env.production", // passed as `--env-file <path>` to deno deploy
      },
    },
  },
};

The workflow: plan → preview → production

The command exposes five operations. All five share the same resolution flags; up adds two more.

A typical first deployment walks these steps:

# Guard-only. No push, no platform mutation. Safe to run any time.
netscript deploy deno-deploy plan --org my-org --app my-app

# Equivalent, via up:
netscript deploy deno-deploy up --dry-run --org my-org --app my-app

# Push a preview deployment (no --prod). If the guard finds unstable-API
# usage it warns but still proceeds for a preview.
netscript deploy deno-deploy up --org my-org --app my-app

# Promote to production. If the guard finds unstable-API usage, this
# REFUSES to push (see the guard callout).
netscript deploy deno-deploy up --prod --org my-org --app my-app

# Read state and logs, or delete the deployment.
netscript deploy deno-deploy status --org my-org --app my-app
netscript deploy deno-deploy logs   --org my-org --app my-app
netscript deploy deno-deploy down   --org my-org --app my-app

If your netscript.config.ts already carries the org/app/entrypoint, every line above shortens to just netscript deploy deno-deploy <op> — the config supplies the rest, and any flag you add wins for that run.

The unstable-API guard

Before any push, NetScript runs a best-effort unstable-API guard. Deno Deploy rejects --unstable-* flags, so a project that depends on an unstable API cannot run there — the guard catches this before you upload rather than after the platform rejects it.

Many NetScript runtime plugins (workers, sagas, triggers) require Deno KV and therefore --unstable-kv. Those background processors are not a fit for a single Deno Deploy isolate — deploy a KV-free entrypoint (for example a Fresh app or a stateless oRPC service) here, and run the KV-backed processors on infrastructure that permits --unstable-kv, as covered in the Deploy recipe.

Troubleshooting

Where to go next

For every CLI command grouped by workflow, see the CLI reference.