A session is the user-visible Jio resource. It has a stable ID and can outlive one client connection. A generation is one running microVM incarnation of that session.
Lifecycle
starting -> ready -> stopping -> stopped -> ready
\ /
-------> destroyed <-----Failures can move creation or lifecycle work to failed. Hosted ephemeral
sessions can expire and do not support stop/start.
| Operation | Result |
|---|---|
| Create | Allocates a session, workspace, network identity, and VM generation |
| Get | Returns the current observed state and generation |
| Connect | Opens SSH to the ready generation |
| Exec | Runs a bounded command over SSH |
| Stop | Releases compute and retains files, when supported |
| Start | Creates a new generation with retained files |
| Destroy | Permanently deletes compute and retained files |
Identity and generation
Session IDs are 32-character lowercase hexadecimal values in the current API. A generation counter changes when stopped compute starts again. Lifecycle mutations use generation checks so an older client cannot race a newer incarnation.
Session IDs are not secrets. Authorization still requires the account API key, and SSH access requires the private key generated by the client that created the session.
Storage
The runtime template is immutable. Session-owned writable storage holds the workspace and, where supported, persistent system files. A clean stop flushes and retains those volumes before compute is released.
Current recovery does not promise restoration across a Core or host restart, and running services are not checkpointed. A memory snapshot is not the durability contract for user files.
Endpoint differences
The client discovers capabilities from the endpoint. Hosted ephemeral sessions carry an expiry and reject stop/start. Retained-session endpoints can preserve files across a clean stop/start. Never infer support from the CLI command existing; handle the endpoint response.