Guides

Storage

Two different tools for two different jobs: object storage for files your users upload, volumes for state a single container must keep on disk.

Which one do I want?

	Object storage	Volumes
Good for	User uploads, images, exports, backups — anything you address by key.	Databases you run yourself, search indexes, caches on disk.
Accessed via	An S3-compatible API over the network.	A filesystem path inside the container.
Effect on scaling	None — any number of replicas can share a bucket.	Pins the app to one replica.
Effect on deploys	None.	Deploys stop the old pod before starting the new one, so there is a brief gap.

Prefer object storage when either would work

A volume costs you horizontal scaling and zero-downtime deploys for the whole app. Reach for one only when your workload genuinely needs a local filesystem.

Starter, Standard, Pro and Scale include no Codara buckets. For object storage on these plans, use a bucket you already have with any S3-compatible provider, such as Cloudflare R2 or Amazon S3. Choose Add → External service on the environment canvas; its credentials are injected into your apps and jobs. The provider bills you for that storage directly.

Codara object storage buckets

A Codara bucket is S3-compatible object storage provisioned in the EU. Your existing S3 client library works against it unchanged.

Codara buckets need a separate agreement

On Starter, Standard, Pro and Scale, creating a bucket is refused with 402 plan_limit_exceeded. Codara object storage is available by separate agreement.

Manage buckets from your canvas

With an object storage agreement, open an environment and choose Add → Bucket. Select a bucket to inspect its endpoint, connect an app, or permanently delete the bucket and all its objects. App connections appear on the canvas. The HTTP API and MCP tools also support buckets; there is no codaracloud buckets command yet.

What gets injected

Connecting a bucket to an app provides the following keys. The default prefix is derived from the bucket name; supplying an explicit connection alias replaces that prefix. The table uses UPLOADS as an example.

Variable	Contains
UPLOADS_BUCKET	The bucket to address.
UPLOADS_S3_ENDPOINT	The S3-compatible endpoint URL.
UPLOADS_S3_ACCESS_KEY_ID	Access key.
UPLOADS_S3_SECRET_ACCESS_KEY	Secret key.
UPLOADS_S3_REGION	Region to pass to your S3 client.

Uploading directly from a browser

Codara can issue presigned URLs so a browser uploads straight to storage instead of streaming through your app. This keeps large files off your container entirely — the usual pattern is that your backend requests a presigned URL, hands it to the client, and the client PUTs the file to it.

Region is fixed at creation

Buckets are provisioned in the EU jurisdiction and this cannot be changed afterwards.

Deleting a bucket destroys its contents

Bucket deletion is irreversible and removes every object inside. There is no recycle bin.

Persistent volumes

A volume is a disk attached to an app at a mount path. It survives restarts, redeploys and image changes.

Need a larger storage allowance? Check your organization’s Billing & usage → Extra capacity. Extra storage costs €0.12 per GiB per month before tax, from 10 to 1,000 GiB, on every current self-service plan, and counts only while your plan is active. It renews monthly even with an annual base plan, stops renewing once your plan is scheduled to end, adds no CPU or RAM, and receives no trial or promotional discount. Use Stop renewal under Your extra capacity to cancel future renewals. See billing and safe capacity reduction for details. Buying extra disk does not automatically grow an existing volume or add backup protection.

bash

$ codaracloud volumes add my-app \    --name data \    --mount /var/lib/data \    --size 20 \    --client my-workspace $ codaracloud volumes list my-app --client my-workspace

Setting	Detail
Default size	10 GiB
Range	10–10,240 GiB, within your plan’s storage allowance
Mount path	Any absolute path inside the container
Name	Lowercase, hyphenated, up to 63 characters

A volume changes how your app runs

Attaching a volume pins the app to a single replica and switches it to a stop-then-start rollout, because the disk can only be mounted by one container at a time. That means no horizontal scaling and a short outage on every deploy. Plan for it before adding one to a traffic-serving app.

Growing a volume

bash

$ codaracloud volumes grow my-app data --size 50 --client my-workspace

Volumes can only grow, never shrink, and the app restarts once to pick up the new size. Unlike database storage, app volumes are not grown automatically — watch your own usage.

Detaching a volume

bash

$ codaracloud volumes remove my-app data --client my-workspace

Detaching does not free the storage allowance

By default the disk and its data are kept after you detach, so you can reattach later. The disk still consumes allocated storage; detaching does not cancel extra storage or change your base-plan price. To free the allocation you must purge the disk, which permanently destroys its data.

Detached disks appear under Detached, data retained on the app page. From there you can reattach the same disk and choose its mount path, or permanently delete it after typing its exact name.

bash

# Permanent and irreversible$ codaracloud volumes purge my-app data --confirm data --client my-workspace

Backups

When the app-volume backup policy is enabled, volumes are copied on a schedule to off-site storage. This is separate from database backups, and there is no self-serve volume restore — recovery is an operator task. If the data matters, keep another copy somewhere you control.

Last updated 25 September 2026