# Concepts (https://tenki.cloud/docs/sandbox/concepts) > For the complete documentation index, see [llms.txt](https://tenki.cloud/llms.txt) Understand the primitives behind Tenki Sandbox, including sessions, persistent volumes, snapshots, and templates, and when to reach for each. Tenki Sandbox is built around a few primitives. Most workflows combine two or three of them. | Primitive | What it is | Lifetime | | --------- | ------------------------------------------------------------------- | ------------------------------- | | Session | A running full Linux VM | Until you pause or terminate it | | Volume | Workspace-scoped persistent block storage | Across sessions | | Snapshot | A point-in-time capture of one session's VM state (disk and memory) | Until deleted or expired | | Template | A named, reusable definition of a prepared environment | Until deleted | Sessions [#sessions] A session is an isolated Linux VM, and the main thing you drive in Tenki Sandbox. You control its CPU and memory, network access, and environment, and can attach volumes and SSH keys. Every session starts from the same [base image](/docs/sandbox/base-image), with common runtimes and tools already installed. Lifecycle [#lifecycle] You create a session, it enters a running state, and from there you can: * **Snapshot it** to capture its state and start new sessions from it later. The session briefly pauses, then keeps running. * **Pause it** to free compute while preserving files and memory, then resume later. A paused session stops accruing metered charges, and its preserved state counts against your workspace storage quota. * **Terminate it** to release all resources. A terminated session cannot be resumed. The public lifecycle states are `CREATING`, `RUNNING`, `PAUSED`, `TERMINATING`, and `TERMINATED`. A session is ready to use once it reaches `RUNNING`; `TERMINATED` is final. See [Sessions](/docs/sandbox/sessions) for exec, files, ports, and SSH, and the [SDK reference](/docs/sandbox/sdk) for resource limits. Persistent volumes [#persistent-volumes] A volume is workspace-scoped block storage that you attach to a session and keep after the session ends. Reach for one when data needs to outlive a single VM: * package and build caches * large repositories * datasets shared across sessions A volume lives separately from the VM root disk, and it is never attached automatically; you attach it explicitly, at create time or later. See [Volumes](/docs/sandbox/volumes) for the full API. Snapshots [#snapshots] A snapshot captures both a session's disk and memory, so a restored session comes back with its running processes and in-memory state intact, not just its files. A snapshot is one-to-many: you can start many new sessions from the same snapshot. Reach for one when: * you want to preserve the exact state of a session * you want a fast restore point * you want to fork a running environment Snapshot states: `CREATING`, `READY`, `FAILED`, `DELETING`, `DELETED`. Snapshot vs pause/resume [#snapshot-vs-pauseresume] Both hold on to a session's state, but they solve different problems: | | Pause / resume | Snapshot | | -------------------- | --------------------------------------------- | ------------------------------------------ | | The original session | Pauses (stops) the session | Session briefly pauses, then keeps running | | How many you get | One-to-one: resume restores the same session | One-to-many: one snapshot starts many | | When to use it | Set a session aside and pick it back up later | Create a reusable checkpoint | See [Snapshots](/docs/sandbox/snapshots) for the workflow. Templates [#templates] A template captures a prepared environment so every session can start from the same known state. You declare a setup script (which installs dependencies, copies files, and so on), an optional start command, environment variables, and default resources. Tenki builds the template by running the setup script and capturing the result as a snapshot. Every session you create from a template starts from that captured state, so you skip the install-and-warm-up step each time. To use a template, you publish it to your workspace registry and create sessions from its reference, like `myworkspace/my-node-env:latest`. See [Templates](/docs/sandbox/templates) for the full workflow. Snapshots vs templates [#snapshots-vs-templates] Both give you a reusable starting point, but they are not the same: | | Template | Snapshot | | ---------------- | ---------------------------------------- | --------------------------------------------- | | How it's created | Declared before any session exists | Captured from a running session | | What you get | Produces the same environment every time | Captures whatever state existed at the moment | | When to use it | Repeatable environments | Checkpointing, rollback, forking | A snapshot is the saved state; a template is the reusable definition that produces it. Building one runs your configuration and stores the result as a snapshot, so every session from that template starts from the same place. Use templates when every session should start from an identical, known environment; use snapshots when you need to capture or fork live state that depends on what happened during a run. Choosing the right primitive [#choosing-the-right-primitive] | You want… | Reach for… | | -------------------------------------------------------------- | ---------- | | An ephemeral VM for a single task | Session | | Data that outlives the VM | Volume | | An exact restore of one VM's state | Snapshot | | Every session to start from an identical, prepared environment | Template |