Gopuff Replaced Manual Vendor File Delivery With a Files.com Hub Connecting Azure and Oracle Cloud ERP

Gopuff built instant commerce. From company-owned micro-fulfillment centers, it delivers everyday goods directly to customers. The model is unusual: where competitors run marketplaces that connect users, drivers, and retailers, Gopuff owns, stocks, and staffs its own fulfillment network end to end.

Owning the chain has a consequence for data. Its vendors and platform partners, along with the Oracle Cloud ERP that runs the corporate side, exchange files with Gopuff directly. Across that network, every file needs a place to land.

With Files.com in production, Gopuff replaced an exchange built on email exports and manual delivery with a standing pattern it repeats for every new counterparty: SFTP deliveries land directly in its Azure storage, where Oracle and other internal services process them continuously.

Exports by Email, Manual Deliveries by Engineers

When Gopuff came to Files.com in 2021, its file exchange had not caught up with its business. Source systems could get data out one way: by email. And delivering vendor data to an external partner meant an engineer connecting to that partner's own SFTP server and pushing the files by hand, one counterparty at a time.

The cost was not any single transfer. It was that every exchange was a one-off. Onboarding a new vendor meant building another manual delivery routine. Connecting a new internal system meant another bespoke path. There was no governed place where a vendor, a partner, or one of Gopuff's own services could drop a file and trust that the right downstream process would pick it up. Each new counterparty meant more engineering time spent doing courier work.

Vendors, Azure, and Oracle Did Not Share a Surface

The fix was not obvious, because the exchange spanned three worlds with no natural meeting point. External vendors spoke SFTP and FTP. Gopuff's own estate ran on Azure, with Blob Storage holding the data and Azure Functions and Postgres behind it. And the corporate side ran on Oracle Cloud ERP, which consumed vendor files continuously through Oracle Integration Cloud.

Security narrowed the field further. Gopuff treated Okta single sign-on as a hard gate: no production use until workforce access ran through it. Vendor connections had to authenticate with SSH keys. At least one vendor would accept inbound connections only from whitelisted IP addresses. And the data itself had to reside in Gopuff's own Azure instance, not accumulate as a second copy somewhere else.

So the exchange point had to speak the protocols vendors already had, mount onto the Azure storage Gopuff already ran, deliver outbound to vendor-controlled servers from fixed addresses, and put every account behind keys and single sign-on. Gopuff selected Files.com to be that exchange point.

One Site All Three Sides Could Reach

Files.com became the surface all three worlds share: vendors reach it over the protocols they already use, Azure is the storage behind it, and Oracle polls it as the consumer.

On the inbound side, each vendor gets its own SFTP account, authenticated by SSH key and scoped to its own folder, on Gopuff's own branded domain. Accounts are provisioned in bulk from the Files.com CLI, so standing up a new vendor is routine provisioning rather than an integration project.

Behind those folders, a Files.com Remote Server Mount links the site to Gopuff's Azure Blob Storage. Files.com presents the folders and enforces who can reach them; the data resides in Gopuff's Azure instance from the moment a vendor drops it. Nothing gets copied home afterward, because it is already home.

Gopuff's Azure Function also reads and writes against the site over SFTP, while Oracle Integration Cloud polls it and picks up files as they are dropped, around the clock.

Outbound delivery runs through the platform too. For the vendor that requires IP whitelisting, an SFTP remote server on Files.com pushes files to the vendor's own endpoint using the site's dedicated IP addresses. The vendor whitelists those fixed addresses once, and no engineer ever logs in to deliver a file again.

A New Vendor Is a Keyed Account and a Folder

That standing pattern changed the work:

• Onboarding a vendor became provisioning: a keyed SFTP account and a scoped folder, instead of a new delivery routine built and run by an engineer.
• Vendor data lands directly in Gopuff's own Azure storage the moment it is dropped, with no one carrying it downstream.
• Oracle Cloud ERP picks up files from the site 24/7, as they arrive, without a person in the loop.
• The same site carries Gopuff's exchange with major delivery marketplaces, e-commerce platforms, and HR systems: the partner integrations its retail business depends on.

The pattern then outgrew its first problem. What began as a handful of human logins is now a site populated mostly by system accounts, services dropping, collecting, and routing files across multiple remote servers. Whole classes of internal system are built on it.

“We have entire systems within our company that completely rely on SFTP file drops, transformation, and processing.”

The Pattern Gopuff Now Builds On

Today, the file layer between Gopuff's vendors, its Azure estate, and its Oracle ERP runs as one Files.com site instead of a set of one-off deliveries. A vendor drops a file. It already resides in Gopuff's Azure. A service transforms it, and the ERP collects it before anyone has asked. The engineer who used to push files onto other companies' servers does not appear in that sentence, and that is the change. For a company that owns every step from vendor to doorstep, standardizing exchange on Files.com turned partner and system integration into something Gopuff repeats, a keyed account and a folder at a time, instead of something it builds.