--project [--parent ]` | create a folder |
| `druntime folder rename` · `move` · `delete ` | rename, move or delete a folder |
| `druntime link --project [--env ]` | link this folder to a project and environment |
| `druntime unlink` | remove this folder's link |
## Environments [#environments]
| Command | |
| --------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `druntime env create --project [--folder ] [--mode dev\|prod] [--client-org ]` | create an environment; prints its handle |
| `druntime env open [--env ] [--once] [--no-clients]` | start or reattach the development session |
| `druntime push [--env ] [--yes] [--no-site] [--delete ] [--rename ]` | put the folder's domain live on its environment: publish to a development environment, [release](#releasing-to-production) to a production one. `--yes` confirms removals of what the domain declared (and, for production, the release itself), `--delete` confirms one by name, `--rename` keeps an attribute and its data under a new name, `--no-site` releases the domain without the folder's [Site](#the-folders-site). See [Changing the schema](/docs/data/modeling-data#changing-the-schema) |
| `druntime schema deleted` | what was removed from the schema in the last 2 days |
| `druntime schema restore ` | bring a removed entity or attribute back, with its data |
| `druntime env pull [] [--project ] [--no-code]` | bring the environment's code and public configuration into this folder |
| `druntime env run -- ` | run a command with the environment's configuration |
| `druntime env stop [--env ]` | stop the development machine; data is kept |
| `druntime env delete [--yes] [--confirm=] [--force]` | [delete an environment](#deleting-an-environment); restorable for 2 days |
| `druntime env restore ` | bring a deleted environment back, with its data |
## Common options [#common-options]
| Option | Applies to |
| ---------------- | ------------------------------------------------------------------------------------ |
| `--env ` | push, run, query and environment commands; otherwise the folder's linked environment |
| `--org ` | project, folder and environment commands; otherwise the selected organization |
| `--json` | most commands: structured output for scripts and agents |
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 [#releasing-to-production]
```bash
druntime push --env prod-acme-main # asks, then releases
druntime push --env prod-acme-main --yes # CI
```
```text
✔ 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.
```text
✘ 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 [#the-folders-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://.domainruntime.site`. Domain and Site go live, and roll back, together. The app is declared in `.domainruntime/site.json`:
```json
{ "access": "organization", "root": "app", "enabled": true }
```
| Key | Meaning |
| --------- | ------------------------------------------------------------------------------------------------------------------------------ |
| `access` | who the Site serves: `organization` (default, members of the environment's organization), `users` (anyone signed in), `public` |
| `root` | the app's folder, when it is not the folder itself |
| `enabled` | `false` releases the domain alone on every push from this folder (default `true`) |
To release only the domain once, pass `--no-site`:
```bash
druntime push --env prod-acme-main --yes --no-site
```
```text
✔ 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](/docs/auth/service-keys) 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:
```text
├─ released by ada@acme.dev (you)
├─ runner provisioned · environment credential
```
## Deleting an environment [#deleting-an-environment]
```bash
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
```
```text
✔ 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 ` 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 [#data-and-actions]
| Command | |
| ------------------------------------------------------------------------- | ---------------------------------------------------------------- |
| `druntime run [--input '' \| @file.json \| -] [--env ]` | run an action as you and print its output |
| `druntime query '' [--env ]` | run a [query](/docs/data/reading-data) as you and print the rows |
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.
```text
$ 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)* [#releases-planned]
| Command | |
| ------------------------------------- | -------------------------------- |
| `druntime release rollback --env ` | re-activate the previous release |
## Keys *(planned)* [#keys-planned]
| Command | |
| -------------------------------------------------------------- | ---------------------------------------- |
| `druntime keys create --name [--env \| --project ]` | a [service key](/docs/auth/service-keys) |
| `druntime keys list` · `revoke ` | list or revoke keys |