Files.com mounts the Amazon S3, Azure, or Google Cloud bucket you already run and serves it over SFTP, FTP, FTPS, 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 shouldn’t be handing out, the console keeps no log an auditor accepts, and 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, FTP, FTPS, 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 lands: 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 doesn’t keep it.
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.
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, 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, FTP, FTPS, 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. See the full comparison.
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.
Your data stays where it lives. 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, kept for years, and exportable or streamable to your SIEM. 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, HIPAA, and GDPR. The certifications and controls a security review asks for come built in, 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.
What teams ask most when putting Files.com in front of their cloud storage.
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 free trial and move a file over SFTP in minutes.
No credit card required • Free for 7 days • Live in minutes