Storafleet — Multi-Cloud Storage Control Plane

The first objection a company raises about a storage console is simple: we are not pasting long-lived AWS keys into a third-party website. So for AWS we built a connection that needs no keys at all.

The handshake

1. The connect wizard asks our API for a setup. The server mints a fresh UUIDv4 ExternalId for that one connection and keeps it in a short-lived RoleSetup record that expires after an hour.
2. The server builds a CloudFormation quick-create link, so the customer's own AWS console opens with our template and the ExternalId filled in. The stack creates an IAM role that trusts one dedicated Storafleet role, only when the matching ExternalId is presented, with permissions scoped to a single bucket. It can also create the bucket, with versioning, default encryption and a full public-access block switched on.
3. The customer pastes the role ARN back. Before anything is saved, the server runs two probes. Assuming the role without the ExternalId must fail; if it succeeds, the trust policy is too open and we refuse the connection. Assuming it with the ExternalId must succeed. Then the usual read, write and delete checks run.

Decisions worth noting

• One ExternalId per connection, not per workspace. A workspace can connect buckets in many different AWS accounts, and each one is its own trust relationship.
• Two-hop role chaining. Our caller identity assumes our own storafleet-sts role, which then assumes the customer's role. Customer stacks trust that role, not the caller, so we can rotate our credentials without asking anyone to re-run a stack.
• No change to existing code paths. For role connections the bucket's getS3Config() returns an auto-refreshing temporary-credentials provider, so the roughly 30 places that build an S3 client did not change.
• Failures have names: TRUST_POLICY_TOO_OPEN, EXTERNALID_MISMATCH, RCP_BLOCKED and ROLE_NOT_ASSUMABLE, each mapped to a specific fix in the UI.

A dated caveat: as of late September 2026 the first hop is proven from production, and a full run against a disposable test stack is the next check on our list.

"S3-compatible" is a promise every provider keeps a little differently. We did not want 50 code paths, so every provider is a profile in one file, providers.js, and a probe corrects the profile for each real bucket.

The profile

Each profile records the endpoint template, regions, path-style addressing, the console steps for creating a key, and eight capability flags: versioning, lifecycle, storage-class transitions, CORS, bucket policy, public-access block, object tagging and object lock. Provider quirks live there too, as data rather than if statements:

• Newer AWS SDK releases add CRC32 checksums by default, which many non-AWS services reject, so those profiles opt out.
• Wasabi returns a duplicate XML declaration on some bucket settings reads, so its profile switches on a response fix.
• R2 always uses the region auto; DigitalOcean puts the region in the endpoint.
• A self-hosted MinIO behind a private certificate authority gets a per-bucket CA bundle. We never switch TLS verification off.

The probe

The profile is an optimistic baseline. When a bucket connects, we run five read-only requests in parallel (versioning, lifecycle, object lock, bucket policy and public-access block) and classify each answer as supported, unsupported or unknown. The probe can only demote a feature. A successful read does not prove a write will work, so the probe never unlocks something the profile says the provider lacks, and an unknown answer keeps the default. In practice, a Backblaze bucket without Object Lock enabled simply does not show an Object Lock tab.

Curating the roster

Providers were added in batches, each checked against the provider's own documentation and cross-checked with rclone's S3 provider list. Batch 5, in July 2026, added 12 providers and recorded their migration caveats, such as one service that only accepts multipart parts of exactly 8 MB and another with server-side copy disabled. When a customer's bucket is unreachable, the API answers with a 424 carrying a provider-specific code, message and next step, rather than a generic 500.

Moving terabytes between clouds takes hours, and servers restart. We designed the engine so a restart costs only time.

MongoDB is the queue

The worker runs in the Node.js cluster's primary process. It claims a job with one atomic findOneAndUpdate that sets a 90-second lease, and renews the lease every 30 seconds. If the process dies, the lease expires and the next claim resumes the job. HTTP requests run in forked processes, so pause and cancel travel as a controlRequest field the worker checks between objects.

Checkpoints

Within a job, objects are copied in key order, one at a time. That was a deliberate v1 trade-off: it makes the checkpoint trivially correct. The checkpoint is the last key that copied cleanly with no failure before it, and a resumed run lists the source with StartAfter set to that key.

