Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.dari.dev/llms.txt

Use this file to discover all available pages before exploring further.

Dari mounts <base_prefix>/sessions/<session_id>/ as the session’s /workspace for agents that reference a storage binding. Only GCS-backed /workspace mounts on E2B are supported today. S3 and partial workspace mounts are not yet available.

​
Setup

​
1. Create a GCP service account scoped to your bucket

Recommended: one dedicated bucket or managed folder per environment, one service account per environment, roles/storage.objectUser. 
gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME \
  --member="serviceAccount:GCS_SERVICE_ACCOUNT_EMAIL" \
  --role="roles/storage.objectUser"
If the bucket uses CMEK, also grant the service account access to the KMS key.

​
2. Create a JSON key

gcloud iam service-accounts keys create gcs-workspace-key.json \
  --iam-account=GCS_SERVICE_ACCOUNT_EMAIL

​
3. Connect the bucket to Dari

dari storage connect gcs workspace \
  --bucket customer-bucket \
  --base-prefix dari/acme-prod \
  --service-account-key ./gcs-workspace-key.json
This stores the service account key as an org credential and creates a named storage binding called workspace.

​
4. Reference the binding from your manifest

sandbox:
  storage_binding: workspace
Dari derives <base_prefix>/sessions/<session_id>/ and mounts it via gcsfuse as the whole agent workspace at /workspace.

​
Notes

  • Use a separate GCS prefix and storage binding for each environment, such as dari/dev with workspace-dev and dari/prod with workspace-prod, so test sessions cannot read or overwrite production workspace files.
  • Rotate the service account key on your normal schedule; update the org credential when you do.