Google Cloud Storage SFTP: Three Ways to Put an SFTP Server in Front of a GCS Bucket

Google Cloud Storage is excellent at storing objects. It is not an SFTP server.

Buckets are accessed over HTTPS through the JSON and XML APIs, the gcloud storage and gsutil command-line tools, and client libraries for most languages. That works well when you control the application. The problem starts when someone else controls the connection method: a trading partner that only supports SFTP, a bank that requires SSH keys and a pinned host key, a legacy application that has read files from an SFTP directory for fifteen years and has no realistic path to modernization.

In those cases you need something between the SFTP client and the bucket. There are three common approaches: run your own SFTP gateway on a Compute Engine VM, deploy a third-party gateway image from Google Cloud Marketplace, or use a managed file transfer service that presents the bucket as an SFTP-accessible folder. All three work. The difference is how much infrastructure, and how much operational risk, you want to own.

What Google Cloud Storage supports

GCS moves files with gcloud storage cp and gsutil from the command line, client libraries for application integration, signed URLs for time-limited uploads and downloads, resumable uploads for large files, IAM for access control, and audit logs for bucket activity. All of it is HTTPS. A bucket does not expose an SFTP or FTP hostname, and an SFTP client cannot connect to one. If a partner has to upload over SFTP, a gateway has to accept the connection and write the resulting object to GCS.

Build your own SFTP gateway

The traditional approach is a Compute Engine VM running OpenSSH with SFTP enabled, the bucket mounted with Cloud Storage FUSE, and each user's keys, permissions, and chroot directory configured by hand. To an SFTP user the mounted bucket looks like a directory, and an upload writes an object to GCS. This gives you complete control, and it makes you responsible for the complete service.

A production gateway needs operating-system and OpenSSH patching, high availability and failover, firewall rules and IP allowlists, SSH key onboarding and rotation, per-user chroots and directory permissions, host-key management, capacity planning, monitoring and log retention, authentication from the VM to GCS, and disaster recovery for the configuration. Use an attached service account or workload identity rather than a long-lived service account key sitting on the VM.

Cloud Storage FUSE also deserves careful testing. It presents object storage through a filesystem interface, and it does not turn GCS into a POSIX filesystem: file locking, concurrent writes, renames, metadata operations, and directory-heavy workloads behave differently from a local disk. That rarely matters for "upload a file and close it." It matters a great deal when an application expects ordinary filesystem semantics.

There is an audit gap too. A self-managed gateway produces two layers of logs, SSH and SFTP activity on the VM and object access in Google Cloud, and connecting them to answer "which partner uploaded this object" takes additional logging and correlation. GCS sees the gateway's identity, not the SFTP user's, unless you design a more granular identity model.

Use a Marketplace gateway

Google Cloud Marketplace lists third-party SFTP gateway images that package the same architecture with a browser-based administration interface, easier account and key management, built-in logging, preconfigured storage integrations, and commercial support. They save real setup time, and the underlying infrastructure is still yours: you operate the VM, plan for availability, apply updates, and pay for both the cloud infrastructure and the software license. It is a reasonable middle ground when you need control over the deployment and do not want to build the management layer yourself.

Put a managed SFTP endpoint in front of the bucket

A managed file transfer service removes the gateway VM entirely. With Files.com, you connect a Google Cloud Storage bucket as a Remote Server Mount: an empty folder on your Files.com site becomes a live view of the bucket, or of a specific prefix inside it. Every operation on the folder passes through to GCS in real time, and Files.com keeps no copy of the data.

A partner connects to your Files.com hostname over SFTP and uploads to that folder, and Files.com writes the object to GCS. A legacy application reads the same folder over SFTP without knowing the files live in object storage. Files.com authenticates to GCS with a service account's native JSON credentials scoped to the bucket or prefix, and for a GCS remote server configured that way, downloads route directly from the bucket to the client rather than through Files.com's network.

