Cloud Body Storage

Configure per-user or per-organization cloud storage so Steward uploads full request/response bodies to your own S3 or GCS bucket.

Majordomo uploads request/response bodies to cloud storage that you control. Configure this in the dashboard at the user or organization level. When configured, Steward writes bodies to those buckets and logs only metadata (tokens, cost, latency) to Majordomo.

If no personal/org Cloud Storage is configured, Steward does not store bodies by default. You can optionally enable local body columns in Postgres for debugging via logging.store_request_body / logging.store_response_body in Steward config.

Where to configure

• Personal: Settings → Cloud Body Storage
• Organization: Settings → Organization Cloud Body Storage

Either scope works. If both are set, the personal bucket takes precedence for that user’s API keys.

Amazon S3 setup

1. Create a bucket (e.g., your-llm-logs).
2. Choose an authentication method:
   • Recommended: instance role / workload identity attached to where Steward runs; leave access keys blank.
   • Alternative: Access Key ID / Secret Access Key scoped to this bucket.
3. In the dashboard form, select Provider = S3 and fill:
   • Bucket (required)
   • Region (default us-east-1)
   • Endpoint (optional — for S3‑compatible services like MinIO or Cloudflare R2)
   • Access Key ID / Secret Access Key (only if not using instance role)
4. Save. The status badge shows “S3 Configured”.

What Steward writes

• Object per request with gzipped JSON containing request headers/body and response headers/body.
• Key format includes API key id, request id, and timestamp for easy lookup.

Google Cloud Storage setup

1. Create a GCS bucket (e.g., your-llm-logs).
2. Create a service account (e.g., majordomo-storage@<project>.iam.gserviceaccount.com) and grant Storage Object Admin on the bucket.
3. Generate a JSON key for that service account.
4. In the dashboard form, select Provider = GCS and fill:
   • Bucket (required)
   • Project ID (optional but recommended)
   • Service Account JSON (paste the key JSON)
5. Save. The status badge shows “GCS Configured”.

Data handling rules

• Bodies are uploaded to your bucket when a valid per‑user or per‑org config exists.
• If neither is configured, Steward will not upload bodies; metadata is still logged.

Troubleshooting

• “Configured” badge missing: open Settings → Cloud Body Storage and ensure required fields are saved for the correct scope.
• S3 upload errors: verify IAM permissions for PutObject/ListBucket and that Region/Endpoint are correct. MinIO/R2 require setting the custom Endpoint.
• GCS upload errors: confirm the service account has Storage Object Admin and the pasted JSON is valid.

Related Steward variables

Cloud storage credentials and bucket details are managed in the dashboard and encrypted at rest. You rarely need to touch these, but Steward exposes env vars for Postgres body storage if needed for local debugging:

Variable	Default	Description
LOG_STORE_REQUEST_BODY	false	Store request bodies in Postgres. For debugging only.
LOG_STORE_RESPONSE_BODY	false	Store response bodies in Postgres. For debugging only.

Prefer configuring cloud storage in the dashboard over Postgres body storage for production use.