Persistent Storage & Volumes

Nanokit provides a unified way to manage persistent data across different environments using conceptual Storage Types. Instead of worrying about cloud-specific drivers like EBS or EFS, you define the behavior you need, and Nanokit handles the underlying orchestration.

Storage Types

Nanokit supports three primary types for different performance and accessibility requirements.

Type	Best For	AWS	GCP	Azure	DigitalOcean
Block	DBs / Low Latency	EBS	Persistent Disk	Managed Disks	Block Storage
Shared	Uploads / Shared	EFS	Filestore	Azure Files	Managed NFS
Object	Media / Backups	S3	GCS	Azure Blob	Spaces

---

Configuration

Volumes are defined in the volumes section of your nanokit.yml.

Block Storage (Dedicated Disk)

High-performance block storage for databases or single-instance applications.

volumes:
  db-disk:
    type: block
    size: 20Gi
    performance: high # standard, high, or ultra

Shared Storage (Network Filesystem)

Perfect for sharing files between multiple instances of a service.

volumes:
  shared-uploads:
    type: shared
    performance: standard # standard or high

Object Storage (Bucket)

Mount an object store (like S3) directly into your container's filesystem.

volumes:
  cloud-assets:
    type: object
    bucket: my-company-assets

---

Linking to Services

To use a volume, simply list it in the volumes section of your service configuration using the format volume_name:container_path.

services:
  web:
    image: my-app
    volumes:
      - db-disk:/app/data
      - shared-uploads:/app/uploads
      - cloud-assets:/app/public/static

Cloud Portability

Because Nanokit uses abstract storage types, your nanokit.yml remains unchanged whether you deploy to AWS, Google Cloud, or Azure. Nanokit's providers automatically map these types to the most appropriate native primitives of each platform.