Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/denoland/celld/llms.txt

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

celld supports Google Cloud Storage via the Cloud Storage XML API with generation preconditions. Using a gs:// bucket URL selects GCS as the storage backend — celld then authenticates with Google credentials instead of AWS credentials and uses the GCS-native precondition protocol rather than the S3 If-Match header.
For GCS, celld uses the x-goog-if-generation-match precondition header, not the S3 If-Match header. The condition compares the object generation number rather than an ETag. This is intentional: Cloud Storage does not apply If-Match to a PUT, so celld sends the GCS request dialect when the bucket URL begins with gs://.

​
Authentication options

celld supports three ways to authenticate against a GCS bucket: Application Default Credentials (ADC) The simplest option for local development and for workloads that run inside Google Cloud. Run: 
gcloud auth application-default login
celld picks up the credential automatically. No environment variables are needed beyond CELLD_BUCKET. Service account key file Point GOOGLE_APPLICATION_CREDENTIALS at a JSON key file for a service account that has access to the bucket: 
export GOOGLE_APPLICATION_CREDENTIALS=/path/to/service-account-key.json
export CELLD_BUCKET=gs://YOUR-BUCKET
Inline service account key Set the JSON key content directly in the environment variable GOOGLE_SERVICE_ACCOUNT_KEY. This is useful in containerised environments where mounting a file is inconvenient: 
export GOOGLE_SERVICE_ACCOUNT_KEY='{"type":"service_account","project_id":"...","private_key":"...","client_email":"...",...}'
export CELLD_BUCKET=gs://YOUR-BUCKET

​
Compute Engine

On a Compute Engine instance, celld can use the service account attached to the instance. However, the default access scope for Compute Engine instances permits storage reads only. celld requires both read and write access to the bucket, so you must create the instance with the cloud-platform scope: 
gcloud compute instances create my-node \
  --scopes=https://www.googleapis.com/auth/cloud-platform \
  --service-account=celld-sa@YOUR-PROJECT.iam.gserviceaccount.com
With the cloud-platform scope, the IAM role of the attached service account controls bucket access. Grant the service account at least the Storage Object Admin role on the bucket.

​
Setup

1

Create a GCS bucket

Create a bucket in the Google Cloud console or with the gcloud CLI:
gcloud storage buckets create gs://YOUR-BUCKET \
  --location=us-central1 \
  --uniform-bucket-level-access
Uniform bucket-level access simplifies IAM: permissions apply to the whole bucket rather than individual objects.
2

Authenticate

Choose one of the authentication options above. For local development, Application Default Credentials are the easiest:
gcloud auth application-default login
For a service account, export the credentials:
export GOOGLE_APPLICATION_CREDENTIALS=/path/to/service-account-key.json
3

Set the bucket URL

Point celld at the GCS bucket with a gs:// URL:
export CELLD_BUCKET=gs://YOUR-BUCKET
4

Deploy and start a node

Run celld deploy to push the application, then start the node. A gs:// bucket requires no --endpoint or --region flags:
celld deploy . --bucket "$CELLD_BUCKET"

celld --bucket "$CELLD_BUCKET"

​
Notes

  • A gs:// bucket URL takes no S3_ENDPOINT and no AWS_* credentials. celld ignores the storage region for GCS.
  • S3 static credentials (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY) do not apply to a gs:// bucket.
  • celld does not read ~/.aws profiles or SSO logins for GCS.
  • The GCS backend uses the Cloud Storage XML API, not the JSON API. The x-goog-if-generation-match precondition provides the conditional-create and conditional-overwrite semantics that celld requires for ownership fencing. See Ownership and fencing for the full mechanism.
A gs:// key prefix works the same as with S3: set CELLD_BUCKET=gs://YOUR-BUCKET/PREFIX to namespace all fleet objects under PREFIX/. Two independent fleets can then share one bucket. A fleet configured without a prefix stays at the bucket root and does not need to be migrated.

Build docs developers (and LLMs) love

Get started for freeTalk to us