Access keys and authentication
Filebase uses the same authentication model as AWS S3: every API call is signed with an access key pair using AWS Signature Version 4 (SigV4). Any S3-compatible client signs requests automatically — you only need to supply the keys.
Access key pair
A pair consists of:
- Access Key ID — public, identifies your account.
- Secret Access Key — private, never sent over the wire (used to derive a per-request signature).
Both halves are required. View and rotate them in the Access Keys page of the console. See the Get started access keys page for the step-by-step.
How signing works
When you make an authenticated request:
- Your client builds the request (method, URL, headers, body).
- Your client computes a SHA-256 hash of the request (or
UNSIGNED-PAYLOADfor streaming). - Your client derives a signing key from the secret access key, the date, the region (
auto), and the service (s3). - Your client uses the signing key to HMAC-SHA-256 the canonical request.
- The resulting signature is sent in the
Authorizationheader.
Filebase repeats steps 2–4 server-side and rejects the request if the signatures don't match.
You almost never need to think about this — the AWS CLI, AWS SDKs, rclone, s3cmd, Cyberduck, and every other S3 client handle signing for you.
Required values
| Setting | Value | Why |
|---|---|---|
| Endpoint | https://s3.filebase.io | Filebase S3 endpoint |
| Region | auto | Filebase routes globally; no per-region buckets |
| Signature version | s3v4 (SigV4) | Only version Filebase accepts |
Single key pair per account
Filebase issues one access key pair per account. We don't support per-key scoping or IAM-style policies today. If you need stricter separation between workloads, create separate Filebase accounts.
Keep secrets out of source control
A leaked secret access key gives an attacker full read-write access to every bucket on your account. Treat it like a password:
- Store it in environment variables (
FILEBASE_KEY,FILEBASE_SECRET) or a secrets manager (AWS Secrets Manager, HashiCorp Vault, Doppler, 1Password CLI). - Never check it into git, even in
.envfiles. Use.gitignoreaggressively. - Rotate it immediately if you suspect exposure — see the Access Keys page in the console.
Granting limited access
When you need to give someone temporary, scoped access — letting a customer upload to one bucket, or a partner download a single file — use pre-signed URLs instead of sharing your access keys. A pre-signed URL embeds a short-lived signature for one specific operation on one specific object.
See pre-signed URLs for examples.