Algoma Steel Connects SAP Datasphere to Its On-Premises Plant Without Building an SFTP Server
Algoma Steel is an integrated Canadian steel producer supplying plate and coil products.
The systems that run the plant stay on premises by design. Steel production is continuous, and the process systems behind it have to be available every hour of every day, so Algoma keeps them in the building rather than staking them on cloud availability. That posture is deliberate, and it set up a collision. Clients and partners needed a place to exchange files with Algoma. SAP Datasphere, running in the cloud, needed to deliver files into those same on-premises systems. Both required exactly the thing the posture forbids: an endpoint on the internet with a path into the plant.
On-Prem by Design, With Nowhere to Drop a File
Algoma had no SFTP capability at all. The business needed a location to put individual files for clients and partners to retrieve, and to pull files back down itself, and it needed SAP Datasphere output to land in on-premises systems. Neither exchange had anywhere to happen.
The one in-house answer was to build the endpoint: stand up an SFTP server, put it on the internet, and own it. For the systems architecture team, owning it meant a host to keep alive, an operating system to patch on the schedule of whoever finds the next vulnerability, keys and accounts to manage, and the security posture of a permanently exposed machine to defend. All of it indefinitely, and none of it steelmaking. That server would also have been the one standing door into an environment Algoma keeps sealed on purpose.
“We didn't really want to stand up a server with SFTP. I wanted to take advantage of the services that companies like yours provide and not have to deal with managing the whole stack.”
An SFTP Layer in Front of the Plant, Not Inside It
The requirement, restated as a specification: a dedicated SFTP endpoint that clients, partners, and SAP could reach; a path from that endpoint into the plant that opened no inbound port; and no server for Algoma to run. Algoma selected Files.com to provide that managed SFTP layer.
On the outside, Files.com is the endpoint. Clients and partners connect to it, drop files, and retrieve what Algoma has left for them. The same endpoint receives files from SAP: Algoma created a dedicated service account for SAP Datasphere, authenticated by SSH key rather than a password, and handed the public key to its SAP team for the inbound connection.
On the inside, two on-premises Files.com Agents carry files the rest of the way. An Agent runs on a server inside Algoma's network and connects outward to Files.com, so nothing in the plant listens for the internet and no inbound firewall rule exists. When Datasphere delivers a file, the Agent brings it in and lands it on the on-premises systems that need it. Files.com sits in that path as a second firewall layer in front of the plant environment: the only thing exposed to the internet is Files.com itself.
Algoma deployed the two Agents across development and production, giving the SAP integration parallel paths under its existing change discipline. It governed access to the managed endpoint with country-based IP restrictions, single sign-on for internal users, file expiration, and granular permissions for external parties.
SFTP Became a Service Instead of a Server
With the workflow in production, Algoma replaced a server it would have had to build with a service it configures. SAP Datasphere delivery and client and partner exchanges now run through the same managed endpoint, while the systems architecture team owns no internet-facing host to patch, maintain, or defend.
The compounding result is what happened next. New file workloads landed on it instead of spawning new infrastructure. Internal applications now stage files on Files.com and periodically pull them back down, and the platform holds the printing configuration for Algoma's XM Cloud environment. Each arrived on an already governed platform, with nothing new to build and nothing new to expose.
The Plant Stays Sealed
Today, when the business brings the next file exchange—whether from a partner, a cloud application, or an internal system—meeting it means configuring the platform rather than building and defending a server. The one internet-facing piece of Algoma's file exchange is Files.com's to run.
Related Customer Stories
Manufacturing
Porsche Cars North America Built a Files.com Alternative to Email and FileZilla That Teams Adopted Without Promotion
To clear Porsche AG's hosting rules, the channel combined federated identity, Porsche branding, and Canadian data residency for workflows across the business.
Read story →
Manufacturing
Qualcomm Uses Files.com for Modem-Log Collection Across Three Simultaneous Carrier Assessments
A shared collection layer let contractor teams upload multi-gigabyte handset logs without VPN access while Qualcomm kept its analysis systems on-prem.
Read story →
Manufacturing
Acer America Retired Its Warranty Repair FTP Server With Files.com—Without Changing the Address
A weekend cutover moved the repair channel to Files.com while preserving the Acer endpoint and protocols its service providers already used.
Read story →