# Anonymous Volumes vs Named Volumes in Container: Key Differences and Usage > Learn the key differences between anonymous and named volumes in container storage. Understand how each is created, managed, and used for persistent data. - Repository: [Apple/container](https://github.com/apple/container) - Tags: deep-dive - Published: 2026-06-13 --- **Anonymous volumes are automatically generated UUID-based storage entities created when you omit a source name in mount flags, persisting beyond container termination until manually pruned, while named volumes rely on explicit user-defined identifiers for persistent, shareable data management.** The `apple/container` CLI provides two distinct mechanisms for managing container data through its volume subsystem. Understanding how **anonymous volumes** differ from named volumes is essential for preventing storage leaks and optimizing resource lifecycle management. This guide examines their technical implementations, lifecycle behaviors, and CLI interactions based on the actual source code implementation. ## What Are Anonymous Volumes? Anonymous volumes are storage entities created automatically by the Container CLI when you specify a mount destination without providing a source volume name. When you run a container with a flag like `-v /data` or `--mount type=volume,dst=/data`, the system calls `VolumeStorage.generateAnonymousVolumeName()` to produce a UUID-based identifier prefixed with `anon-` (e.g., `anon-550e8400-e29b-41d4-a716-446655440000`). These volumes behave like named volumes in terms of storage mechanics but lack user-defined identifiers. According to the implementation in [`Sources/ContainerResource/Volume/VolumeConfiguration.swift`](https://github.com/apple/container/blob/main/Sources/ContainerResource/Volume/VolumeConfiguration.swift), anonymous volume names follow the pattern `^anon-[0-9a-f-]{36}$`, ensuring they satisfy the same validation rules as named volumes through the `isValidVolumeName` check. ## Key Differences: Anonymous vs Named Volumes While both volume types persist data to disk using the same underlying storage layer, they differ significantly in creation, identification, and management workflows: - **Naming Scheme**: Named volumes use explicit identifiers supplied by users (e.g., `mydata`) that must match the pattern `^[A-Za-z0-9][A-Za-z0-9_.-]*$`. Anonymous volumes receive auto-generated UUID strings via `generateAnonymousVolumeName()` and appear with the `anon-` prefix in volume listings. - **Creation Point**: Named volumes are created explicitly via `container volume create` or implicitly when referenced by name in a mount flag (`-v name:/path`). Anonymous volumes are created implicitly during `container run` when the source component is omitted from the mount specification. - **Lifecycle Management**: Neither volume type is automatically removed when a container exits, even when using the `--rm` flag. Both persist in the `VolumesService` store until manually deleted via `container volume rm` or removed through the `volume prune` command, which deletes any volume (named or anonymous) not currently referenced by a running container. - **Visibility**: Both appear in `container volume list` output, but anonymous volumes are immediately identifiable by their `anon-` prefix, making manual cleanup straightforward. ## Technical Implementation in Container ### Volume Name Generation In [`Sources/ContainerResource/Volume/VolumeConfiguration.swift`](https://github.com/apple/container/blob/main/Sources/ContainerResource/Volume/VolumeConfiguration.swift), the `generateAnonymousVolumeName()` function produces the 36-character UUID format. This ensures anonymous volumes satisfy the `isValidVolumeName` validation while remaining clearly distinguishable from user-created names. ### Mount Parsing Logic The CLI determines whether to create an anonymous volume in [`Sources/Services/ContainerAPIService/Client/Parser.swift`](https://github.com/apple/container/blob/main/Sources/Services/ContainerAPIService/Client/Parser.swift). When parsing `-v` or `--mount` strings, if the source component is absent, the parser marks the mount as a volume type and invokes the anonymous name generation routine, creating the volume entry without requiring explicit user input. ### Storage Architecture Both volume types are persisted through [`Sources/Services/ContainerAPIService/Server/Volumes/VolumesService.swift`](https://github.com/apple/container/blob/main/Sources/Services/ContainerAPIService/Server/Volumes/VolumesService.swift) using a `FilesystemEntityStore`. The storage layer treats the volume name as a unique key regardless of whether it is user-defined or auto-generated, meaning anonymous volumes receive identical durability guarantees as named volumes. ## Working With Anonymous Volumes: Practical Examples ### Creating and Using Named Volumes ```bash # Create a named volume explicitly container volume create mydata # Mount the named volume in a container container run -v mydata:/app/data alpine ls /app/data # Clean up when done container volume rm mydata ``` ### Creating and Managing Anonymous Volumes ```bash # Run a container with an anonymous volume (no source name) container run -v /tmp/cache alpine sh -c "echo hello > /tmp/cache/msg" # List volumes to find the anonymous one (prefixed with anon-) container volume list # Re-use the anonymous volume by ID VOL=$(container volume list -q | grep anon) container run -v $VOL:/tmp/cache alpine cat /tmp/cache/msg # Remove specific anonymous volume or prune all unused container volume rm $VOL container volume prune ``` ## Summary - **Anonymous volumes** are auto-generated via `generateAnonymousVolumeName()` with UUID-based names prefixed by `anon-`, created implicitly when mount flags omit source names. - **Named volumes** require explicit user-defined identifiers matching the pattern `^[A-Za-z0-9][A-Za-z0-9_.-]*$` and are created via `container volume create` or named references. - Both volume types persist beyond container termination and are **not** removed by the `--rm` flag; they require manual deletion via `container volume rm` or `container volume prune`. - The [`Parser.swift`](https://github.com/apple/container/blob/main/Parser.swift) logic automatically detects anonymous volume requests, while [`VolumesService.swift`](https://github.com/apple/container/blob/main/VolumesService.swift) handles persistence for both types uniformly through `FilesystemEntityStore`. ## Frequently Asked Questions ### Do anonymous volumes get deleted automatically when the container exits? No. Anonymous volumes persist after the container stops, even when using the `--rm` flag during `container run`. According to the documentation in [`docs/command-reference.md`](https://github.com/apple/container/blob/main/docs/command-reference.md), you must explicitly remove them using `container volume rm` or `container volume prune` to reclaim storage space. ### How can I identify anonymous volumes in the system? Anonymous volumes appear in `container volume list` output with the `anon-` prefix followed by a 36-character UUID. This naming convention, generated by `VolumeStorage.generateAnonymousVolumeName()`, makes them easy to distinguish from user-named volumes and safe to identify for cleanup operations. ### Can I convert an anonymous volume to a named volume? The Container CLI does not provide a direct rename or convert command. To effectively convert an anonymous volume, you must create a new named volume with `container volume create`, copy the data from the anonymous volume using a temporary container, then remove the anonymous volume with `container volume rm`. ### Do anonymous volumes support the same validation rules as named volumes? Yes. Both volume types must satisfy the `isValidVolumeName` validation defined in [`VolumeConfiguration.swift`](https://github.com/apple/container/blob/main/VolumeConfiguration.swift). Anonymous volumes automatically comply because their UUID-based names consist solely of alphanumeric characters and hyphens, matching the required pattern `^[A-Za-z0-9][A-Za-z0-9_.-]*$`.