Deploy

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.

1. Publish from a sandbox

2. Promote or roll back

miosa deploy releases <deployment>
miosa deploy promote <deployment> <release>
miosa deploy rollback <deployment> --to <release-id> --yes --json

Promotion and rollback each target one exact immutable release.

3. Prove it is live

miosa deploy get <deployment> --json
miosa deploy requests <deployment>

A deployment object is not proof by itself. The public URL must route to the active release, and for App Engine also to the workspace host and a running container.

Pick what you need

You want to	Start here
Serve a static site, SPA, or docs	Publishing
Run an API, SSR, or WebSocket server	Dynamic Runtimes
Run many small apps on one host	App Engine
Roll back to an older version	Rollback
Attach a custom domain	Deployment Domains
Understand the objects behind a publish	The deployment model

The sandbox-to-version pipeline: source snapshots, build modes, and promotion.

Immutable history. List, inspect, promote, and archive versions.

The artifacts: static files and dynamic server artifacts.

Re-point a deployment at an older version in seconds, with no rebuild.

Managed and custom domains. DNS verification, TLS, and route caching.

Dynamic deployments - production runtimes, health checks, and reconciler behavior.

Pipeline, static vs dynamic, deployments, versions, and the proof contract.