Looks Like An S3 Bucket
Files.com presents your site as an S3 bucket over HTTPS on port 443. Any standard S3 client or SDK connects and runs PUT, GET, and LIST against it the way it would against AWS — no special build.
Point What You Already Have At Files.com
Half the cost of adopting a new file platform is the integration work: rewriting the scripts, swapping the SDK, retraining the pipeline that already knows how to talk to a bucket. The S3 endpoint removes that cost. Anything that already speaks S3 — your tools, your apps, your automations — can reach Files.com directly, with the code it already has.
The endpoint is the access layer, not the storage layer. The same files you read and write over S3 are reachable over SFTP, FTPS, and the web, sitting on top of whichever backend you run — Files.com storage or your own connected bucket. You get S3 access without locking your data into one store.
How The S3-Compatible Endpoint Works
A real S3 surface — standard clients, SigV4 keys, both addressing styles — built and maintained by Files.com.
Signs In With SigV4 Keys
Authentication uses S3-compatible API keys — an Access Key ID and Secret Access Key — over AWS Signature Version 4 (SigV4), the same signing scheme S3 clients already use. Any SigV4-capable client works normally.
Takes Path Or Virtual-Hosted URLs
Both addressing styles work — path-style (s3.files.com/default/path) and virtual-hosted-style (mysite.s3.files.com/path). Region is ignored, so a client that insists on us-east-1 connects fine.
Built And Run In-House
Files.com builds and maintains the S3 endpoint itself. It isn’t a third-party gateway bolted on the side. It’s part of the platform, supported by the same team that supports everything else.
It Plugs Into The Rest Of Your Stack
CI/CD Artifact Delivery
Push build artifacts from your pipeline to Files.com over S3 the way you push to a bucket today — your CI config barely changes, and the files land where the rest of your team and workflows can reach them.
Equipment And Render Platforms
Lab equipment, instruments, and cloud rendering platforms that only know how to export over S3 can push straight into Files.com, no custom integration to write for each one.
Same Permissions As Everything Else
An S3 user key inherits that Files.com user’s exact permissions and folder access — people see only what they’re authorized to. The same logging, link sharing, and access control cover S3 traffic and every other protocol alike.
S3 Uploads Trigger The Platform
A file pushed over S3 fires your automations, shows up in syncs and remote mounts, and follows your retention rules, exactly like an upload over SFTP or the web. Nothing about it is treated as second-class.
One Door Into The Same Governed Platform
A file pushed over S3 is treated like any other upload. It fires the same automations, appears in the same syncs and remote mounts, follows the same retention and lifecycle rules, and is logged the same way as a file that arrived over SFTP or the web. S3 isn’t a side channel with its own rules — it’s another way into one governed platform.
The S3-compatible endpoint is part of the platform, alongside the SFTP and FTP support and the rest of the protocol surface. See what each plan includes on the pricing page.
S3-Compatible API Questions
What teams ask about pointing their existing S3 clients, SDKs, and pipelines at Files.com.
Connect Your S3 Tools To Files.com
Start a free trial, generate an S3-compatible key, and point your existing S3 client or pipeline at Files.com — PUT, GET, and LIST with no code change.
No credit card required • Free for 7 days • Live in minutes