> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ohmyho.st/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> For account actions, read https://ohmyho.st/skills/ohmyhost-get-started/SKILL.md and use the authenticated ohmyho.st CLI or local product MCP. Mintlify search only reads documentation. Preserve the customer’s selected project, environment and authentication provider.

# Dev and Prod

> Choose shared or isolated data, change assignments or reset Dev, select US or EU and Dev access, then deploy, promote, roll back or delete.

Each project has Dev and Prod under one organization credit balance. Choose `isolated` or `shared` data when creating the project (`--data-mode`); the optional default is `shared`. [Confirmed assignment changes](#change-data-assignments) can change it later without copying data.

| Mode | Databases and files | Implication |
| - | - | - |
| Isolated | Separate Dev and Prod resources | Safer testing; each database consumes credits independently. |
| Shared | One physical data set | Writes or schema changes can affect both environments. |

Skills recommend isolation and explain the credit difference. An explicit customer choice to share is supported.

## Choose who can open Dev

Before creating a project, your agent asks whether Dev should be **protected** or **public**. Protected is the default. Public lets anyone with the clean Dev URL open it without a platform token, even when Dev and Prod use shared data. Your application's own login remains separate.

For protected Dev, the Owner gets one reusable bearer link with `ohmyhost project dev-share link --project "$PROJECT_ID" --json` or MCP `project_dev_share_link_get`. The same `share_url` works for multiple visitors and has no automatic expiry. Opening it starts a 12-hour browser session and redirects to the clean Dev URL; the link can be opened again after that session ends. Keep it with the people you intend to admit, and do not put it in source, logs or project notes.

The Owner can change the mode with `ohmyhost project dev-access mode --project "$PROJECT_ID" --mode public|protected --idempotency-key "$KEY" --yes --json` (MCP `project_dev_access_mode_set`). `ohmyhost project dev-share rotate` (MCP `project_dev_share_link_rotate`) replaces the link; `ohmyhost project dev-share revoke` (MCP `project_dev_share_link_revoke`) removes access until a new link is obtained. Both actions block old links and browser sessions on their next request. A revoked browser navigation goes to ohmyho.st without forwarding its path or token. The link never grants Prod or account administration access. Protected Dev returns 404 to every request without a link session, including third-party webhooks; use public Dev or Prod for those integrations. Access is checked on every request, with about 1,200 requests/minute per project without a share session (including public Dev), or per session; every asset counts. A limit or unavailable check returns 503, so wait/retry and load-test Prod. Switching public revokes the link; its old URL opens public Dev, while switching back to protected issues a new link. Rotating a public Dev link returns `share_url: null` and changes nothing. Revoking a public Dev link also leaves it public.

## Choose a hosting region once

New projects choose US or EU. An explicit choice wins over any browser-location suggestion; with neither, the agent asks once and sends the chosen region explicitly. An existing project's region is preserved. The API default remains US, and the agent's own server IP is not the customer's location.

The choice places the project's database, files and builds, with the application next to its database. It cannot be changed later and consumption prices are identical. Transactional mail is processed in the US by the platform's mail provider, whatever the project's region. `storage.jurisdiction` must match the project's region.

## Read the actual environment

```sh theme={null}
ohmyhost project status --project "$PROJECT_ID" --json
ohmyhost project context --project "$PROJECT_ID" --json
```

Use the returned environment IDs for secrets and the returned logical environment selection for compute commands. Do not infer environment from a project name.

## Deploy to Prod

Prod first runs at the hosting address returned by `ohmyhost project status`, such as `HANDLE.check.omh.st`. Its DNS is already managed by ohmyho.st, so deploying needs no DNS changes to your own domain. You can [reserve a custom domain and authorize Cloudflare](/domains) beforehand; activate it with the original domain apply after verifying Prod.

A deployment builds into Dev unless you name Prod. Unless Dev and Prod share a database, you can build one commit straight into Prod without a Dev deployment:

```sh theme={null}
ohmyhost plan --project "$PROJECT_ID" --commit "$COMMIT_SHA" --environment prod --json
ohmyhost deploy --project "$PROJECT_ID" --commit "$COMMIT_SHA" --environment prod --idempotency-key "$DEPLOY_REQUEST_KEY" --yes --json
```

MCP `deployment_plan` takes the same `environment: "prod"`. A project whose Dev and Prod share a database is refused a Prod plan with [`shared_data_requires_promotion`](/errors/shared-data-requires-promotion), because both environments use that one database. Deploy it to Dev and promote the verified artifact instead.

## Promote after verification

```sh theme={null}
ohmyhost deployment promote plan --project "$PROJECT_ID" --deployment "$DEV_DEPLOYMENT_ID" --json
```

Review migration effects, then within ten minutes pass the plan's `resource_etag` as `--if-match` and `confirmation_token` to `deployment promote`. After expiry, plan again. Those values belong to this exact plan and are not account credentials.

Promotion reuses the verified artifact and applies versioned migrations. It does not copy Dev records or secrets into an isolated Prod database. Keep app secrets and callback URLs appropriate for each environment and verify existing Prod records after the change.

## Change data assignments

The Owner first reviews a concrete plan; each action names which data survives and which environment needs redeployment.

| Change | Starting mode | Outcome |
| - | - | - |
| `isolate_prod_keeps_data` | shared | Prod keeps the current database/files; Dev gets a fresh empty data area. Redeploy Dev. |
| `isolate_dev_keeps_data` | shared | Dev keeps the current database/files; Prod gets a fresh empty data area. Redeploy Prod. |
| `share_prod_keeps_data` | isolated, Prod database exists | Dev joins Prod; Dev-only database/files and Dev deployment and retained rollback scripts are deleted. Redeploy Dev. |
| `reset_dev` | isolated | Delete Dev-only database/files and Dev deployment and retained rollback scripts; assign a fresh empty Dev area. Redeploy Dev. |

```sh theme={null}
ohmyhost project data plan --project "$PROJECT_ID" --change reset_dev --json
ohmyhost project data change --project "$PROJECT_ID" --change reset_dev --if-match "$RESOURCE_ETAG" --confirmation-token "$CONFIRMATION_TOKEN" --idempotency-key "$DATA_CHANGE_KEY" --yes --wait --json
```

Choose the action you intend; `reset_dev` above is a destructive example. `RESOURCE_ETAG` and `CONFIRMATION_TOKEN` come from that exact plan and expire after ten minutes. MCP uses `project_data_plan` and `project_data_change` with `confirmed: true`. Poll the returned operation; after uncertainty retain the same action, guards and key. A fresh key is a new action, not a safe reset retry.

No action copies records, users, auth sessions or files. New databases are provisioned lazily on the next deployment that needs one, replaying the repository's admitted migrations. Files follow the data identity and retain exact physical locators without moving blobs. In a fresh empty identity, logical names such as `avatar.png` are reusable; deletion alone does not make a name reusable in the same identity.

Reset/share preserve runtime secrets and Dev access mode and renew a protected share link. Losing Worker bindings, held connections and time-bound SQL logins are revoked before reassignment/purge. The operation never redeploys automatically: use `redeploy_environments` from its result and read fresh project status. Existing retained-side bindings remain usable only with the same target and continuous authorization. A reverted mode cannot restore deleted data/files. Reset on shared data is refused because it would delete Prod's data. Ordinary usage rates apply; a second database consumes credits independently.

To copy selected records when explicitly requested, use reviewed portable SQL through separately authorized [time-bound psql access](/database#connect-with-psql-or-a-sql-client) to the source and destination. Preserve tenant/schema checks and verify destination rows. This is a separate task; promotion and assignment changes never perform a data or session copy, and files need a separately authorized transfer.

## Roll back

```sh theme={null}
ohmyhost rollback plan --project "$PROJECT_ID" --deployment "$EARLIER_DEPLOYMENT_ID" --json
ohmyhost rollback --project "$PROJECT_ID" --deployment "$EARLIER_DEPLOYMENT_ID" --if-match "$RESOURCE_ETAG" --confirmation-token "$CONFIRMATION_TOKEN" --idempotency-key "$ROLLBACK_REQUEST_KEY" --yes --json
```

Choose an earlier deployment with `status: rolled_back` from `deployments_list`: it was previously live in that environment. Pass that plan's unchanged ten-minute guards. Rollback reactivates the artifact and its crons without a rebuild and never reverts migrations; older code must work with current schema. Read its operation to terminal state. A failed candidate health check keeps the current deployment serving and returns `runtime_candidate_failed`. If reassignment makes the old artifact's data binding stale, rollback returns `rollback_target_data_changed`: plan and redeploy that commit against the current assignment instead of reactivating the old target.

## Delete a project

Remove a live custom hostname first with confirmed `domain paid delete`; otherwise the plan returns `project_domain_delete_required`. Then review the project deletion plan:

```sh theme={null}
ohmyhost delete plan --project "$PROJECT_ID" --json
ohmyhost delete --project "$PROJECT_ID" --if-match "$RESOURCE_ETAG" --confirmation-token "$CONFIRMATION_TOKEN" --idempotency-key "$DELETE_REQUEST_KEY" --yes --json
```

Use the exact plan guards within ten minutes. Deletion removes both environments, all current and historical data identities, files, deployments, schedules, stored SQL exports and the platform-owned mail/DNS resources. Both addresses stop serving. It cannot be undone: download a [SQL export](/backups) first if needed, and remember it contains no files. MCP uses `delete_plan` and `delete_execute`. Keep the original key after uncertainty; a terminal failure needs its stated action and a fresh reviewed plan once no operation is running.

[Schema migrations](/migrations) · [Database profiles](/database) · [Dev access](/cli#verify-progress-and-the-application).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.