Files.com operates the protocol endpoint and accepts SFTP, FTP, FTPS, and WebDAV inbound. Each partner receives a separate account limited to its folder. Authentication, SSH keys, passwords, host-key verification, and user lifecycle are handled in the managed service. Every transfer is recorded in the audit log with the user, the path, the operation, the timestamp, and the result, which answers operational and compliance questions without correlating auth.log entries against bucket access logs. There is no gateway VM to patch and no Cloud Storage FUSE mount to maintain. The bucket's maximum object size, 5 TB, is the only limit the mount inherits.

Comparing the three approaches

The lowest monthly invoice is not always the lowest-cost option. A small VM looks inexpensive, and the real cost includes engineering time, patching, monitoring, incident response, key rotation, high availability, and audit work. When SFTP is business-critical, those operational costs pass the VM price quickly. A self-managed gateway is still the right choice when you need complete network control, custom server behavior, or an architecture that stays entirely inside your Google Cloud environment.

Mounting is not the same as syncing

A mounted folder gives live access to the bucket, which is right when a partner or application needs to interact with the bucket's current contents. Sometimes you do not want a live view; you want to move files between systems. Sending objects from GCS to a partner's SFTP server every hour, pulling inbound files from a vendor-owned server, archiving files after delivery, routing arrivals by filename, alerting when an expected file does not appear.

For those, use a scheduled Sync and an Automation rather than a mount. Files.com holds the remote server's credentials and pinned host key, connects outbound, and moves the files on the schedule you set; Automations route or rename new arrivals, and an Expectation raises an alert when a scheduled file is late or missing. The distinction is worth keeping: a mount gives users live access to storage where it already lives, a Sync copies files from one system to another, and an Automation acts when a file arrives or a condition is met.

Which approach to choose

Run your own gateway when you need complete control over the operating system and network, have unusual OpenSSH or authentication requirements, already operate highly available SFTP infrastructure, or must keep every component inside your Google Cloud environment.

Choose a Marketplace gateway when you want a packaged product on a VM-based deployment you are comfortable operating, and its management and compliance features justify the license.

Choose a managed endpoint when you do not want to patch or monitor SFTP servers, need to onboard partners quickly, care about per-partner permissions and audit records, need SFTP, FTPS, WebDAV, and HTTPS access to the same files, or also need scheduled transfers, routing, and missing-file alerts.

The technical problem is simple: translate SFTP operations into GCS API calls. The operational problem is deciding who runs that translation layer. For one internal workflow a VM may be enough. For dozens of partners with separate credentials, access rules, audit requirements, and delivery schedules, the management layer matters more than the protocol. The Box and Dropbox posts cover the same pattern for those systems, the S3 to SFTP post covers the equivalent for Amazon S3, and the SFTP server hosting page covers the managed endpoint itself.

Frequently asked questions

Does Google Cloud Storage support SFTP?

No. Google Cloud Storage exposes HTTPS APIs, command-line tools, and client libraries. Buckets do not provide native SFTP or FTP endpoints.

How can I put an SFTP server in front of a GCS bucket?

Run OpenSSH on a Compute Engine VM and mount the bucket with Cloud Storage FUSE, deploy a third-party gateway from Google Cloud Marketplace, or connect the bucket to a managed file transfer service such as Files.com. The first two are cloud infrastructure you operate; the third is a managed endpoint.

How does Files.com authenticate to Google Cloud Storage?

With a Google Cloud service account's JSON credentials, granted only the permissions the bucket or prefix requires. Downloads from a GCS remote server configured this way route directly rather than through Files.com's network.

Can a partner upload over SFTP directly into my bucket?

Not to the bucket's own hostname. With a gateway or a managed mount in place, the partner uploads over SFTP and the resulting object is written to GCS in real time.

Does Files.com store another copy of mounted files?

No. A Remote Server Mount is a live window into the connected bucket rather than a synchronized copy. When the workflow needs files copied between systems, use a Sync instead.

What is the largest object Google Cloud Storage supports?

5 TB per object, which is the limit the mount inherits. Validate large-file requirements against the client and workflow before deployment.