A Snowflake external stage can read from any S3-compatible endpoint — and Files.com is one. Partners deliver over SFTP, and COPY INTO loads their files straight from the folders they land in, with no bucket in between. Mount any source filesystem behind the same folders and the warehouse reads that too.
No credit card required · 7-day free trial · Live in minutes
Real companies. Real file flows. Real results.
Snowflake ingests files from stages. A stage is object storage Snowflake can list and read. The standard answer is a cloud bucket plus everything you build around it: the scripts that carry partner files in, the decryption step, the renaming, the monitoring. The files themselves start somewhere much messier: counterparties on SFTP, business systems exporting on a schedule, teams uploading from a browser.
Files.com is the stage itself, with the whole file layer built in. Snowflake reads your site directly through the S3-compatible endpoint, while partner onboarding, PGP, Automations, and the audit trail govern everything that happens before the COPY and after the unload.
Partner and vendor feeds land the same way whichever storage the warehouse reads: a drop point per sender, and every file in your own bucket the moment it arrives.
Stages without buckets, regulated intake, and outbound delivery, all running on Files.com in production.
COPY INTO reads your Files.com folders through the S3-compatible endpoint, the same place partner files already land. Skipping the staging bucket means no second copy of the data and no copy job to babysit between arrival and load.
The endpoint is the access layer, not the storage layer. Mount S3, Azure, SharePoint, or an on-premises share behind the same folders, and the stage reads whatever lives there: a real-time pass-through from any filesystem to the warehouse.
When the inbound files are PHI or financial data, the front door matters as much as the load: each counterparty scoped to its own credential and folder, decryption on arrival, and a HIPAA business associate agreement covering the layer the warehouse reads from.
The path runs both directions. Snowflake unloads daily files with COPY INTO, and Automations rename each one in flight to the exact name a counterparty’s system expects and deliver it: SFTP to one recipient, a cloud bucket for the next.
Business-system exports commonly arrive GPG-encrypted on a schedule. Decryption runs in the flow, staging lands the file where the load reads, and one monitored job replaces the scripts and hand loads that used to carry it.
A warehouse load that reads an empty stage doesn’t fail: it succeeds at loading nothing. Delivery monitoring knows when each inbound feed is due and alerts when the window closes without files, before the dashboards go quietly stale.
Data engineers don’t point a stage at an endpoint they haven’t vetted.
CREATE STAGE with URL = s3compat://your-subdomain/path/, ENDPOINT = s3.files.com, and an S3-compatible key pair as credentials. The bucket name is your Files.com subdomain; the path is the folder the stage reads.
Snowflake permits connections to s3.files.com on all accounts by default, so there is no support ticket to open. A custom-domain S3 endpoint works too; that one Snowflake support enables on request.
An S3-compatible API key belongs to a Files.com user and inherits that user’s exact folder access. Read permission is enough to load; add write for unloads. The stage sees what that user sees, and nothing else.
The endpoint lists folders recursively, so a stage pointed at a folder reads every file beneath it: no Automation flattening files into one directory first, and no per-subfolder stage definitions.
The company configured Files.com’s S3-compatible endpoint as a Snowflake external stage, so the warehouse reads vendor extracts where they land and the Azure Blob copy is gone.
Read The Story
The new pipeline had to reach an internal SFTP server without exposing it, decrypt CDK exports in flight, and preserve every system already in place.
Read The Story
Files.com gave an alternative asset manager’s technology team a repeatable way to absorb each counterparty’s SFTP, UAT, private-network, and retention requirements.
Read The Story
Files.com became the bidirectional exchange layer, letting a small data team route PHI-bearing files across more than 100 employer-client folder structures without building new warehouse pipelines.
Read The Story
“Files.com's strengths are simplicity, ease of use, and the cloud connectors. We don't have to invent custom infrastructure for every partner.”
“Files.com is versatile — it can manage many different situations from a single platform. We've consolidated multiple tools onto it.”
“Files.com is robust and scales to a large enterprise. We get multiple files per minute, per second — and we're a 24/7 organization, so everything has to always be up.”
What data engineering teams ask most when wiring file intake to Snowflake.
Not directly: Snowflake loads from stages, not from SFTP servers. Files.com closes that gap from both sides. Counterparties deliver over SFTP, FTPS, AS2, or a browser, and a Snowflake external stage reads those same files through the Files.com S3-compatible endpoint, with no separate bucket and no ETL middleware in between.
A Snowflake external stage connects to Files.com with a standard stage definition: URL = s3compat://your-subdomain/path/, ENDPOINT = s3.files.com, and S3-compatible API credentials from your Files.com site. Snowflake allows the s3.files.com endpoint on all accounts by default, so the stage works without a Snowflake support request.
COPY INTO works in both directions against a Files.com stage: loading tables from the stage and unloading query results back to it. External tables and directory tables work with manual refresh, and the Snowpipe REST endpoint handles programmatic loads. Event-driven Snowpipe auto-ingest is an AWS-notification feature, so scheduled loads run as Snowflake tasks instead.
Yes. That’s the pass-through. Remote Server Mounts present S3, Azure, Google Cloud, SharePoint, or on-premises storage as Files.com folders, and the stage reads through them in real time. Snowflake gets one endpoint; the bytes stay wherever they already live.
Yes. TransformScript converts CSV, XML, and JSON in the flow, and Automations rename, split, and route files as they arrive, so what the stage reads is already in the shape the COPY expects.
Files.com accepts partner files however the counterparty can send them: SFTP, FTPS, AS2, the S3 API, a browser upload, or an email inbox that turns attachments into files. Each sender gets its own scoped credential and folder, and every arrival is logged and can fire an automation.
Yes. COPY INTO unloads to the stage, and Automations take it from there: renaming to each recipient’s convention, encrypting under a counterparty’s PGP key where mandated, and delivering over whatever protocol that recipient runs.
Files.com delivery monitoring defines when each inbound feed is due and alerts when a window closes without files. A silent upstream failure becomes a same-hour alert instead of a dashboard quietly showing yesterday’s numbers.
Yes. Files.com runs SOC 2 Type II, encrypts in transit and at rest, and logs every access. A pre-approved HIPAA business associate agreement comes with Files.com Enterprise. PGP decryption, per-counterparty isolation, and retention policies run as configuration on the same folders the stage reads.
Files.com replaces the bucket-and-glue stack: a staging bucket, the scripts that move partner files into it, the decryption step in the middle, and the monitoring nobody built. One governed layer receives, transforms, and stages the files, and Snowflake reads it directly.
Receive, transform, and stage every file your warehouse loads, on one governed platform Snowflake reads directly.
No credit card required • Free for 7 days • Live in minutes