Deploying on MIOSA means turning a Sandbox into a stable production app, site, or API backed by immutable versions, health checks, and a public URL returned by the API. Once published, the deployment URL stays stable. New publishes change which version it points at.

The deployment pipeline

Every publish travels the same path:

1. Sandbox - the mutable environment where you (or an agent) write code.
2. Source Snapshot - an immutable tarball of /workspace captured at publish time. The sandbox can keep changing; the snapshot is frozen.
3. Build - MIOSA runs the configured build/packaging pipeline from the frozen source.
4. Release - the immutable build output. Static: files/assets. Dynamic: a server app artifact with command, port, and health check.
5. Deployment Version - the row in history. version_number increases monotonically. Every version is bootable forever.
6. Runtime - for dynamic deployments, MIOSA starts a production runtime and health-checks it. Static releases skip this; MIOSA serves the files directly. App Engine releases run as containers on the workspace App Engine host.
7. Domain - the route. Managed, workspace-owned, tenant-owned, or exact custom domain. Rollback is re-pointing this route with no rebuild.

Static vs Dynamic

Pass kind: "auto" (or the SDK equivalent) and MIOSA chooses the static or dynamic path from your publish inputs. Supplying a run command and port makes the deployment dynamic. Use App Engine when you explicitly want the app to run inside the workspace App Engine host.

The recommended CLI path is:

miosa sandbox publish <sandbox-id> 
  --app <deployment-id> 
  --docker-deploy 
  --wait 
  --json

Omit --app for the first publish. Keep it on every update so MIOSA creates a new version behind the same deployment ID and URL.

The deployment object

A Deployment is the stable product object. It is the thing the world thinks of as “the live app.” It has a name, a slug, an active version, and one or more domains pointing at it.

Project
  └── Deployment ("smile-dental")
        ├── active_version_id ──► Version 17 ──► Release sha:abc...
        ├── Version 16 (archived, still bootable)
        ├── Version 15 (archived, still bootable)
        ├── domains:
        │     ├── smile-dental.cliniciq.miosa.app (managed fallback)
        │     ├── smile-dental.apps.cliniciq.com  (tenant deployment domain)
        │     └── smiledental.com         (custom, verified)
        └── data:
              └── postgres:  DATABASE_URL=...

A Deployment URL is stable. New publishes change which version it points at, not the URL itself.

What gets versioned

Rollback works because every release is immutable and stays in storage. Re-point the deployment at version 14 and MIOSA serves that known-good version again.

The active version remains live while a candidate builds and starts. MIOSA changes production traffic only after the candidate passes its required checks. If the candidate fails, the active version remains unchanged.

Proof contract

The deployment object is not the same thing as proof that production traffic is working. For standard deployments, proof means the deployment has a public URL and MIOSA can route to the active release. For App Engine deployments, proof also requires the workspace host, durable app target, running container route, and public URL probe.

Use:

miosa deploy prove <deployment-id> --json
miosa docker-deploy doctor <deployment-id> --probe-path / --json

Next