SFTP to Azure Blob, automatically

Azure's own SFTP support means enabling hierarchical namespace on a storage account and exposing it to partners, and many teams instead build a bridge: a VM running an SFTP daemon, files written to a managed disk, then a timer-triggered Function that copies each one into a container and cleans up. That is a VM to patch, a disk where unencrypted partner files briefly sit, and glue code to babysit. FTPasHTTPS collapses the whole pipeline into a single streaming hop — the upload becomes a block blob write with nothing in between.

How SFTP-to-Azure-Blob forwarding works

1. A client connects over SFTP (SSH key auth), FTPS or FTP and runs a STOR (upload) command.
2. FTPasHTTPS opens a block blob write against your container and streams the incoming bytes straight into it — no temporary file is created.
3. The blob name is templated from the filename, username and timestamp, so every upload lands under a predictable virtual path inside the container.
4. When Azure commits the blob, the client receives 226 Transfer complete; a failure maps to 451 Action aborted so the client knows to retry.
5. Every transfer is written to the audit log; failed writes retry with exponential backoff and fall back to a dead-letter queue.

Configuration + example

An Azure Blob forward target is a small JSON config. You supply the storage account, container, a blob-name template, and a credential — a scoped SAS token, a connection string or an account key — plus the access tier the blob should land in:

# Azure Blob forward target for an SFTP server
{
  "protocol": "sftp",
  "auth": { "type": "ssh-key" },
  "forward": {
    "type": "azure-blob",
    "account": "acmepartnerstore",
    "container": "inbound",
    "blobNameTemplate": "{username}/{date}/{filename}",
    "credentials": {
      "sasToken": "${AZURE_BLOB_SAS_TOKEN}"
    },
    "accessTier": "Cool"
  }
}

A vendor then uploads exactly as they always have — nothing changes on their side:

# Vendor uploads over SFTP; the file lands as a block blob
sftp -i partner_key [email protected]
sftp> put invoices-2026-06-20.xml
Uploading invoices-2026-06-20.xml  100%   88KB
226 Transfer complete

# Block blob now exists at:
# https://acmepartnerstore.blob.core.windows.net/
#   inbound/vendor/2026-06-20/invoices-2026-06-20.xml

FTPasHTTPS vs. the DIY SFTP + cron pipeline

Concern	DIY SFTP server + cron + script	FTPasHTTPS → Azure Blob
Files on disk	Written to a managed disk, then deleted	Never touch disk — streamed into the blob
Moving parts	VM + SFTP daemon + timer Function + copy script	One streaming forward
Latency to the container	Up to the timer interval (minutes)	Streams during the upload
Retries on Azure error	Hand-rolled, often missing	Exponential backoff + dead-letter queue
Audit trail	Scattered across VM logs	Full audit log per transfer
Patching & uptime	You own the VM and daemon	Managed for you
Protocols	Usually SFTP only	FTP, FTPS and SFTP

When to use it (and the limits)

Reach for FTPasHTTPS-to-Azure-Blob when partners insist on SFTP or FTP but your data lives in Blob Storage, when you want files committed to a container the moment they arrive, or when you would rather not run an internet-facing SFTP VM just to feed Azure. Azure Blob forwarding (and the inline transformation features) is available from the Professional plan up (€49/server/month: 10,000 transfers, 50GB, SFTP); the Free tier is FTP-only and ideal for proving the flow before you wire in production credentials.

A few limits to keep in mind: forwarding is per-file at upload time, so this is not a tool for batch re-syncing an existing container. Blob names are derived from the upload through the template, not arbitrary client paths, and uploads are committed as block blobs. Throughput is bounded by your plan's monthly transfer and size caps — 10,000 transfers / 50GB on Professional, 50,000 / 250GB on Enterprise, which also adds unlimited users, SSO/SAML, a dedicated IP and PGP.

Blob names, containers and downstream triggers

Because the blob name is templated, you decide exactly how uploads are organised inside the container. A template like {username}/{date}/{filename} gives every partner their own virtual folder and every day its own prefix, which keeps lifecycle management policies, role assignments and downstream consumers simple. Issue a SAS token scoped to write-only on that single container — or even a single prefix — and a leaked token can do nothing but add blobs where it was already allowed to, never read or delete existing data. If you prefer Microsoft Entra over shared keys, point the forward at a connection string backed by a tightly scoped role assignment instead.

Once the block blob is committed, the rest of your pipeline behaves exactly as it would for any other write — an Event Grid Microsoft.Storage.BlobCreated event can fan out to an Azure Function, a Logic App or Service Bus, and a blob-triggered Function can pick the new object up directly. If you would rather not depend on Event Grid at all, attach a webhook to the same forward so your application is notified the instant the upload completes, with the blob name and partner identity included in the signed payload. Either way, the audit log answers the only question that matters during an incident: did the file arrive, and when?

Frequently asked questions