Skip to main content
Filebase — S3-compatible object storage with a single global endpoint, always-on encryption at rest, and a generous 500 requests/second account limit. Two things shape how you use it: buckets come in two kinds with very different egress bills (see below), and bucket names are globally unique across every Filebase account, so a name that looks free may not be.

​
At a Glance

​
Credentials

Create a secret with the Filebase provider type. The auth method is filebase_access_key, which requires: Find your access keys in the Filebase dashboard under Access Keys. Keys are account-wide, with no per-region scoping to worry about.

​
Location Setup

Leave the endpoint blank to use the default. Filebase supports both path-style and virtual-hosted addressing, and HTTPS only — plain HTTP is redirected to 443. Example:

​
Provider Quirks

​
Two bucket types: object storage and IPFS

A Filebase bucket is created as either an object-storage (S3) bucket or an IPFS bucket, and the choice is permanent. They do not behave the same:
Pointing a large recurring transfer at an IPFS bucket bills egress on every read. If the bucket is a transfer destination that something else later reads from, confirm which type it is before the first run.
Not sure which kind a bucket is? Read any object’s response headers: an x-amz-meta-cid header means IPFS, an x-amz-checksum-sha256 header means object storage. The free plan includes 5 GB of storage (S3 + IPFS), free S3 egress, 5 GB of IPFS bandwidth, 500 IPFS pins, and 100,000 Class A / 1,000,000 Class B operations per month. On a trial migration the 5 GB storage ceiling is what you hit first — S3 egress is not metered on any plan, so the 5 GB bandwidth figure applies to IPFS only.

​
Bucket naming — no dots, and globally unique

Filebase does not allow dots (.) in bucket names, which S3 permits. An S3 bucket named like a hostname — backups.example.com — needs a new name on the way in.
The full rules:
  • 3-63 characters
  • Lowercase letters, numbers, and hyphens only — no dots
  • Must begin and end with a letter or number
  • Globally unique across all Filebase accounts
DataRaven checks the first three when you create the location, so a non-conforming name fails immediately with a clear message instead of surfacing later as an error from the service. Global uniqueness is a separate failure mode and no validator can catch it: a perfectly legal name may already belong to a stranger. When it does, Filebase answers ListObjects and HeadObject with 403 rather than 404, because the bucket really does exist — it just is not yours. A Filebase location that fails verification with “Access forbidden” is therefore as likely to have a taken name as a permissions problem, and DataRaven’s error message says so. Object keys are case-sensitive UTF-8 up to 1,024 bytes. In DataRaven’s end-to-end tests Filebase accepted everything S3 does except keys with non-normal path segments — //, /./, and /../ are all rejected at upload. The status depends on the client: rclone sees a 403, the AWS CLI a 301. Everything else round-tripped unchanged — %, %2F, +, &, #, ?, embedded newlines and tabs, NFC/NFD Unicode twins, case-only twins, Windows-reserved names, trailing dots and spaces, a trailing-slash key, a 1,024-byte key, and a 256-byte path segment.
These keys are not normalized away in transit. A source bucket containing an object whose key has // in it will fail that object on every run, permanently — the transfer reports AccessDenied, which reads like a permissions problem but is a key-name rejection. Check source keys before migrating into Filebase, and rename the offenders at the source.

​
Checksums verify normally

Filebase returns real content MD5s as ETags for single-part uploads, so rclone’s post-copy hash verification works and DataRaven leaves it on. Of the 2,098 objects in our fixture transfer, 2,092 landed on Filebase and all 2,092 verified with zero hash differences. (The six that did not land are key-name and source-side cases documented elsewhere on this page, not checksum failures. One of the 2,092 matched on size alone, because its source ETag was a multipart ETag with no rclone-written MD5 metadata to compare against — a property of the source object, not of Filebase.) Filebase also returns x-amz-checksum-sha256 on every GET/HEAD of an object-storage bucket, with x-amz-checksum-type: FULL_OBJECT set even for multipart objects — ChecksumMode: ENABLED is a documented no-op because the header is always present. SHA-256 is the only algorithm supported — but the others are not rejected. PutObject with --checksum-algorithm CRC32, CRC32C, SHA1, or CRC64NVME returns 200, and the object then comes back with only a SHA-256 and null for every other algorithm. The requested algorithm is discarded without an error.
Client-supplied checksums on PutObject are accepted but not verified — Filebase computes its own. A 200 response is not the provider agreeing with your hash.

​
Filebase accepts a lot that it silently ignores

This is the most important thing to know before a migration, and it is not visible from response codes. Several S3 features return 200 and are then dropped, so a migration script that checks only for errors will report complete success while losing the setting: A few reads are surprising in the same direction:
  • GetBucketEncryption returns an empty configuration, not the AES-256 rule Filebase’s documentation describes — so it cannot be used to confirm encryption is on.
  • GetBucketPolicy ignores the ?policy subresource entirely and returns a ListBucketResult — a bucket listing where a policy document belongs. Tooling that parses the response without checking its shape will misread it.
  • GetBucketLocation returns the literal string auto, consistent with the single global endpoint.
  • ListMultipartUploads ignores the prefix parameter and returns every in-progress upload in the bucket. Filter the returned Key yourself, and abort each upload against its own key — aborting one id against a different key fails with NoSuchUpload.

​
DataRaven puts Filebase remotes on HTTP/1.1

