Buckets and objects
Filebase follows the same conceptual model as AWS S3:
- A bucket is a top-level container.
- An object is a file plus its metadata, stored inside a bucket.
- An object is identified by its key — a UTF-8 string that acts like a filesystem path (
photos/2026/sunset.jpg).
If you've worked with AWS S3, every concept on this page applies the same way to Filebase. The only differences are the endpoint and the region — see the S3 API overview.
Buckets
A bucket is a globally-unique namespace for the objects it contains. Buckets are flat — there are no real folders, only object keys that happen to contain / characters that most tools render as a folder hierarchy.
Naming rules
- 3 to 63 characters
- Lowercase letters, numbers, and dashes only
- Start and end with a letter or number
- Globally unique across all Filebase accounts
Lifecycle
You can create, list, configure, and delete buckets via the S3 API, the console, or any S3 client. A bucket must be empty before it can be deleted — use aws s3 rb --force s3://name to delete the contents and the bucket in one step.
Per-account limits
| Plan | Buckets allowed |
|---|---|
| Free | 1 |
| Pro | 100 |
See service limits for the full table.
Objects
An object is the actual data you upload — a JPEG, a JSON document, a video, anything. Each object has:
- A key (the path within the bucket, e.g.
assets/logo.svg). - A body (the bytes themselves).
- System metadata Filebase manages for you: size, last-modified time, ETag (a hash of the contents), Content-Type.
- User metadata — arbitrary
x-amz-meta-*headers you set at upload time.
Object keys
Keys are case-sensitive UTF-8 strings up to 1,024 characters. They can contain almost any character, but for the smoothest experience with web browsers and CDNs, stick to:
- Letters, numbers, hyphens, underscores, periods
- Forward slashes (
/) for hierarchical organization - URL-safe characters
Avoid spaces, quotes, and other characters that need escaping in URLs.
Object size
| Limit | |
|---|---|
| Single PUT request | 5 GB |
| Multipart upload | 5 TB total, 10,000 parts max |
| Recommended max for any single object | 1 TB |
For files over 100 MB you should use multipart upload, which:
- Lets you upload parts in parallel for much higher throughput.
- Automatically retries individual parts that fail without restarting the whole transfer.
- Is required for files over 5 GB.
The AWS CLI and every modern AWS SDK switch to multipart upload automatically once a file exceeds a threshold (typically 5–8 MB).
ETags
Filebase returns an ETag with every object — for single-part uploads it's the MD5 hash of the body, which lets you verify the upload integrity client-side. For multipart uploads the ETag is a composite hash following the same algorithm AWS S3 uses, so any tool that knows how to compute multipart ETags works against Filebase unchanged.
Versioning and lifecycle
Filebase supports the read-side of versioning and lifecycle APIs (GetBucketVersioning, GetBucketLifecycle) for compatibility. Setting custom versioning rules is on the roadmap — see the S3 compatibility matrix for the current state.