SphereStor

SphereStor is ComputeSphere's persistent block storage. Anything your container writes to the mount path survives restarts, redeploys, and image changes. The disk lives in your environment, not the service — when you redeploy or stop a service, the SphereStor stays put and reattaches on the next start.

One disk, mounted into a service

Environment

data25 GB

Disk lives in the env, not the service.

Serviceapi

mount: data → /dataOne disk per service.

Inside the container

/data

Read + write like any local path.

SphereStor is the right storage when: a single service writes files it needs back on next boot (SQLite, app caches, generated artifacts, model checkpoints), an upload feature has to survive a deploy, or a process keeps state on local disk between runs.

What you configure

Field	What it does
Name	Identifier for the SphereStor — unique within the environment.
Size	Capacity in GB. You can grow this later; you can't shrink it.
Mount path	Where the SphereStor appears inside your container's filesystem (e.g. /data, /var/lib/sqlite). Set when you attach it to a service.

A SphereStor is created at the environment level. Once it exists, you attach it to a service by adding a mount config — that's a two-step flow: create the storage, then mount it.

SphereStor vs service lifecycle

A SphereStor is separate from any service that uses it:

Action	What happens to the SphereStor
Redeploy the service	Stays. Reattaches on the new rollout.
Stop the service	Stays. No data loss.
Restart a spherelet	Stays.
Delete the service	Stays in the environment. Attach it to another service or delete it explicitly.
Delete the environment	Deleted with the environment.

That separation is the whole point: your container is replaceable, your data isn't.

When NOT to use SphereStor

Use case	Use instead
Multiple spherelets all need to read+write the same data	Spherefiles (shared filesystem, multiple writers)
Structured queries, transactions	PostgreSQL
Caching, ephemeral data	Valkey (in-memory; faster)
Job queues with delivery guarantees	RabbitMQ

How it works inside a service

When a service has a SphereStor attached:

• One SphereStor attaches to one spherelet at a time. If your service runs multiple spherelets, the storage follows the spherelet that holds it; the others run stateless.
• The mount path is part of the container's filesystem. Inside the container, ls /data shows the SphereStor's contents. Read and write like any local path.
• Data persists across rollouts. A new container image picks up exactly what the previous one wrote.

For most stateful single-replica services (SQLite-backed apps, single-instance vector databases, file-processing workers), this is the simplest, most predictable storage primitive.

Create and attach

Create the SphereStor

1. Open the project and environment where it should live.
2. Click Storage in the environment sidebar → New SphereStor.
3. Fill in:
   • Name (e.g. data).
   • Size in GB.
4. Click Create.

Attach it to a service

1. Open the service that should mount the SphereStor (or create a new one).
2. In the service's settings, find the SphereStor section.
3. Click Attach, pick the SphereStor you created, and set the mount path inside the container (e.g. /data).
4. Click Save. On the next deploy, it's available at that path.

You can change the mount path or detach the SphereStor any time — the storage and its contents stay in the environment.

Snapshots and backups

The platform takes daily snapshots of every SphereStor in your environment, retained for 7 days. Snapshots run during a low-traffic window in your region and don't require taking the service offline.

For point-in-time restore, custom retention, or off-platform exports, contact support. Customer-controlled snapshot configuration is on the roadmap.

Honest limits

• Single-writer. A SphereStor attaches to one spherelet at a time. Services with multiple spherelets can still use one, but only one spherelet will hold it. If your workload needs many writers, use Spherefiles.
• One SphereStor per mount path. You can attach multiple SphereStor to a service (each at a different path), but you can't attach the same one to two different services simultaneously.
• Grow, don't shrink. Increase the size with PATCH; you can't decrease it. To downsize, create a smaller SphereStor, copy data, swap mounts.
• Cross-environment is not supported. A SphereStor in staging can't be moved or attached to a service in production. Snapshot, export, and re-import to migrate.
• No public mount. Reachable only via a service that mounts it. There's no external block-device endpoint.
• No filesystem choice. Formatted with ext4. Custom filesystems (xfs, btrfs) aren't selectable today.
• Billed by GB. You pay for the provisioned size, not the used size. See Pricing.

What's next

• Spherefiles — when many spherelets need to share a filesystem.
• Spherelets — the compute units that mount SphereStor.
• Environments — where SphereStor lives and how it's scoped.
• PostgreSQL — when you want a managed database instead of raw block storage.