Releases — MIOSA Docs

A Release is the physical artifact produced by a build. Versions reference releases; releases sit in object storage; runtime instances boot from them.

You typically don’t address releases directly through the API — they’re an implementation detail of Deployment Version. But it’s useful to know they exist as their own record because they’re what makes rollback and horizontal scaling work.

Release kinds

Kind	Used by	Storage
`static`	Static deployments served from MIOSA’s edge	`tar.zst` of the built directory
`oci`	Dynamic deployments via OCI image registries	OCI image blobs
`rootfs`	Dynamic deployments booted by Firecracker	`tar.zst` of a Linux rootfs

The release format determines how the deployment is served:

Static releases → MIOSA’s static artifact server streams files from object storage directly. No per-app process runs.
OCI / rootfs releases → MIOSA’s scheduler picks compute hosts, Firecracker boots Runtime Instances from the release, the router sends traffic to them.

Immutability

Releases are content-addressed by sha256. A release with sha256 abc... is always the same bytes, anywhere it’s referenced. This is what makes:

Rollback trivial: repoint a domain at an older version, which still references its release.
Scaling trivial: schedule N copies of the same release on N hosts; every instance is byte-identical.
Audit clean: the release that served traffic at time T can be reproduced from its hash.

A release is never mutated after creation. To “change” it, publish a new version, which produces a new release.

Where releases live

Releases are stored in MIOSA-managed object storage by default. For larger plans, releases replicate across regions for cold-start locality. You can inspect the storage URI on the version record:

{
  "version_number": 17,
  "artifact_uri": "s3://miosa-releases/dep_xyz/ver_abc.tar.zst",
  "artifact_sha256": "a5e6f0c1...",
  "artifact_manifest": {
    "files": 42,
    "total_bytes": 184320,
    "entrypoint": "index.html"
  }
}

You do not need to download releases yourself — MIOSA’s serving plane reads from this URI when traffic arrives. The URI is shown for debugging and audit.

Source snapshot vs release

These are two different artifacts in the same build:

Artifact	What it is	Sha256 stored on
Source snapshot	Frozen tarball of the sandbox source at publish time	`version.source_sha256`
Release	The built output	`version.artifact_sha256`

The source snapshot exists so retries / rebuilds are reproducible. The release exists so production can be served and scaled.

Garbage collection

Static release artifacts older than the retention window (default 30 days for archived versions) may be garbage-collected. The version row remains for audit; if you attempt to rollback to a version whose artifact has been GC’d, MIOSA returns 410 Gone.

Active versions (active_version_id on any deployment) are never GC’d, even past retention.