CLI

npm i -D @domainruntime/cli     # or run any command with npx @domainruntime/cli

The CLI is built on the Platform SDK: everything it does, you can also do from code.

Start

Account

Projects and folders

Environments

Common options

The development session (druntime, env open) never targets production. push releases to production only when the target is explicit — --env prod-… or the folder's link — and asks first (--yes in CI).

Releasing to production

druntime push --env prod-acme-main          # asks, then releases
druntime push --env prod-acme-main --yes    # CI

✔ Built locally  src/domain.ts · 3 files · 2 actions
✔ Uploaded  build 3f0c1b2e
⟳ Building on the platform  building
✔ Built on the platform  52 s
✔ Live  https://prod-acme-main.domainruntime.cloud
├─ environment  prod-acme-main
├─ build        3f0c1b2e-…
├─ released by  ada@acme.dev (you)
└─ schema       +2 attrs

1. The domain is built and loaded on your machine, the same check a development push makes.
2. Its files are uploaded as the release's source: the folder that holds them keeps its layout, and the packages they import are pinned to the versions you have installed. The release is built from your folder as it is, not from the project's repository.
3. The platform builds it. If the build fails, you see the compiler's messages at your files' paths, then the last lines of the build log; the current release keeps serving.
4. Activating the release applies its schema with the same checks and confirmations as in development, then prints the live URL.

✘ The build failed on the platform; the current release keeps serving.
├─ src/domain.ts:3:19
│  └─ An import path can only end with a '.ts' extension when 'allowImportingTsExtensions' is enabled.
└─ log
   ├─ Next.js build worker exited with code: 1 and signal: null
   └─ Error: Command "npx --yes pnpm@10.6.1 build" exited with 1

Imports must be relative (no path aliases such as @/lib/x) and domain files .ts or .json; push names any file that is not. A production release serves actions, so the domain needs at least one.

The folder's Site

When the folder's package.json depends on Next.js or Vite, a production push releases that app with the domain as the environment's Site, served at https://<handle>.domainruntime.site. Domain and Site go live, and roll back, together. The app is declared in .domainruntime/site.json:

{ "access": "organization", "root": "app", "enabled": true }

To release only the domain once, pass --no-site:

druntime push --env prod-acme-main --yes --no-site

✔ Built locally  src/domain.ts · 3 files · 2 actions
◇ Site not released  --no-site · the environment's Site stays as it is
✔ Uploaded  build 3f0c1b2e

A release without a Site does not remove one: the environment's Site keeps serving what was last released with it.

Who can release: an owner or admin of the organization, signed in as themselves, or the organization's service key in CI (DOMAIN_ORGANIZATION_KEY, with --yes). A member without that role is told so. Every release records who pushed it and who made it live, and push prints it (released by).

The first release of an environment also sets up its runner, the service that runs your actions. The platform gives the runner a credential of its own, valid for that environment only; you never see it, and your organization's key never leaves the platform. push says so once:

├─ released by  ada@acme.dev (you)
├─ runner       provisioned · environment credential

Deleting an environment

druntime env delete dev-orders-main-3f0c1b2e                   # asks first; --yes in CI
druntime env delete prod-acme-main                             # type the handle to confirm
druntime env delete prod-acme-main --confirm=prod-acme-main    # CI

✔ Deleted  prod-acme-main
├─ mode              production
├─ deleted by        ada@acme.dev (you)
└─ restorable until  2026-09-25 14:02 UTC  2 days, then its data is purged
❯ druntime env restore prod-acme-main  brings it back with its data

• It stops at once: its URL, actions and queries answer not found, its development machine stops, and it leaves every listing.
• Its data — records, files, streams and executions — is kept for 2 days. druntime env restore <handle> brings it all back, including a production environment's last release. After 2 days it is purged and cannot be restored.
• Only owners and admins of the organization (or its service key) can delete or restore an environment. Who did it, and when, is recorded.
• A production environment asks you to type its handle; --yes alone never deletes one. While custom domains still point at it, it is not deleted unless you pass --force.
• Its name is free for a new environment at once; its handle stays reserved until it is purged, so it can be restored.

If a deletion is interrupted, the environment has already stopped serving; run the same command again to finish it.

Data and actions

Both use --env or the folder's linked environment, and act as you: an action sees you as runtime.auth.user, a query returns what the environment's rules let you read.

$ druntime run orders.place --input '{"orderId":"8f1c…","total":10}'
✔ Ran  orders.place  dev-orders-alice-7f3k9x2m · 412 ms
└─ execution  0f5a…

{
  "orderId": "8f1c…"
}

$ druntime query '{"orders_order": {"$": {"limit": 5}}}'
✔ orders_order  2 rows
  id     total  status
  8f1c…  10     placed
  91d0…  25     paid

If the action does not run, run says why: an unknown action, the parts of the input that do not fit its schema, or the error your action threw. A lost answer is retried with the same request id, so the action never runs twice. --json prints the call's record for run and the objects for query.

Releases (planned)

Keys (planned)