Streaming and verification

Each object streams from GetObject through a SHA-256 hashing transform into a multipart upload. Part size is the larger of 8 MiB or the object size divided by 9,000, which stays under every provider's 10,000-part ceiling and keeps parts equal-sized, as R2 requires. Verification has three levels:

We do not trust ETags across providers, because multipart ETags are computed differently. A move deletes the source only after the copy has verified.

Cost guard

Before a job starts we estimate egress. Above $10 the user has to acknowledge the estimate, and a running job pauses itself if it moves more than twice the estimated bytes.

In August 2026 a test harness drove every migration route, from create and estimate to pause, resume and cancel, against a real Cloudflare R2 to Backblaze B2 copy over HTTP. An opt-in hand-off to Cloudflare's Super Slurper for R2-bound jobs falls back to the streaming engine; it is unit-tested but not yet verified on a live Cloudflare account.

Storafleet is sold by a Bangalore LLP through Razorpay, but storage buyers think in dollars. Getting that right took two designs.

Version 1: show USD, collect INR

In June 2026 we priced plans in USD and collected the INR equivalent at a daily exchange rate, locked per invoice, with a 3% buffer and an admin override. It worked for one-off payments. It broke down when we built renewals: a Razorpay Subscription charges a fixed amount and a Razorpay Plan's amount cannot be edited, so a converted rupee price either drifts away from the dollar price or needs a new plan every day.

Version 2: native currency

Once international cards were enabled on the account in July 2026, we switched. Each plan version now carries an INR price and a USD price, both set by a person. Checkout picks the currency from the billing address (India pays in INR, everyone else in USD) and locks the subscription to the currency actually charged, because invoices, credits and refunds all have to be computed in that currency. The exchange rate survives only for reporting and as a suggestion in the price editor, and revenue dashboards show rupees and dollars side by side, never summed.

GST numbering

GST invoice numbers must be sequential with no gaps. Each financial year has one counter document, and numbers such as INV/FY26-27/00042 are reserved with an atomic $inc. An invoice is validated before a number is reserved, so a failed invoice cannot burn a number. The financial year is computed in UTC, so the April rollover is deterministic. Credit notes have their own series.

Auditing our own money path

Before switching payments on, we audited the whole path and logged 35 findings. By 16 July, 33 were closed, each with its own acceptance test and commit. One of them: the first invoice of every financial year was numbered 00000. Webhooks now verify the signature on the raw body, and the verify endpoint and the webhook compare-and-set the same order, so replaying an event still produces exactly one invoice.

Storafleet's promise is that your files stay in your buckets. For a while we also offered managed buckets, where we provisioned storage for the customer. In September 2026 we withdrew that tier, so the rule now has no exception: Storafleet holds the means to reach your storage, never the storage itself.

Encryption at rest

Every stored secret (S3 access keys, Azure account keys and client secrets, Google service-account JSON, Cloudflare and DigitalOcean API tokens, webhook secrets) is encrypted with AES-256-GCM:

• A 256-bit key is derived for each account with HKDF-SHA256 from a master key that exists only in the server environment. The derived key is never stored.
• Every encryption uses a fresh random 12-byte IV, and the 16-byte authentication tag makes any tampering fail loudly on decrypt.
• Each payload carries a version number, so the algorithm can be rotated later without re-encrypting everything at once.
• The server refuses to start if the master key is missing or the wrong length, rather than failing on the first write.

Small details matter here. Credentials are trimmed before encryption, because a stray newline from a paste silently breaks AWS request signing.

Keeping secrets off the wire

The bucket API returns a hasCredentials flag, never the encrypted fields. The ExternalId for an AWS role connection is returned once, during setup, and never again. Operator screens build their field lists from the schema instead of a hand-kept deny-list, and a checker script looks for any model that could return a secret path.

Keeping bytes off our servers

Browser uploads go straight to the customer's bucket through presigned multipart URLs. Share links do the same in reverse: each click mints a fresh 15-minute presigned URL, and link passwords are stored as bcrypt hashes. The only copy of the data is the one the customer already owns.