Skip to main content
Impossible Cloud — EU-sovereign S3-compatible object storage with six European regions and one in New York, a single STANDARD storage class, and pay-per-use pricing with no egress or per-request fees. Two things shape how you use it: every bucket is pinned to the region it was created in and only answers on that region’s endpoint (see below), and the fair-use policy expects monthly egress to stay within the volume you store — which matters when Impossible Cloud is the source of a transfer.

​
At a Glance

​
Credentials

Create a secret with the Impossible Cloud provider type. The auth method is impossible_cloud_access_key, which requires: Generate access keys in the Impossible Cloud console under IAM → Access keys. The secret is shown once, at creation. Keys are IAM credentials, not per-region: the same key pair was used against us-east-1, eu-central-2, and eu-west-1 in our verification runs. A transfer makes these calls, so a scoped IAM policy needs the matching actions: s3:ListBucket and s3:GetObject on the source; s3:ListBucket, s3:PutObject, and the multipart family (CreateMultipartUpload, UploadPart, UploadPartCopy, CompleteMultipartUpload, AbortMultipartUpload, ListMultipartUploads) on the destination; s3:DeleteObject as well for sync tasks. DataRaven never calls CreateBucket. We verified with an unrestricted key — a minimum-policy run is listed under what we did not verify.

​
Location Setup

Pick the bucket’s region from the dropdown and the endpoint is derived automatically. An explicit endpoint_url overrides the derived value and satisfies the region requirement on its own — the region is read back out of the hostname, so an endpoint-only location behaves exactly like a region-only one. One of the two must be set. Region names are Impossible Cloud’s own and do not map to AWS’s: eu-west-1 is Amsterdam here and Ireland on AWS; eu-central-2 is Frankfurt here and Zurich on AWS. Read the bucket’s region off the Impossible Cloud console rather than from habit. Example:

​
Provider Quirks

​
Every bucket answers on one endpoint

Impossible Cloud lists every bucket in the account from every regional endpoint, but a bucket’s data is only reachable on the endpoint of the region it was created in, and that region cannot be changed afterwards. A request for a us-east-1 bucket sent to eu-west-1 is not redirected — it fails:
DataRaven reports this at verification as “The bucket is not served by this region’s endpoint” (REGION_MISMATCH) rather than as a permissions problem. Fix the location’s region; nothing about the key is wrong. The same code comes back for a bucket name you do not own. Bucket names are shared across every Impossible Cloud account (CreateBucket on a taken name answers “The bucket namespace is shared by all users of the system”), so a location pointed at a stranger’s bucket fails with IncorrectEndpoint too. The verification message says so.

​
Bucket names follow the S3 rules, dots included

The rules, as CreateBucket itself states them:
  • 3-63 characters
  • Lowercase letters, numbers, dots, and hyphens
  • Must begin and end with a letter or number
  • No .., and not shaped like an IP address
  • Shared across all Impossible Cloud accounts
Dots are allowed, so an S3 bucket named like a hostname — backups.example.com — carries over unchanged. DataRaven checks the syntactic rules when you create the location; global uniqueness surfaces at verification as described above. Uppercase is rejected by the service rather than downcased, so the check runs on the name exactly as typed.

​
Object keys: everything S3 allows, including what the docs say it rejects

Impossible Cloud’s published limitations say keys may not begin with /, may not contain empty path segments, may not have a segment longer than 255 bytes, and that an object cannot share its name with a “folder” (xxx/yyy alongside xxx/yyy/file). In our end-to-end runs none of those were enforced. PutObject accepted, stored, listed, and served back a leading-slash key, //, /./, /../, a key ending in /, a 256-byte segment, and conflict next to conflict/child.txt — along with %, %2F, +, &, #, ?, embedded newlines and tabs, NFC/NFD Unicode twins, case-only twins, Windows-reserved names, trailing dots and spaces, a 1,024-byte key, and CJK plus emoji. A 1,025-byte key fails with KeyTooLongError, the only key rejection we found. Two of the awkward shapes are limited by rclone rather than by Impossible Cloud, on every S3 provider alike:
  • /./ and /../ segments cannot be read from any S3 source. rclone cannot form a request for them (“failed to open source object: object not found”), so they fail on every run. Rename them at the source.
  • // (an empty segment) transfers only through a recursive listing. rclone’s per-directory listing discards the entry (“Entry doesn’t belong in directory … (too short) - ignoring”), and the recursive ListR path copies it. DataRaven sets fast_list for Impossible Cloud locations partly for this reason — turn it off and those keys are silently skipped.

