Dropbox SFTP: How to Give a Dropbox Folder an SFTP Endpoint Without a Relay Server

A vendor needs to deliver files over SFTP. Your team works in Dropbox.

It sounds like a simple integration until you discover the catch: Dropbox does not provide an SFTP server. There is no hostname you can hand to a partner, no port 22 endpoint, and no way for an SFTP-only application to browse a Dropbox folder directly.

That leaves three practical options: build against the Dropbox API, run your own SFTP relay server, or put an SFTP-capable platform in front of Dropbox. Here is how each works and when it makes sense.

Dropbox does not support SFTP or FTP

Dropbox is designed for file synchronization and collaboration. Its interfaces are the desktop and mobile apps, the web application, shared links and folders, and the Dropbox API with SDKs for Python, JavaScript, Java, .NET, Swift, and Objective-C. What it does not provide is an SFTP or FTP endpoint.

That distinction matters when files move between systems rather than people. A trading partner has an automated SFTP job. A vendor exports reports only to an SFTP server. A legacy application knows how to list, upload, and download files over SFTP and nothing else. In those situations, "just share a Dropbox folder" is not an answer.

Integrate directly with the Dropbox API

If you control the application sending or receiving files, the Dropbox API is the most direct option. Your application authenticates with OAuth and uses files/upload for smaller uploads, upload sessions for larger files, files/download to retrieve files, and files/list_folder to enumerate a folder. Nothing new is added to the architecture.

The limitation is plain: the other system has to be able and willing to integrate with Dropbox. That works for software you own. It is no use when a partner already has an SFTP client and no interest in building a custom integration for you.

Run an SFTP relay server

The traditional workaround places a server between SFTP and Dropbox. A partner uploads to the relay's SFTP daemon, a script watches the landing directory and pushes each file to Dropbox through the API, and another process handles retries, cleanup, and notifications. The same pattern runs in reverse for outbound files.

It works, and the relay becomes infrastructure you own. Someone patches the operating system, secures SSH, rotates credentials, monitors disk space, handles duplicates and failed transfers, and maintains the Dropbox integration. You will also want logging and auditing, or the answer to "did the file arrive at 2:17 a.m." is buried across an SSH log, a cron job, and a half-finished script. For teams that already operate managed file transfer infrastructure, that may be acceptable. For everyone else, the relay becomes a surprisingly expensive small script.

Put an SFTP endpoint in front of Dropbox

The third approach uses a managed file transfer platform that presents a Dropbox folder through SFTP. Files.com does this with a Remote Server Mount.

You connect Files.com to Dropbox and associate an empty folder on Files.com with a folder in Dropbox. That folder becomes a live view of the Dropbox contents: listings, uploads, downloads, renames, and every other file operation pass through to Dropbox in real time, and Files.com keeps no copy. Files.com also provides SFTP, FTP, FTPS, and WebDAV access.

The result is a straightforward bridge. A partner connects to your Files.com hostname over SFTP and uploads to a folder they are authorized to use. Files.com writes the file to the mounted Dropbox folder, and your team sees it in Dropbox through the tools they already use. The same setup works in the other direction: an SFTP-based application lists and downloads files from the mounted folder without knowing Dropbox is behind it. The partner keeps using SFTP, your team keeps using Dropbox, and neither side writes integration code.

Why a managed bridge instead of a relay

The difference is operational. With a self-hosted relay you are responsible for both sides of the connection and everything between them. With a managed platform, the protocol server, user access, transfer records, and the Dropbox connection are handled in one place.

Partners get separate access. They do not need Dropbox accounts, shared links, or access to your broader Dropbox environment; each receives a Files.com user scoped to the right folder, so one vendor is limited to uploads while another may list and download.

Credentials are centralized. The Dropbox credentials live in Files.com's encrypted credential store rather than on a general-purpose relay alongside SSH keys and scripts.

Transfers are audited. SFTP activity lands in the Files.com audit log, so who uploaded the file, when the transfer completed, which account downloaded it, and whether it was renamed or removed are questions with answers.

