Guide

SFTP to cloud storage: the complete guide

Everything you need to put an SFTP front door on cloud object storage, why object storage has no native SFTP, the gateway options, the security model, and links to provider-specific setup.

You want people or systems to move files over SFTP, and you want those files to land in cloud object storage: Amazon S3, Azure Blob, Google Cloud Storage, or an S3-compatible store. This guide is the map: why it takes a gateway, what your options are, how the security model works, and where to go for each provider.

Why object storage has no native SFTP

Object stores speak their own HTTP APIs, not SFTP. They’re also not filesystems: there are no real directories, no in-place edits, no atomic rename, and listings are eventually consistent. SFTP clients expect a POSIX-like filesystem. So something has to translate between the two, and that something is an SFTP gateway (or “SFTP proxy”). See what is an SFTP proxy and how an SFTP proxy works for the mechanics.

Your three options

  1. A managed bring-your-own-bucket gateway (such as Firepipe). You connect a bucket you own; the gateway runs the SFTP-to-storage translation. No server to operate, files stay in your cloud account. Best for low operational effort.
  2. Self-host an SFTP server with an object-storage backend (for example SFTPGo). Full control, no third party in the path, at the cost of running and patching the server.
  3. A hosted platform that stores your files (Files.com, ExaVault, and similar). Broader feature sets, but your data lives on their service rather than your own bucket, and pricing is platform-level.

This guide focuses on the bring-your-own-bucket approach, where your files stay in storage you own.

The access and security model

Whichever gateway you use, the security building blocks are the same:

  • Per-user credentials (SSH keys or passwords), one per partner or system, so you can revoke one without affecting the rest. See SSH keys vs password authentication.
  • Path jails: each user is scoped to a prefix and can’t see anyone else’s files. See chroot directories explained.
  • Least-privilege storage access: for S3, a scoped cross-account IAM role; for Azure, GCS, and S3-compatible stores, a scoped access key you can revoke.
  • An audit trail of every connection and transfer. See SFTP audit logging.
  • Source-IP pinning per credential, and instant revoke when access should end.

Round it out with SFTP security best practices.

Provider-specific setup

What object storage can’t do (know this up front)

Because object storage isn’t a filesystem, a few SFTP behaviours don’t translate: in-place edits, preserved timestamps/permissions, and atomic directory rename. A good gateway fails those loudly rather than corrupting data. The full list is in SFTP compatibility & known limitations; read it before you automate.

The bottom line

SFTP onto cloud storage is a solved problem: pick a gateway model that matches how much you want to operate, connect a bucket you own, issue per-user path-jailed credentials, and keep an audit trail. Start with SFTP to S3 or the provider guide that fits your stack.

Try it on your own bucket

Connect a bucket you already own, Amazon S3, Azure Blob, Google Cloud Storage, or an S3-compatible store, and hand out a clean SFTP endpoint in minutes. Your files stay in your cloud.

Start free

← All guides