Skip to main content
Dari can mount a customer-approved bucket prefix into /workspace/customer for each session. The agent still sees one session filesystem. Repo code, package installs, caches, and runtime internals stay on local disk. The mounted subtree is for customer data and generated files.

​
How access works

  1. Choose a bucket and a base prefix dedicated to Dari.
  2. Grant Dari’s cloud identity access to that scope in your cloud account.
  3. Register the provider, bucket, and base prefix with Dari.
  4. Dari mounts <base_prefix>/sessions/<session_id>/ into /workspace/customer for each session.
Example remote layout:
  • GCS: gs://customer-bucket/dari/acme-prod/sessions/sess_123/
  • S3: s3://customer-bucket/dari/acme-prod/sessions/sess_123/

​
Choose your provider

Connect Storage on GCP

Grant Dari access to a Google Cloud Storage bucket or prefix with a Dari-managed service account.

Connect Storage on S3

Grant Dari access to an Amazon S3 bucket or prefix with a customer-created IAM role.

​
Shared recommendations

  • Use a dedicated bucket or a dedicated base prefix for Dari.
  • Keep dev and prod in separate prefixes.
  • Grant access to the smallest scope available in your cloud setup.
  • Do not hand over long-lived static credentials as the default production path.

​
What you share with Dari

  • Cloud provider: gcs or s3
  • Bucket name
  • Base prefix, for example dari/acme-prod
  • Target environment: dev or prod

​
Runtime limits

Bucket-backed workspaces expose object storage through a filesystem interface.
  • Use them for customer inputs, outputs, artifacts, and large generated files.
  • Do not use them for repo checkouts, package installs, dependency caches, or other tooling that expects full POSIX filesystem behavior.
  • Keep your dedicated prefix stable so revocation and cleanup stay simple.
Read Connect Storage on GCP or Connect Storage on S3 for provider-specific setup steps.