Files.com mounts the Amazon S3, Azure, or Google Cloud bucket you already run and serves it over SFTP, FTPS, FTP, and WebDAV, with the access control, automation, and audit trail object storage never had. Your data stays in your bucket, in your region. Nothing is migrated, and nothing is copied out.
On its own, that bucket has no safe way to let an outsider in. A partner needs an IAM key you’d never hand out, and the storage logs know API calls, not partners. The alternative is a gateway you build, secure, and then babysit forever.
Partners log in over the protocol they already use. Your team gets share links and a full record of every action. Your scripts keep talking to the same storage over the S3-compatible API. One platform sits in front of the cloud you already trust, and you never move a byte to get it.
A bucket is a great place to keep bytes. It was never built to let a partner log in, govern who reaches what, automate the work, or keep a record of it. Files.com adds all four on top, without moving the data.
A bucket only speaks its own cloud API. Files.com serves it over SFTP, FTPS, FTP, and WebDAV, plus an S3-compatible endpoint, so a partner, an app, or a device connects the way it already does. Nobody has to learn your cloud’s API just to send you a file.
Object storage controls access with broad keys and IAM policies. Files.com puts nine permission levels per user or group, folder by folder, in front of the bucket, so a partner reaches exactly the folder they should and nothing else.
Run a workflow the moment a file arrives through Files.com: move it, encrypt it, route it, or hand it to another system. There is no Lambda or Cloud Function to build and babysit, which is the automation plain storage never comes with.
Every login, upload, download, and permission change is written to a tamper-proof audit log you can export or stream to your SIEM. That is the record a SOC 2 review or a partner dispute asks for, and the bucket’s own logs stop at API calls.
A gateway is not a migration. When you mount your bucket, Files.com proxies each upload, download, and delete straight through to it in real time. Nothing is copied onto Files.com, and your files stay in your cloud, in your region, under your own account. You point Files.com at the credentials, and the bucket starts speaking SFTP.
The same mount is how partner data feeds land in the bucket your warehouse reads, one SFTP login per sender, with nothing copied out.
Mount the storage you already run, then put the protocols, identity, and automation on top of it.
Point a Remote Server Mount at your Amazon S3, Azure Blob, Azure Files, Google Cloud Storage, Wasabi, Backblaze B2, or Cloudflare R2 storage. It shows up as a normal Files.com folder, and every operation passes straight through to your bucket in real time.
The same folder is now reachable over SFTP, FTPS, FTP, and WebDAV, plus the web app, the desktop and mobile apps, the CLI, and the REST API. Your partners and apps connect however they already do, against storage that only spoke its own cloud API a minute ago.
Sign-in runs through SSO across Entra ID, Okta, Active Directory, Google, and any SAML provider, with SCIM. When someone leaves, you cut their access in one place in your directory, and their reach into the bucket goes with them.
The Files.com Agent fronts an on-prem NAS or SMB/NFS share over an outbound-only connection, with no inbound firewall change. Mix as many backends as you need on one site. High Availability mounts that fail over between backends are an Enterprise feature.
“Files.com is a secure and easy-to-set-up product with multiple integration options for on-premise servers or any of the public cloud servers. We can have Active Directory-based corporate authentication as well as local user creation on their platform, and we can manage permissions independently.”
“Files.com is versatile — it can manage many different situations from a single platform. We've consolidated multiple tools onto it.”
Real companies. Real file flows. Real results.
When you need to put SFTP and governance in front of a bucket, you are usually choosing between a hyperscaler add-on, a cloud-NAS appliance, a build-it-yourself server, or your cloud’s own console. Here is how Files.com stacks up.
AWS Transfer Family gives you an SFTP endpoint, charges per protocol, and leaves you to assemble access control, automation, sharing, and an audit trail yourself. Files.com comes with all of that on day one, in front of any cloud, not just AWS.
Nasuni and CTERA put an appliance in front of your storage that you deploy, patch, and maintain. Files.com is a hosted platform with nothing to run on-site, and it adds the partner protocols, sharing, and automation a caching gateway doesn’t.
An SFTP server on a VM plus a pile of scripts is one more thing you own, patch, and get paged about. Files.com is bespoke code run in production for 15+ years, with the protocols, governance, and automation already built and nothing for you to maintain.
The S3 or Azure console manages storage. It was never a way to let a partner log in, hand someone a download link, or prove who touched what. Files.com is the file platform the console isn’t, sitting on top of the same bucket.
Most teams don’t have one cloud. They have an S3 bucket here, an Azure container there, a Google Cloud project from an acquisition, and a NAS that has to stay on-prem. Files.com fronts all of them at once and presents them as one set of folders, under one login, with one audit trail.
You can move storage later without anyone noticing, because what your people and partners connect to is Files.com, not the bucket behind it.
The storage stays where it is. The governance a security review expects sits on top of it.
Every action in front of the bucket is written to a tamper-proof audit log and kept for years. You can answer who reached what and when without reconstructing it.
SSO over SAML, SCIM provisioning, MFA, and nine permission levels per user or group. The accounts in front of your storage follow the directory you already manage.
SOC 2 Type II, PCI DSS, a HIPAA BAA, and a GDPR DPA: the attestations a security review asks for are already in place, on top of the cloud storage you already trust.
Standing up a gateway means credentials, permission mapping, and firewall posture. That is the kind of thing you want a real engineer on the other end of the line for.
The people who answer know the platform and the clouds it fronts. You reach an engineer who can stand up a mount with you, not a ticket queue.
Step-by-step setup for every backend, the read-only and read-write modes, credential handling, and the firewall posture, so you can plan the connection before you build it.
White-glove onboarding maps your buckets, sets the permissions, and wires the automation, so the gateway is live in front of your storage in days, not a quarter.
Four shapes account for nearly every customer with Files.com in front of storage they already own.
Trading partners connect over SFTP to a hostname on your domain, and every file they send is an object in your S3, Azure or GCS bucket the moment it arrives, so the pipeline that reads the bucket never knows a transfer happened.
Clients upload and download through a branded web portal or SFTP with per-folder permissions, while the data sits in the account your security team already governs. No one outside the company ever holds a cloud key or a SAS token.
Non-technical teams open the bucket in a browser, a desktop drive or a mounted folder with single sign-on, so the engineer who used to copy files out of S3 by hand stops being the interface.
A SaaS company gives each customer an isolated SFTP tenant backed by that customer’s own bucket, and swaps the storage behind an endpoint without changing a single upload script.
Vendors kept familiar SFTP access while each file landed in Gopuff's own storage for unattended processing.
Read The Story
An Azure Blob Storage mount gives external operators and field-service platforms governed access while keeping data in Corteva's existing storage environment.
Read The Story
Files.com let external partners keep using SFTP while files landed directly in company-controlled S3 under IAM, eliminating the code and AWS resources that once moved them there.
Read The Story
The Files.com Agent connected CCM’s existing Windows share to a hosted FTP endpoint while staff and customers kept working as before.
Read The Story
What teams ask most when putting Files.com in front of their cloud storage.
A cloud storage gateway like Files.com puts a file-transfer and governance layer in front of object storage you already run. Files.com mounts your S3, Azure, or Google Cloud bucket and serves it over SFTP, FTPS, FTP, and WebDAV, with the access control, automation, and audit trail the bucket doesn’t have on its own.
No data moves onto Files.com: with a Remote Server Mount, every upload, download, and delete proxies through to your bucket in real time. Your files stay in your cloud, in your region, under your own account. If you’d rather Files.com also keep a copy for backup or a faster tier, a sync does that to a destination you choose, but the gateway itself moves nothing.
Files.com mounts Amazon S3, Azure Blob, Azure Files, Google Cloud Storage, Wasabi, Backblaze B2, Cloudflare R2, and any S3-compatible storage. On-premise NAS and SMB or NFS shares connect too, through the Files.com Agent over an outbound-only connection.
Files.com is the assembled product: access control, sharing, automation, and audit logging included, in front of any cloud rather than only AWS. AWS Transfer Family is a protocol endpoint that bills $216 a month for SFTP alone, before a second protocol and before any of the pieces you still have to build around it. Files.com Starter is $199 a month with every protocol included.
Azure Blob Storage has a native SFTP option, and for a narrow job it works: one container, SFTP only, files under 500 GB, partners who accept Azure-generated credentials. The endpoint is a port on a bucket, billed at about $216 a month whether or not bytes move, and everything around the port is still yours to build. Files.com mounts the same container and adds the rest: FTPS, FTP, WebDAV, and the web app, partner-scoped credentials with a real audit trail, automation on arrival, and files up to 5 TB.
Files.com exposes an S3-compatible API, so tools that already speak S3 read and write with no code change. Everyone else uses SFTP, the web, the desktop app, or a share link against the same storage.
Partners connect to Files.com over SFTP or FTPS with their own credentials and never touch your cloud account. They see only the folders you grant them, and every transfer is written to the audit log.
Files.com publishes per-tier pricing publicly. The gateway is part of the platform, not a per-protocol surcharge, so fronting your storage with SFTP, sharing, automation, and audit is included rather than metered by connection type.
Mount the container as a Files.com folder through the Azure Blob Storage integration and give each client an account scoped to its own subfolder, over SFTP or the branded web portal. Uploads land in your storage account as blobs, the client never sees a key or a SAS token, and every upload is logged against the client.
Repoint the Files.com folder at the new bucket or region. The hostname, credentials and paths customers use stay the same, so their scripts keep running while the data lands somewhere new, and Files.com syncs the existing content across if the history should move too.
Yes. Files.com mounts remote S3 buckets and SFTP servers as folders on your site, so staff browse and download the partner’s files in the web app or desktop app under your permissions and your audit log, and nobody hands out the partner’s credentials.
Mount the S3, Azure, or Google Cloud storage you already run, and add SFTP, sharing, automation, and an audit trail on top, with no migration and no second copy. Connect a bucket during the 7-day free trial and move a file over SFTP in minutes.
No credit card required • Free for 7 days • Live in minutes
