Skip to main content
A storage provider is where stored content lives: templates, uploaded files, and anything the ResourceManager reads or writes. One provider is active per server, named by storage_module in the manifest.

​
Local filesystem

The default for a single-process install. Every path resolves under one root, and a path that escapes it raises rather than reading outside.
manifest.yml
Local storage is per-process state on one machine’s disk. A multi-replica fleet gives each replica its own copy — use S3 or GitHub instead.
Content types are inferred from the path suffix, because a filesystem records none.

​
S3

manifest.yml
Leave the key pair unset to fall through to the AWS credential chain — an instance profile, IRSA, or ~/.aws/credentials. The bucket policy needs s3:GetObject, s3:PutObject, s3:DeleteObject, and s3:ListBucket on the bucket and its contents. The driver’s HeadObject probes fall under s3:GetObject and its multi-object delete under s3:DeleteObject; it makes no other calls. Text templates are stored with content type application/jinja2, so a stat on one reports that rather than a text/* type.

​
GitHub

Stores content as files on a branch, which makes every write a commit and every version reviewable.
manifest.yml
A fine-grained token needs Contents: read and write on the repository; a classic token needs repo. Only STORAGE_GITHUB_TOKEN is read — an ambient GITHUB_TOKEN is ignored, as are proxy environment variables.
Two limits shape what this provider suits. Writes are capped at 1 MiB and a larger payload raises before the request. Reads come from the raw content CDN, which can serve a stale copy for a few minutes after a write — do not use GitHub storage for content a tool writes and immediately reads back.
Listing uses the recursive tree API and raises on a truncated response rather than acting on a partial listing. The API host is fixed, so GitHub Enterprise Server is not supported.

​
See also