Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/mikronita/mikrom/llms.txt

Use this file to discover all available pages before exploring further.

Mikrom persistent volumes are network-attached block devices backed by Ceph RBD (RADOS Block Device). Unlike the ephemeral root filesystem inside each microVM — which is discarded when the VM stops — volumes retain their contents across deployments, restarts, and app redeployments. You can attach a volume to any application microVM at a chosen mount point, take snapshots for point-in-time recovery, and move volumes between applications by detaching and re-attaching them.

​
Creating a Volume

Volumes are sized in MiB at creation time. The size cannot be changed after creation without snapshotting and restoring. 
mikrom volume create --name my-data --size 10240
FlagDescription
--nameDisplay name for the volume
--sizeSize in MiB (e.g. 10240 = 10 GiB)

​
Listing Volumes

List all volumes in your active project: 
mikrom volume list
Filter by the application a volume is attached to: 
mikrom volume list --app my-app

​
Attaching a Volume

Attach a volume to an application and specify the path inside the microVM where the block device should be mounted. 
mikrom volume attach \
  --app my-app \
  --volume-id vol_abc123 \
  --mount /data

​
Access Modes

The --mode flag controls how many VMs can access the volume simultaneously. The default is 0 (ReadWriteOnce).
ModeValueDescription
ReadWriteOnce (RWO)0Single VM read/write access (default)
ReadWriteMany (RWX)1Multiple VMs can read and write concurrently
ReadOnlyMany (ROX)2Multiple VMs can read; no VM can write
# Attach in ReadWriteMany mode for shared access
mikrom volume attach \
  --app my-app \
  --volume-id vol_abc123 \
  --mount /shared \
  --mode 1
If you try to attach a volume that is already attached to another application in RWO mode (--mode 0), the operation will be rejected. Detach it from the current application first, or re-attach using RWX mode if concurrent access is acceptable for your workload.

​
Detaching a Volume

mikrom volume detach --app my-app --volume-id vol_abc123
Detaching is non-destructive — the volume and all its data remain intact and can be re-attached to the same or a different application.

​
Snapshots

Snapshots capture the exact byte-level state of a volume at a point in time. They are stored as Ceph RBD snapshots and are independent of the application that owns the volume.

​
Create a snapshot

mikrom volume snapshot --volume-id vol_abc123 --name before-migration

​
Restore a volume from a snapshot

Restoring overwrites the volume’s current contents with the snapshot state. The volume must be detached before a restore can proceed. 
mikrom volume restore --volume-id vol_abc123 --snapshot before-migration
Restoring a snapshot is irreversible for the current volume state. Any data written after the snapshot was taken will be permanently lost. If you need to compare the current state with the snapshot, create a new volume from the snapshot instead of restoring in place.Additionally, if you attempt to delete a volume that has existing snapshots, the operation will be blocked until all snapshots are removed. Delete each snapshot individually with mikrom volume snapshots delete before deleting the volume.

​
List snapshots for a volume

mikrom volume snapshots list --volume-id vol_abc123

​
Delete a specific snapshot

mikrom volume snapshots delete --snapshot-id snap_xyz789

​
Deleting a Volume

mikrom volume delete --volume-id vol_abc123
You will be prompted for confirmation. Pass --yes to skip the prompt in scripts.
A volume must be detached from all applications and all snapshots must be deleted before it can be removed. The CLI will return an error if either condition is not met.

​
Common Workflows

  1. Detach the volume from the current app: 
    mikrom volume detach --app old-app --volume-id vol_abc123
  2. Attach it to the new app at the desired mount point: 
    mikrom volume attach --app new-app --volume-id vol_abc123 --mount /data
Before a potentially destructive migration, snapshot your volume so you can restore quickly if something goes wrong:
mikrom volume snapshot --volume-id vol_abc123 --name pre-deploy-v3
mikrom app deploy --name my-app --cpu 2 --memory 1G
If the migration fails, restore the volume:
mikrom volume detach --app my-app --volume-id vol_abc123
mikrom volume restore --volume-id vol_abc123 --snapshot pre-deploy-v3
mikrom volume attach --app my-app --volume-id vol_abc123 --mount /data

Build docs developers (and LLMs) love

Get started for freeTalk to us