​
Checksums verify normally

Single-part uploads get a real content-MD5 ETag, so rclone’s post-copy hash check works and DataRaven leaves it on. In our S3 → Impossible Cloud fixture transfer, 2,097 of 2,099 objects landed and 2,095 verified by hash; the other two matched on size because their source objects were multipart uploads with no rclone-written MD5 to compare against. The two that did not land were GLACIER and DEEP_ARCHIVE objects, which fail on the source side until restored. Multipart uploads get the usual <md5-of-part-md5s>-<parts> ETag. rclone stores the whole-object MD5 in X-Amz-Meta-Md5chksum for its own multipart uploads, so those still verify; objects assembled by other tools are compared by size. Impossible Cloud also stores every x-amz-checksum-* algorithm you send — CRC32, CRC32C, SHA1, SHA256, and CRC64NVME all came back on HeadObject with ChecksumType: FULL_OBJECT — and it enforces Content-MD5: a PutObject or UploadPart whose MD5 header does not match the body is rejected with BadDigest.
That enforcement has one migration-visible consequence. An AWS S3 object stored with SSE-KMS has an ETag that is not its MD5, rclone trusts the ETag and sends it as Content-MD5, and Impossible Cloud answers BadDigest — the transfer fails for that object on every run. AWS itself rejects the same copy the same way, so this is a property of the source object and rclone, not of Impossible Cloud. ignore_checksum does not help (the header is still sent); forcing those objects through multipart with a low s3_upload_cutoff does, or re-upload them at the source without KMS.

​
Standard HTTP headers do not survive — only Content-Type does

This is the most important thing to know before a migration, because nothing reports it: the upload returns 200 and the header is simply gone. Verified with PutObject, HeadObject, GetObject, a presigned GET, and CopyObject with REPLACE:
Objects stored compressed with Content-Encoding: gzip arrive as raw gzip bytes served under their Content-Type. Browsers and HTTP clients will not decompress them. If a bucket is served directly to clients, expand those objects before migrating or serve them through something that can set the header.
rclone’s own modification-time metadata (X-Amz-Meta-Mtime) round-trips, including pre-1970 and post-2038 timestamps, so incremental runs still skip unchanged objects correctly.

​
Rejected outright rather than silently ignored

Impossible Cloud mostly says no to what it does not support, which is the behaviour you want from a migration target: a rejected request is visible, a discarded one is not. These are all the response to a plain PutObject: DataRaven never sets a storage class or SSE header, so none of these affect a transfer. They do affect what a source-side setting means after migration: an object that was STANDARD_IA on S3 is STANDARD here.

​
Multipart, UploadPartCopy, and server-side copy all work

The full multipart surface is implemented, and we exercised it hard: a 5.08 GiB object assembled server-side from 52 UploadPartCopy calls, a three-part upload with non-uniform 6 + 5 + 1 MiB parts, and an abandoned upload that ListMultipartUploads reports correctly, with the prefix parameter honoured. Parts must be at least 5 MiB (EntityTooSmall otherwise), the S3 standard. Server-side CopyObject works between buckets in the same region, so an Impossible Cloud → Impossible Cloud task within one region copies without moving bytes through the worker — 31 test objects copied server-side in about a second. Across regions the copy streams through the worker, because rclone will not attempt server-side copies between remotes with different endpoints: our us-east-1 → eu-central-2 fixture run moved all 5.5 GiB through the client.
Parts from a multipart upload that was interrupted and never completed or aborted are not visible in listings but do occupy storage. Impossible Cloud has no lifecycle rules to expire them (GetBucketLifecycleConfiguration is NotImplemented), so clean up with aws s3api abort-multipart-upload or rclone cleanup after an interrupted large-object transfer.

