Box SFTP: How to Send and Receive Files Over SFTP When Box Has No SFTP Server

Start with the short answer: Box does not provide an SFTP server.

That often comes as a surprise. Box is widely used by enterprises to store and collaborate on files, and SFTP remains one of the most common ways businesses exchange files with partners and automated systems. It seems as though the two would work together. They do, but not directly.

If a trading partner can only deliver files over SFTP, they cannot connect an SFTP client to your Box account. An application built to retrieve files from an SFTP server cannot read from Box without an intermediary. Here is what Box offers instead, the three common ways to bridge that gap, and how to give partners an SFTP experience while the files stay in Box.

What Box offers instead of SFTP

Box provides the Box web application, Box Drive for desktop access, the Box API and SDKs, and the Box CLI. What it does not provide is a native SFTP or FTP endpoint. Nothing listens on port 22 that a partner can reach with an ordinary SFTP client. Box offered FTP access to some customers years ago and retired it; today automated transfers rely on Box Drive or the API.

That leaves three practical ways to connect Box to partners and systems that require SFTP.

Build an integration with the Box API

If you control the application sending or receiving files, the Box API is the most direct option. Box offers SDKs for Python, Node.js, Java, and .NET. Your application authenticates through OAuth or an application service account, then uses Box's REST endpoints to upload, download, list, and manage files, with a chunked-upload workflow for large files.

This works when you own the application on the other end, your engineering team can build and maintain the integration, and the application can use HTTPS APIs instead of SFTP. The limitation is plain: an API integration does not help a partner that only supports SFTP. If the partner cannot change its workflow, you still need something that accepts an SFTP connection.

Run your own SFTP relay server

The traditional solution puts a relay server between Box and the outside world. The server runs an SFTP daemon so partners can upload and download, and a separate script or service uses the Box API to move those files between the relay and the right Box folders.

It works, and it is another system to operate. Your team patches and secures the server, manages SFTP and Box credentials, monitors transfer jobs, retries failed transfers, prevents duplicate and missing files, manages temporary storage, maintains logs and audit records, and troubleshoots the transfer that failed at 3 a.m. For organizations that already run managed file transfer infrastructure, that may be acceptable. For everyone else, a homegrown relay becomes more work than expected.

Put an SFTP interface in front of Box

The third option is a managed file transfer platform that connects to Box while presenting an SFTP server to partners. Files.com does this with a Remote Server Mount.

A folder on your Files.com site is connected to a folder in Box. The mounted folder is a live view of the Box content: when an authorized user lists, uploads, downloads, renames, or deletes a file through the mount, the corresponding operation happens in Box, in real time, and Files.com keeps no copy. Files.com also provides inbound access over SFTP, FTP, FTPS, and WebDAV.

Put those together and the workflow is short. A partner connects to your Files.com hostname with its existing SFTP client and uploads into its assigned folder. That folder is mounted to Box, so Files.com passes the operation through, and the file appears in Box where your employees see it normally. The reverse works as well: a system connects to Files.com over SFTP and retrieves files from the mounted Box folder. From the partner's perspective it is a normal SFTP server. From your employees' perspective the files are still in Box.

Why a managed bridge instead of a relay

The biggest advantage is that you do not build or operate the bridge. Box credentials live in Files.com's encrypted credential store. Each partner receives a separate Files.com user limited to the folders it needs, with no Box account or seat and no access to the rest of your Box environment. Every transfer is recorded in the Files.com audit log, which gives administrators one place to review activity and investigate failures.

This model fits when partners cannot move away from SFTP, employees need to keep working in Box, several external organizations need separate access, compliance or audit requirements apply, and nobody wants to maintain another internet-facing server. Rather than asking every partner to support the Box API, you give them the protocol they already use.

Performance and file-size considerations

A Box mount operates within Box's technical limits.

Box enforces API rate limits, so a mounted Box folder may not deliver the throughput of native object storage such as Amazon S3 or Azure Blob Storage. The difference shows when many files move at once or in high-volume automated workflows. Files.com's Buffered Uploads setting improves the sender's experience: with buffering enabled, Files.com receives the complete upload, reports the SFTP transfer as finished, and forwards the file to Box in the background, so a slow Box API response does not hold the partner's SFTP session open. The file is staged by Files.com while the transfer to Box completes.

Box's maximum file size depends on your Box plan and reaches 150 GB on some plans. The mount inherits that limit. Check your plan and expected file sizes before making the mount part of a production workflow.

When Box is the wrong long-term destination

A Box-to-SFTP bridge makes sense when the files genuinely need to remain in Box, usually because employees review, edit, approve, or collaborate on them there. Box is a content management and collaboration platform, and it is not the best long-term home for large volumes of machine-generated files that people rarely open. For system-to-system exchange, native managed file transfer storage or object storage such as S3, Azure Blob, or Google Cloud Storage offers better scalability and more predictable performance.

Keep the files in Box when people actively work with them there. Use native or object storage when the files mostly move between systems. And if the goal is to leave Box entirely, a mount is not the tool: a scheduled Sync copies files from Box into another location in batches while the team keeps working in Box until cutover, and a one-time migration of the whole Box environment is a job for Mover, the migration tool from Files.com, which starts with a free dry run that prices the move.

The Dropbox 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 Box support SFTP?

No. Box provides a web application, Box Drive, APIs, SDKs, and a command-line interface, and no native SFTP or FTP endpoint. An SFTP client cannot connect directly to a Box account.

How can I receive SFTP uploads in Box?

Mount a Box folder on Files.com and give the partner SFTP access to the mounted folder. The partner uploads to your Files.com hostname and Files.com forwards the file to Box in real time.

Can an SFTP client download files from Box?

Yes, through a Files.com Remote Server Mount. The SFTP client connects to Files.com and sees the mounted Box folder as ordinary files and directories.

Do partners need Box accounts?

Not when they connect through Files.com. Each partner receives a scoped Files.com user with access only to its assigned folders, so no Box seat is created for an external organization.

Why can a Box mount be slower than S3?

Box applies API rate limits, which constrain throughput. Buffered Uploads reduce the effect on the partner by completing the SFTP session before the file is forwarded to Box in the background.

How can I migrate everything out of Box?

For an ongoing transition, a scheduled Sync copies files from Box into Files.com or another destination. For a one-time, large-scale migration, Mover runs a free dry run before the full move.