Why Firepipe uses object storage instead of local disks

A traditional SFTP server keeps files on the local disk of the machine it runs on. Firepipe takes a different approach: files live in cloud object storage you own, and the gateway is stateless. That choice drives most of what makes Firepipe different. Here’s the reasoning.

The problem with local disks

A local-disk SFTP server ties your files to one machine, and that creates a chain of obligations:

• Durability is your problem. A disk fails, and unless you’ve set up RAID and backups, files are gone. You own the backup strategy and the restore testing.
• Capacity is a ceiling. The disk fills, and you’re resizing volumes or migrating servers.
• It’s a single point of failure. One box down means the drop-zone is down.
• It doesn’t scale sideways. Adding a second server means keeping two disks in sync, which is its own headache.
• You operate all of it. Patching, monitoring, backups, capacity planning, the lot.

What object storage gives you instead

Cloud object storage (Amazon S3, Azure Blob, Google Cloud Storage, and S3-compatible) is built for exactly the properties local disks lack:

• High durability by design. Providers replicate objects across multiple facilities; Amazon S3, for instance, is designed for eleven nines of durability. You don’t run RAID or nightly backups to get it.
• Effectively unlimited capacity. No volume to fill or resize; you store what you store.
• No server holding the files. The gateway is stateless and the storage is the cloud’s, so there’s no single disk whose failure loses data.
• Managed by the provider. Replication, scaling, and availability are theirs to run, not yours.

The part that matters most: it’s your storage

Firepipe doesn’t host the storage; you do. The files land in a bucket on your own AWS, Azure, or Google account. That means:

• No lock-in and no migration. The data is already where you’d want it; you can read it with the cloud’s own tools, lifecycle it, and analyse it in place.
• Your durability guarantees and your region choices apply, not a vendor’s.
• A clean separation: Firepipe operates the SFTP layer; your cloud operates the storage. Decoupling the protocol from the storage is what lets you swap or scale either independently. See how an SFTP proxy works.

The trade-off, honestly

Object storage isn’t a filesystem, so a few POSIX behaviours don’t translate: in-place edits, preserved timestamps and permissions, and atomic directory rename. A local-disk server can do those; an object-storage gateway can’t, and shouldn’t pretend to. Firepipe fails those loudly rather than corrupting data, and the full list is on the SFTP compatibility page. For the overwhelming majority of SFTP use, uploading, downloading, listing, organising, the trade is well worth the durability, scale, and zero-server-operations you get back.

In short

Local disks make durability, capacity, and availability your job. Object storage makes them the cloud’s job, in a bucket you own, with the gateway holding no files of its own. That’s why Firepipe is built this way. See SFTP to S3 to put it in front of your bucket.