​
Versioning and object lock

Versioning is a per-bucket switch that can be enabled, suspended, and re-enabled. On a versioned destination:
  • every overwrite creates a new version and every delete leaves a delete marker — including the deletes a sync task performs;
  • an unchanged object on a re-run is skipped, not re-written, so scheduled tasks do not pile up identical versions;
  • a transfer reads and writes current versions only. Version history on the source does not carry over.
Object lock (compliance and governance retention, legal hold) is offered at bucket creation and cannot be changed afterwards. We did not run a transfer into a locked bucket — see below.

​
Performance and Rate Limits

Impossible Cloud publishes no request rate limit and charges nothing per request. We looked for a ceiling and did not find one:
  • Small objects, one client, us-east-1: 1,500 objects at transfers 16 / 32 / 64 ran at 93 / 187 / 250 objects per second; 10,000 objects at 64 ran at 357 objects/s and at 128 at 666 objects/s. Zero errors and no SlowDown, 429, or 503 at any setting. Listing the resulting 24,500 objects took 3 seconds; deleting them took 71 seconds.
  • Large objects: the fixture transfers (5.5 GiB, 2,100 objects, three regions) were bounded by our client’s uplink, not by the service. Server-side copy within a region is effectively free.
  • DataRaven defaults to transfers: 32, checkers: 16 for tasks touching an Impossible Cloud location. That is nowhere near what the service accepted; it is a conservative starting point that leaves headroom for the remote on the other side of the transfer, which may well have a limit of its own. Raise it in the task’s rclone configuration if the peer can take it. (Plan limits still apply: Free-tier executions run with transfers: 1.) There is no tpslimit, deliberately — there is no request budget to protect.
  • HTTP/1.1 only. The endpoints do not negotiate HTTP/2, so each request owns its connection and a server-side connection close costs at most one retryable request. No disable_http2 setting is needed.
  • s3_no_check_bucket is on by default, and not because CreateBucket is unavailable — it works with an ordinary key. With the check on, rclone would create a mistyped destination bucket name on the spot, or collide with someone else’s bucket of that name. Off, a typo fails verification instead.
Egress is free but not unlimited. The fair-use policy expects your monthly egress to stay within your stored volume — store 100 TB, download up to 100 TB a month. A one-off migration out of Impossible Cloud that moves most of a bucket is within that; a recurring task that re-reads a large bucket every day is not. Impossible Cloud’s commercial team arranges exceptions for such workloads.

​
What Transfers — and What Doesn’t

Impossible Cloud stores object data, Content-Type, user metadata, object tags, and rclone’s modification-time metadata faithfully. Migrating from S3: CopyObject and UploadPartCopy are supported within a region, along with range requests and presigned URLs (rclone link works). DeleteObjects is listed as supported by Impossible Cloud; rclone issues one DeleteObject per key regardless.

​
What We Did Not Verify

Every claim above comes from a run against live us-east-1, eu-central-2, and eu-west-1 buckets on 2026-09-04 with rclone 1.75.0. These did not get a run and are stated on Impossible Cloud’s documentation alone:
  • A transfer with a minimum-privilege IAM policy — we used an unrestricted key.
  • A transfer into an object-locked bucket, and what a sync delete does there.
  • The 50 TiB object ceiling and the maximum part count — our largest object was 5.08 GiB in 52 parts.
  • Behaviour under the fair-use egress threshold — our egress stayed far below stored volume.
  • The four regions we have no bucket in: eu-west-2, eu-west-3, eu-east-1, eu-north-1.

​
Importing from rclone.conf

Impossible Cloud remotes appear in rclone.conf as type = s3 with provider = ImpossibleCloud. rclone’s own config wizard writes the endpoint without a scheme (endpoint = eu-central-2.storage.impossibleapi.net) and often no region; the importer accepts both and recovers the region from the endpoint hostname. See the rclone import guide.