SFTP to Azure Blob Storage: your options in 2026

You need a partner or an automated job to drop files over SFTP, and you want them to land in Azure Blob Storage. Unlike the early days, you now have a few genuine options, including a native one from Microsoft. Here’s how they compare, and where each one bites.

Option 1: Azure’s native SFTP support

Azure Blob Storage has built-in SFTP support, available on storage accounts with the hierarchical namespace enabled (Azure Data Lake Storage Gen2). You enable SFTP on the account, create local users, and assign them permissions and home directories.

• Good: first-party, no extra infrastructure, files land directly in your own storage account.
• The catches worth knowing before you commit:
  • It requires hierarchical namespace, which is an account-level choice you make at creation; you can’t simply flip it on an existing flat account later without migration.
  • Authentication is via local users specific to the SFTP feature (SSH keys or password), not your Entra ID / Azure AD identities.
  • There’s an hourly charge while SFTP is enabled on the account, on top of normal storage and transaction costs, similar in spirit to AWS Transfer Family’s always-on model, so an idle endpoint still costs you.
  • Per-feature limits apply (concurrent connections, supported operations). Check the current Azure SFTP documentation before you design around it.

If you live entirely in Azure, only need Blob Storage, and the hierarchical-namespace requirement is fine for you, the native feature is the most direct route.

Option 2: self-host an SFTP server

Run SFTPGo (which has a native Azure Blob backend) or OpenSSH with a blob-mount tool on a VM, and point it at your container.

• Good: full control, no per-endpoint feature charge, works regardless of namespace type.
• The catch: you now operate a server, patching, HA, monitoring, key rotation, and the edge cases where a mount layer disagrees with blob semantics. Cheap until it isn’t.

Option 3: a managed bring-your-own-bucket gateway

A hosted gateway that connects to a container you own and runs the SFTP translation for you. This is the category Firepipe is in, and the pitch is your storage, not ours: files stream straight into your own Azure Blob container, with nothing custodied on the vendor side.

For Azure (and for Google Cloud Storage, and S3-compatible stores) the gateway connects using a scoped, encrypted access key you provide, least-privilege access you can rotate or revoke at any time. On top of that you get:

• Per-user SFTP credentials (SSH keys or password), each path-jailed to its own prefix
• One unified audit trail across every backend you connect
• Instant credential revoke that also tears down live sessions
• The option to pin a credential to specific source IPs

The trade-off, as with any managed service, is that the connection passes through the gateway, so choose one whose security model you trust. Pricing starts free, then $19/mo, with no per-operation or per-listing fees.

See the walkthrough on the SFTP to Azure Blob page.

Which should you choose?

If you…	Best fit
Live entirely in Azure, can use hierarchical namespace, want first-party	Native Azure SFTP
Want zero vendor in the path and don’t mind running a server	Self-host
Want low-effort, per-user credentials + audit across providers, files in your own storage	Managed gateway

The common thread: your files should end up in your storage account, under access you can revoke at will. Pick the option that gets you there with the least operational weight for your situation, and if you span more than one cloud, a single gateway across S3, Azure, and GCS saves you running three different setups.