SFTP to Google Cloud Storage

The usual way to land partner files in a GCS bucket is to run an SFTP server, write each incoming file to a local volume, then poll that directory with a cron job or a Cloud Function that copies the file into the bucket and deletes the original. That is three things to patch, monitor and secure — plus a window where partner data sits unencrypted on a disk. FTPasHTTPS folds the whole pipeline into one streaming hop: the SFTP upload becomes the GCS object write directly, with nothing staged in between.

How SFTP-to-GCS forwarding works

1. A client connects over SFTP (SSH key auth), FTPS or FTP and runs a STOR (upload) command.
2. FTPasHTTPS opens a streaming object write to your Google Cloud Storage bucket and pipes the incoming bytes straight into it.
3. The object name is templated from the filename, username and timestamp, so every upload lands at a predictable, partitioned path.
4. When GCS finalizes the object, the client receives 226 Transfer complete. A storage error maps to 451 Action aborted so the client knows to retry.
5. Every transfer is written to the audit log; failures retry with exponential backoff and fall back to a dead-letter queue.

Configuration + example

A GCS forward target on a server is a small JSON config. You supply the bucket, its location, an object-name template, and a credential — either a scoped service account JSON key or a Cloud Storage HMAC key:

# GCS forward target for an SFTP server
{
  "protocol": "sftp",
  "auth": { "type": "ssh-key" },
  "forward": {
    "type": "gcs",
    "bucket": "acme-partner-dropbox",
    "location": "europe-west1",
    "objectNameTemplate": "inbound/{username}/{date}/{filename}",
    "credentials": {
      "type": "service-account",
      "key": "${GCP_SERVICE_ACCOUNT_JSON}"
    },
    "storageClass": "NEARLINE"
  }
}

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

# Vendor uploads over SFTP; the object lands in GCS
sftp -i partner_key [email protected]
sftp> put orders-2026-06-20.csv
Uploading orders-2026-06-20.csv  100%   42KB
226 Transfer complete

# Object now exists at:
# gs://acme-partner-dropbox/inbound/vendor/2026-06-20/orders-2026-06-20.csv

FTPasHTTPS vs. the DIY SFTP + cron pipeline

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

When to use it (and the limits)

Reach for FTPasHTTPS-to-GCS when partners insist on SFTP or FTP but your stack lives in Google Cloud Storage, when you want objects in a bucket the moment they arrive, or when you would rather not own an internet-facing SFTP daemon on Compute Engine. GCS forwarding (and the inline transformation features) is available from the Professional plan up (€49/server/month: 10,000 transfers, 50GB); 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 bucket. Object names are derived from the upload template, not arbitrary client paths. And throughput is bounded by your plan's monthly transfer and size caps — 10,000 transfers / 50GB on Professional, 50,000 / 250GB on Enterprise.

Object names, prefixes and downstream triggers

Because the object name is templated, you decide exactly how uploads are organised in the bucket. A template like inbound/{username}/{date}/{filename} partitions every partner into their own prefix and every day into its own folder, which keeps Object Lifecycle Management rules, IAM bindings and downstream consumers simple. Scope the service account (or HMAC key) to write only that prefix, and a leaked credential can do nothing but write where it was already allowed to write.

Once the object is finalized, the rest of your pipeline behaves exactly as it would for any other GCS write — a Cloud Function, an Eventarc trigger or a Pub/Sub notification on object finalize can all fire off the new object. If you would rather not depend on GCS event notifications at all, attach a webhook to the same forward so your application is notified directly the instant the upload completes, with the object name and partner identity included. Either way, the audit log gives you a single place to answer the only question that matters during an incident: did the file arrive, and when?

Frequently asked questions