withvibe
Sign in
Self-hosting

Object storage

Every workspace has a storage backend for its compose files and uploaded env assets. It defaults to local disk on the API host; you can switch it to S3 so that data survives env wipes and is shared across API replicas.

What it stores

The storage backend is the durable home for a workspace's compose files and uploaded env assets(and template files). When an env starts, withvibe materializes these into the env's clone directory so Docker can bind-mount them — but the backend is the source of truth.

Local disk (default)

Out of the box, storage is Local disk: files are written under a base path on the API host, laid out per workspace and env. Set the base path under Settings → Storage backend(it must be writable by the API process; it's created on first write). If you leave it unset, it defaults to the env clone directory.

Local disk has limits
Local storage lives on a single API host's disk. It isn't shared across multiple API replicas, and it can be lost when an env clone directory is wiped. If that matters for your deployment, use S3.

S3

Switch the mode to S3 to store compose files and assets in a bucket. Fields:

  • Bucket — e.g. my-team-withvibe.
  • Region — e.g. us-east-1.
  • Key prefix (optional) — namespaces objects under a path.
  • Access key ID and Secret access key.

Secrets are write-only: once saved, the settings page shows a "saved" marker rather than the value, and you can leave the credential fields blank to keep the existing ones. A Disconnect S3 credentials button clears them.

AWS S3, not generic S3-compatible
The S3 client is configured with region and credentials only — there's no custom endpoint field today, so MinIO / R2 / Wasabi-style endpoints aren't supported yet. Use AWS S3, or stay on local disk backed by a shared/durable volume.

Test & migrate

The storage settings (admin-only) include two operations:

  • Test connection — round-trips a small probe object (write, read back, delete) and reports success or the exact error. Save your changes first; the test runs against the saved config.
  • Migrate existing envs— copies every active env's compose and assets into the newly configured backend. It's idempotent and reports per-env what was copied or skipped, so you can switch backends without losing existing data.
PreviousNetwork isolationNext CLI