There is no permanent relay copy. A mount is a window onto Dropbox, not a second repository. The one exception is Buffered Uploads: when enabled, Files.com holds a completed upload briefly and forwards it to Dropbox in the background, so the partner's SFTP session does not stay open while Dropbox finishes processing.

Dropbox performance and file-size considerations

An SFTP front end does not remove Dropbox's own limits. Dropbox applies API rate limits, so a mounted folder may be slower than storage designed for high-volume system-to-system transfers such as Amazon S3, Azure Blob Storage, or Google Cloud Storage. That rarely matters for occasional documents or daily reports; it can matter for large batches, frequent polling, or workflows that move thousands of files. Buffered Uploads improve the sender's side: the SFTP upload is marked complete once Files.com has the whole file, and the transfer to Dropbox continues in the background.

Dropbox's per-file maximum still applies. Files.com documents a 375 GB limit for files transferred through a Dropbox mount, and limits change, so confirm current values before designing a large-file workflow.

Common ways teams use SFTP with Dropbox

The pattern is most useful when Dropbox is the right workspace for people and the systems around those people require SFTP.

A logistics team works from a shared Dropbox folder while brokers and carriers deliver shipment documents over SFTP; the mounted folder lets those files arrive in the team's existing workflow without the broker changing its process. An internal or third-party application that only knows how to poll an SFTP directory lists and retrieves files stored in Dropbox as if they sat on a conventional server. A team with years of habits and permissions built around one Dropbox folder connects it once and lets external automations act on its contents without moving anyone to a new interface. And a team staging a migration away from Dropbox runs a scheduled Sync that pulls the contents into Files.com in batches while users keep working in Dropbox until cutover.

When Dropbox is the wrong place for the files

Adding SFTP access does not make Dropbox the best backend for every transfer workflow. Dropbox is optimized for end-user synchronization, sharing, and collaboration. If files mostly move between applications and people rarely touch them, native cloud or object storage is the better long-term destination: S3, Azure Blob, Google Cloud Storage, or native Files.com storage for high-volume automated transfers, predictable system-to-system performance, and fewer API bottlenecks.

The rule is simple. Mount Dropbox when the files need to remain in Dropbox because people actively work with them. Migrate the files when Dropbox is an accidental backend, and for a one-time migration of a whole account into another cloud, Mover, the migration tool from Files.com, prices the move with a free dry run before anything copies.

The Box and Google Cloud Storage posts cover the same pattern for those systems, and the SFTP server hosting page covers the managed endpoint itself.

Frequently asked questions

Does Dropbox support SFTP or FTP?

No. Dropbox provides desktop and mobile apps, a web interface, shared folders, and an API, and no native SFTP or FTP endpoint.

How can I receive SFTP uploads in Dropbox?

Connect Dropbox to Files.com with a Remote Server Mount. A partner uploads over SFTP to your Files.com hostname, and Files.com forwards the file to the mounted Dropbox folder. A relay server of your own also works, at the cost of the infrastructure and maintenance.

Can I download Dropbox files over SFTP?

Yes, with an intermediary that supports both. An SFTP client connecting to Files.com lists and downloads files from a mounted Dropbox folder as ordinary directories and files.

Do partners need Dropbox accounts?

Not with a managed SFTP bridge. Each partner receives a separate Files.com account scoped to the folders and actions they need.

Will a Dropbox mount be as fast as object storage?

Not necessarily. Dropbox rate-limits its API and is built for user collaboration and sync. For high-volume automated transfers, object storage or native managed file transfer storage is the better fit.

What are Buffered Uploads?

A Files.com setting that receives the complete file from the SFTP client first, reports the upload as complete, and forwards the file to Dropbox in the background, so the sender does not wait on Dropbox during the SFTP session.

How do I migrate files out of Dropbox?

A scheduled Sync moves Dropbox folders into Files.com in batches. For a one-time account migration to another cloud, Mover runs a free dry run before copying begins.