Guide

SFTP for MinIO: a complete setup guide

How to put SFTP in front of self-hosted MinIO object storage, creating scoped access keys, the network-reachability constraint a hosted gateway adds, and when to self-host the SFTP layer too.

MinIO is self-hosted, S3-compatible object storage you run on your own hardware or cloud VMs, popular for on-prem, air-gapped, and data-residency-sensitive deployments. Because it speaks the S3 API, you can put an SFTP layer in front of it the same way you would for Amazon S3. There’s one extra consideration MinIO brings that the hosted clouds don’t: network reachability, covered below.

Why MinIO specifically

  • You own the whole stack. Storage lives on your infrastructure, on-prem, in your VPC, or air-gapped, which is often the entire reason for choosing MinIO.
  • S3-compatible. Standard access keys and an endpoint, so any SFTP-to-S3 gateway can connect.

Step 1: create a bucket and an access key

On your MinIO server, via the console or mc:

mc mb local/sftp-dropzone
mc admin user svcacct add local <your-user>

Or in the MinIO Console: Identity → Service Accounts → Create, then Buckets → Create Bucket. Scope the service account’s policy to just the bucket the SFTP users should reach. Save the Access Key and Secret Key.

Your endpoint is wherever MinIO is served, e.g.:

https://minio.internal.example.com:9000

Step 2: decide who runs the SFTP layer

This is the MinIO-specific fork in the road, because MinIO is yours, not a public cloud:

Option A: a managed gateway (the network constraint)

A hosted bring-your-own-bucket gateway like Firepipe connects to MinIO as an S3-compatible backend, but the gateway runs outside your network, so it must be able to reach your MinIO endpoint over the network. That’s fine if MinIO is exposed on a routable (ideally TLS-terminated, firewalled) address. It is not an option for a fully air-gapped or strictly private MinIO that can’t accept inbound connections from a hosted service. If you chose MinIO precisely to keep storage unreachable from outside, a hosted gateway is the wrong fit, go to Option B.

If MinIO is reachable: add a connection, choose S3-compatible, enter the endpoint, Access Key, and Secret (stored encrypted, scoped to your bucket), then create per-user SFTP credentials, each path-jailed to its own prefix.

Option B: self-host the SFTP layer too

For air-gapped or strictly private MinIO, run the SFTP server inside the same network: SFTPGo has a native S3 backend and points at MinIO with the same access key and endpoint. You keep everything in-network and own the SFTP layer, at the cost of operating it (patching, HA, monitoring, key rotation), which for a MinIO shop is usually already familiar territory.

Step 3: per-user access and audit (either option)

Whichever layer you run, the security hygiene is the same: one credential per partner (SSH key or password), each path-jailed to its own prefix, a full audit trail of connections and transfers, and instant revoke. With Firepipe you also get source-IP pinning per credential and the audit log exportable out of the box; self-hosting, you assemble that yourself.

Summary

MinIO + SFTP works because MinIO is S3-compatible: the real decision is where the SFTP layer runs. If your MinIO is network-reachable, a managed gateway gives you per-user credentials and audit with nothing to operate. If it’s air-gapped or deliberately private, self-host the SFTP layer in the same network. Either way the files stay in your MinIO.

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