Deploy and operate

Validate

opencloud validate "$APP_DIR"

The command prints the exact manifest-reachable file list. Only the canonical manifest, frontend tree, declared migrations, and declared Function source trees enter the deterministic archive.

Validation also resolves runtime.sdk.version to one exact version. The deployment records that pin, so later platform SDK releases cannot change the running app.

Develop and verify the candidate

Use an isolated development session before changing production:

opencloud app dev start "$APP_DIR"
# edit locally
opencloud app dev sync "$APP_DIR"
opencloud app dev verify "$APP_DIR"

The stable capability URL serves the exact active dev revision with an isolated schema and no production data or secrets. Migration changes replay from empty. Functions remain dormant until the CLI or a deliberate preview interaction invokes them. Verification issues a short-lived receipt bound to the source digest, migration digest, and production base deployment. See Develop safely before production.

For human review before promotion, use the dev session's browserPreviewUrl. It admits only a signed-in owner or builder and opens the isolated revision in a clearly marked Not live preview window with Full size, Tablet, Mobile, and Reload tools. The framed app runs as synthetic user A without changing the reviewer's normal OpenCloud login.

Deploy

Promote the exact verified candidate with a unique idempotency key:

opencloud app dev promote "$APP_DIR" --idempotency-key "$UNIQUE_KEY"

The command follows the durable deployment, runs feature-aware production verification, prints the live URL, and stops dev after success. The platform verifies the artifact, reconciles runtime boundaries, preflights all migrations in a disposable constrained schema, creates a pre-deployment backup, applies new migrations, activates the release, checks health, and reconciles cron. For automation that intentionally does not use a development session, direct deploy "$APP_DIR" remains available but does not carry a dev verification receipt.

With the owner-parity CLI release, success and failure are structured JSON. Preserve the operation ID and use the same idempotency key if the response is lost. A local wait timeout does not mean the deployment failed; recover the durable result without starting a duplicate deployment:

opencloud operation get "$OPERATION_ID" --follow

Verify

opencloud app verify "$APP_ID"

app verify creates a durable server-side verification operation for active release state, exact runtime metadata, deployment-pinned SDK, canonical HTTPS health, Chromium diagnostics, and the immutable external E2E specification. CLI v3 has no second verification file or partial local substitute. Exercise Data, Files, Auth, and every declared Function in the isolated development revision before promotion, then inspect cron, logs, and usage after normal production traffic.

Inspect

opencloud app sdk-inspect "$APP_ID"
opencloud deployment list "$APP_ID"
opencloud deployment get "$APP_ID" "$DEPLOYMENT_ID"
opencloud cron history "$APP_ID"
opencloud logs "$APP_ID" --level error
opencloud usage "$APP_ID"

A normally replaced healthy deployment becomes superseded. rolled_back means an explicit operator rollback targeted that deployment. SDK upgrades are normal new releases; rollback restores both the frontend and its previous SDK pin.

Recovery

Backups are non-destructive to create and inspect. Restore and code rollback can discard or replace state. An exact-app owner Agent may choose either for its assigned app without another operation-specific approval, then must inspect the terminal operation and verify the resulting state. Ordinary human-directed sessions and legacy or narrower Agent credentials retain the requirement for explicit user authorization of that exact destructive action.