Filebase serves HTTP/2 and recycles connections with a graceful GOAWAY. Because HTTP/2 multiplexes many requests onto one connection, a single GOAWAY lands on every upload in flight on it, and Go cannot replay a PUT whose body it has already written. The result is a burst of failures like:
Copying the same 1,500 objects twice at transfers: 32 produced 18 failed uploads over HTTP/2 and none with HTTP/1.1. rclone’s retries did recover all 18, so this is wasted requests and log noise rather than lost data — but those retries are not free against the 500 requests/second ceiling, and a task configured with fewer retries would lose the objects outright. DataRaven therefore sets disable_http2 on the Filebase remote itself, not as a task-wide setting, so the remote on the other side of the transfer keeps HTTP/2.

​
Listing uses ListObjects V1, deliberately

Filebase has no provider = value of its own in rclone, so the generated remote says provider = Other, which resolves to ListObjects V1. That is safe here: V1 and V2 return identical key sets across page boundaries, and V1’s marker= is a plain object key with no server-internal suffix to misparse. Verified across 1,500 objects, and again with a one-key page size so that every hostile key in the test set took a turn as the marker. Set s3_list_version in the task’s rclone configuration if you want V2 anyway.

​
UploadPartCopy is not supported

Filebase supports the rest of the multipart surface — CreateMultipartUpload, UploadPart, CompleteMultipartUpload, AbortMultipartUpload, ListParts, ListMultipartUploads — but not UploadPartCopy. This only matters for Filebase-to-Filebase transfers. rclone copies server-side when both ends are the same provider, and reaches for UploadPartCopy above its own copy cutoff (--s3-copy-cutoff, 4.656 GiB by default). Below that threshold plain CopyObject works normally. 4.66 GiB is not a Filebase size limit — it is simply where rclone starts calling an operation Filebase does not implement. The call fails at every size: forcing it onto a 12 MiB object with --s3-copy-cutoff 5M reproduces the failure exactly. Filebase answers UploadPartCopy with HTTP 200, Content-Length: 0, and an empty CopyPartResult — no ETag, and no error anywhere in the response. rclone’s SDK rejects the empty payload, cancels the copy, and reports:
Retries do not help, but rclone does fail loudly and leaves nothing behind.
Tooling that does not notice the missing CopyPartResult gets something worse than an error. The part is registered as a zero-byte part — ListParts reports it with the MD5 of the empty string — and CompleteMultipartUpload then succeeds, returning a normal-looking multipart ETag for an object that is 0 bytes. Every call in the sequence returns 200. A migration script that checks only status codes will report success and have copied nothing.
There is no task setting that works around this today — DataRaven does not expose rclone’s --disable copy or --s3-copy-cutoff. A Filebase-to-Filebase task carrying objects larger than ~4.66 GiB will fail on those objects. Transfers where only one side is Filebase are unaffected, because rclone streams those through the worker rather than copying server-side.

​
Performance and Rate Limits

Filebase allows 500 requests per second per account, shared across the S3 API and the Platform API. Higher limits are available on request from hello@filebase.com. What that means for transfer tasks:
  • Every HTTP call counts as one request, regardless of size. A 100-part multipart upload is 102 requests. Each ListObjectsV2 page is one. Many small objects hit the request cap long before bandwidth becomes the limit.
  • Anonymous reads from public buckets through the CDN are not counted against the account.
  • SlowDown (503) responses are throttling, not failure — and the only error Filebase documents as retryable. rclone backs off and retries automatically. If they persist in the execution logs, lower transfers in the task’s rclone configuration.
  • DataRaven defaults to transfers: 32, checkers: 16, tpslimit: 400 for tasks touching a Filebase location. The same 2,098-object transfer at these settings drew no SlowDown response at all. tpslimit is the part that is actually a rate limit — concurrency alone is not, since 32 in-flight transfers issue requests as fast as the round trip allows. It caps the whole rclone process at 400 transactions/second, so a transfer with Filebase on one side sends it roughly half that and leaves headroom for the Platform API and any concurrent task. Raise it in the task’s rclone configuration if Filebase has lifted your account limit. (Plan limits still apply: Free-tier executions run with transfers: 1.)
  • s3_upload_cutoff is workload-dependent. Single PutObject is capped at 5 GB; past that Filebase returns EntityTooLarge (400). rclone’s 200 MiB default cutoff sits well inside that, and multipart parts may be 5 MiB-5 GiB with up to 10,000 parts, so every object size up to the 5 TB maximum is reachable without tuning. Raise the cutoff (256M-1G) for small-object-heavy transfers to keep them single-PUT — one request per object instead of several — and lower it (64M-256M) for large-object transfers, scaling s3_chunk_size and s3_upload_concurrency rather than file-level transfers.
  • s3_no_check_bucket is on by default. Not because CreateBucket is unavailable — it is fully supported — but because the existence check is one request per run that tells you nothing about a bucket you already named.
Orphaned parts from a multipart upload that was neither completed nor aborted count toward your storage quota. If a large-object transfer is interrupted partway, the already-uploaded parts remain — invisible in listings but billed — until explicitly aborted with aws s3api abort-multipart-upload or the equivalent.

​
What Transfers — and What Doesn’t

Filebase stores object data and standard metadata faithfully — content type, cache control, content disposition, user metadata, and rclone’s modification-time metadata all survive a round trip. Migrating from S3: CopyObject is supported with both ends on Filebase, along with range requests, conditional headers, and pre-signed URLs across GetObject, PutObject, HeadObject, and multipart. DeleteObjects accepts up to 1,000 keys per request.

​
Importing from rclone.conf

Filebase has no provider = value of its own in rclone, so real configs write provider = Other. The importer recognizes Filebase remotes by their endpoint hostname (s3.filebase.io or the legacy s3.filebase.com) instead of falling back to S3 Compatible. See the rclone import guide. The legacy https://s3.filebase.com endpoint is still accepted — enter it in the endpoint field if your existing tooling still points there.