Skip to content

docs(cloud-deployment): separate publish from install (in-environment)#1691

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
os-zhuang merged 1 commit into from
Jun 10, 2026
Merged

docs(cloud-deployment): separate publish from install (in-environment) #1691

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
27 changes: 17 additions & 10 deletions content/docs/guides/cloud-deployment.mdx
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -62,20 +62,27 @@ or the host's deployment config.

## Cloud-managed deployment

The unified path publishes a **versioned package** and installs it into a cloud
environment in one step:
Publishing and installing are **separate steps**. The CLI publishes a
**versioned package** to your organization's catalog — it does not touch any
environment, and you never pass an environment id:

```bash
os cloud login # once: stores a cloud token
os package publish --env env_prod --install # publish a version + install it
os cloud login # once: stores a cloud token
os package publish # → sys_package + immutable, checksummed sys_package_version
```

This registers a `sys_package` plus an immutable, checksummed
`sys_package_version`, then records the install against the target environment
(see the cloud [package](/docs/references/cloud/package) and
[package-version](/docs/references/cloud/package-version) references). The
environment kernel is evicted on install, so the new metadata and any sample
data are live on the next request — no restart.
See the cloud [package](/docs/references/cloud/package) and
[package-version](/docs/references/cloud/package-version) references.

Installing then happens **inside the target environment**: sign in to that
environment's Console → **Marketplace** → pick the package → **Install**. The
install is authorized by your environment login and applied to that environment
(metadata + sample data); the kernel is evicted so it is live on the next
request — no restart, and no environment id to remember.

> **CI shortcut.** A pipeline deploying to a *known* environment can publish and
> install in one call: `os package publish --env <id> --install`. This is for
> automation only — interactive installs happen in the environment Marketplace.

> **Legacy env-revision path.** `os publish` posts compiled metadata straight to
> an environment as a revision, rather than as a versioned package:
Expand Down