Containers on a host

A host runs its own container runtime, and MIOSA manages containers on it: create, start, stop, restart, delete, and stream logs and resource usage. Everything is addressed by the host ID and the container ID, and every operation is tenant-scoped.

MIOSA does not build the image for you. Your image must already be pullable by the host’s runtime.

Run a container

Field	Type	Required	Description
`name`	string	Yes	1 to 63 characters, starting with a letter or digit
`image`	string	Yes	Image reference the host’s runtime can pull
`command`	string[]	No	Command and arguments; default `[]` (the image default)
`env`	object	No	Environment variables as a map; default `{}`
`ports`	object[]	No	`{host_port, container_port, protocol}`; `protocol` defaults to `tcp`
`volumes`	object[]	No	`{source, target, readonly}`; `readonly` defaults to `false`
`restart_policy`	string	No	`no`, `on-failure`, `always`, or `unless-stopped` (default)
`runtime`	string	No	`auto` (default), `docker`, or `podman`

The response is {"container": {...}} with id, name, image, command, env, ports, volumes, restart_policy, runtime, state, runtime_id, runtime_name, exit_code, started_at, stopped_at, last_error, last_cpu_percent, last_mem_mb, and last_stats_at.

Container states are provisioning, running, stopped, failed, removing, and removed.

Logs

Stats

The latest sample is also kept on the container record as last_cpu_percent, last_mem_mb, and last_stats_at.

Lifecycle

miosa host container start <host> <container>
miosa host container stop <host> <container>
miosa host container restart <host> <container>
miosa host container rm <host> <container> --force --yes

Action	REST	Notes
Start	`POST /opencomputers/hosts/{host_id}/containers/{id}/start`	Only from `stopped` or `failed`; returns `409` otherwise
Stop	`POST .../containers/{id}/stop`	Only from `running`; accepts a `timeout_s` grace period, default 10
Restart	`POST .../containers/{id}/restart`	Allowed from `running`, `stopped`, or `failed`
Update	`PATCH .../containers/{id}`	`image`, `command`, `env`, `ports`, `volumes`, `restart_policy`, `runtime`
Delete	`DELETE .../containers/{id}?force=true`	`force` deletes a running container; returns `202`

Deleting a container does not delete its volumes for you unless you asked for the volume to be removed with the container.

Compose projects

A compose project is a docker-compose file the host keeps running.

miosa host compose list <host>
miosa host compose up <host> app --build --pull
miosa host compose down <host> app --remove-volumes
miosa host compose rm <host> app --yes

Action	REST
List	`GET /opencomputers/hosts/{host_id}/compose-projects`
Create	`POST .../compose-projects` with `name`, `yaml` (required), `env`, `pull`, `build`
Up	`POST .../compose-projects/{id}/up`
Down	`POST .../compose-projects/{id}/down` with `remove_volumes`
Delete	`DELETE .../compose-projects/{id}`
Events	`GET .../compose-projects/{id}/events` (SSE)

Compose project states are creating, running, partial, stopped, failed, and removing. The events stream carries {type, payload} frames where type is progress, log, or error.

--remove-volumes destroys the project’s volumes. Confirm what you intend to lose before using it on a stateful project.

Plan limits

The number of container slots a tenant can use depends on the plan, and a compose project counts its services against the same budget.

Plan	Containers and compose service slots
`free`	2
`starter`	10
`pro`	50
`team`	250
`enterprise`	1000

Exceeding the limit returns 402 with error: "plan_limit_reached", plus the limit and current values. See Billing and limits for the other plan-scoped limits.