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
| Action | Scope |
|---|---|
| Get | deployments:read |
See also
- Versions — parent resource
- Deployments — top-level resource
- Releases — conceptual model