Magic Containers now supports persistent volumes: storage that survives restarts and redeployments

After bringing Bunny Database into public preview last month, we’re continuing to build out the bunny.net developer toolkit with a new release for Magic Containers, our simple but powerful app hosting service.

Let’s hop right into the details.

Persistent volumes without the wiring

While autoscaling compute is largely a solved problem in modern PaaS, persistent storage often still means provisioning volumes manually, mounting them to specific machines, and ensuring they stay attached as your app scales or restarts.

Even having to think about that isn't any fun when you just want to build things, so we took great care to ship persistent storage that actually gets out of your way.

Rather than forcing you to reason in terms of machines, Magic Containers opts for a Docker Compose-style mental model, where your app lives in a pod. A pod may consist of multiple containers that share networking and resources, now including persistent volumes.

Here’s everything you need to know about this new capability:

• Auto-attach and detach: When your app scales and new replicas are started, new volumes are provisioned and attached automatically. When replicas scale down, their volumes detach but persist so they’re ready to reattach when needed, keeping all data intact.
• No data duplication between replicas: Each pod gets its own dedicated volume. When your app is replicated across regions, every replica runs with its own storage.
• Encryption: Every volume is AES-encrypted by default to keep all data safe.
• Limits: Up to 100 GB per volume, with up to two volumes per app (pod).
• Cost: $0.10 per GB per month, based on the allocated (provisioned) volume size.
  

So the idea is that persistent volumes in Magic Containers are set-and-forget. You just add a volume to your app and it’s automatically provisioned and managed, without you having to worry about volume behavior or any wiring.

In this demo, we set up a single-replica Redis instance and a Go API on Magic Containers using a persistent volume:

When to use persistent volumes

Magic Containers works best for apps and services you want running 24/7, such as:

• Web apps: always-on APIs, backends, and server-rendered apps
• Workers and automation: long-running jobs and internal services
• Real-time and TCP/UDP apps: game servers and services with persistent connections

Now that Magic Containers supports persistent volumes, you can have durable data right next to your code. This is useful for a number of things:

• Caches and generated assets: image caches, build caches, template compilation, model files
• Background processing and workers: file processing, PDF generation, media transcoding, temporary spooling before uploading to object storage
• Stateful single-instance services: DBs such as Redis and Postgres, or internal tools

For databases and caches that expect a single writable disk, run with 1 replica per volume. This is because each replica gets its own volume, so running multiple replicas of a stateful service could lead to state inconsistency. If you need your data replicated or distributed across regions, use Bunny Storage or Bunny Database instead.

What will you build?

We can’t wait to see what stateful apps you’ll build with Magic Containers. Log in or sign up to the dashboard to try out persistent volumes and let us know what you think on Discord.

This release is another addition to the bunny.net developer toolkit, and we don’t stop shipping. Stay tuned for more updates later this month.

Happy building!