isolated or shared data when creating the project (--data-mode); the optional default is shared. Confirmed assignment changes can change it later without copying data.
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 withohmyhost 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
Deploy to Prod
Prod first runs at the hosting address returned byohmyhost 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 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:
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, because both environments use that one database. Deploy it to Dev and promote the verified artifact instead.
Promote after verification
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.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 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
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 confirmeddomain paid delete; otherwise the plan returns project_domain_delete_required. Then review the project deletion plan:
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 · Database profiles · Dev access.