On this page

A Release is the physical artifact produced by a build — what a Version references. See Releases for the conceptual model.

Endpoints (Phase 2B)

GET /api/v1/releases/:id
GET /api/v1/deployments/:id/versions/:version_id/release

Releases are not typically created directly — they’re produced by Publish. The endpoints above are for inspection and audit.

Release shape

{
  "id": "rel_...",
  "deployment_version_id": "ver_...",
  "service_id": "svc_...",
  "tenant_id": "...",
  "kind": "static",
  "storage_uri": "s3://miosa-releases/dep_xyz/rel_abc.tar.zst",
  "sha256": "a5e6f0c1...",
  "size_bytes": 184320,
  "start_command": null,
  "port": null,
  "metadata": {
    "build_log_uri": "s3://...",
    "build_duration_ms": 8420
  },
  "created_at": "2026-05-14T18:19:48Z"
}

For dynamic releases: kind: "oci" | "rootfs", start_command and port populated.

Immutability

Releases are content-addressed by sha256. A release with sha256 abc... is always the same bytes. This is what makes Rollback trivial and horizontal scaling identical across instances.

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

Garbage collection

Static release artifacts older than the retention window (default 30 days for archived versions) are eligible for GC. The version row remains for audit; the artifact itself may be removed from object storage.

If you attempt to rollback to a version whose artifact has been GC’d, MIOSA returns 410 Gone. Active versions (any deployment’s active_version_id) are never GC’d.

Permissions

ActionScope
Getdeployments:read

See also

Was this helpful?