@dura-run/cli

Command-line tool for dura.run — deploy TypeScript and JavaScript automations with one command.

Install

npm install -g @dura-run/cli

Quickstart

# 1. Authenticate
dura login

# 2. Create a new project with a POST endpoint
dura new my-api --trigger post
cd my-api

# 3. Run it locally
dura dev
# → http://localhost:3000/hello

# 4. Deploy
dura deploy

# 5. Trigger it in the cloud — the project ID comes from dura.json
dura run hello

Common commands

| Command | Purpose | |---|---| | dura new <name> | Scaffold a new project (--trigger get\|post\|cron) | | dura init | Add dura.json to an existing directory | | dura dev | Local dev server with hot reload | | dura deploy | Deploy to the dura cloud | | dura pull | Recover a deployment's source from the platform into a directory (inverse of dura deploy) | | dura export | Snapshot the local project directory to a dura-export-v1 JSON file (a local copy — for platform recovery use dura pull) | | dura logs --follow | Tail execution logs | | dura secrets set KEY value | Store a secret for an automation | | dura endpoint-keys create <name> | Issue an API key for private HTTP triggers | | dura diagnose <exec-id> | AI-powered analysis of a failed execution |

Project & org resolution

Every project-scoped command resolves the project ID through the same chain:

1. --project <id> flag
2. projectId in the nearest dura.json, searching upward from the current directory (dura new writes it automatically; link an existing directory with dura config set projectId <id>)
3. defaultProjectId in the CLI config store
4. The DURA_PROJECT_ID environment variable (stateless CI)

So inside a project directory you never need --project. When nothing resolves, commands exit with a structured PROJECT_REQUIRED error that honors --json — never a bare usage error.

Org-scoped commands resolve the org the same way: --org <id> flag > defaultOrgId persisted by dura login / dura org use > DURA_ORG_ID environment variable > automatic discovery from your credential.

Security

dura dev runs your handlers in-process (GH #118)

dura dev loads your automation code via native import(...) in the CLI's Node process. That process has full access to your filesystem — including ~/.dura/config (where the CLI stores your API key), ~/.ssh, ~/.aws, and environment variables. A malicious npm dependency anywhere in your handler's import graph could read those files and exfiltrate them on the first request.

To make this risk explicit, dura dev refuses to start whenever you have credentials stored locally unless you opt in per project:

# Option 1 — pass --trust (recommended; acknowledges the risk once)
dura dev --trust

# Option 2 — set an env var (useful in scripts / devcontainers)
DURA_DEV_TRUST=1 dura dev

# Option 3 — log out first (removes the credentials being protected)
dura logout
dura dev

Acceptance is recorded in .dura/dev-trust inside your project, so subsequent runs proceed without re-prompting. The warning banner is still printed each time as a reminder. Delete .dura/dev-trust to revoke trust for the project. Add the file to .gitignore if you don't want to share your acceptance with collaborators.

Treat dura dev with the same trust you'd give node -e ... in a project that imports every one of your dependencies — audit your package.json (and lockfile) before trusting a new project.

The trust gate is the permanent mitigation. We evaluated a full isolated-vm migration for local dev in GH #147 and declined it: the threat window is narrow (malicious deps mostly fire at install or require-time, which sandboxing dura dev wouldn't help with), and the engineering cost is high relative to the mitigation. Production handlers run in a real V8 isolate via the executor service. See docs/internal/architecture.md for the threat-model decision.

Documentation

Full docs and recipes at docs.dura.run.

License

Apache 2.0