A Canadian Municipality Retires CrushFTP for Files.com Hosted in Canada

A Canadian municipal government is unusually self-reliant: it runs more of its own services and infrastructure in-house than most cities its size, including its own utilities.

That habit of running its own infrastructure extended to file transfer. Daily accounting feeds from cloud vendor systems flow into the city’s J.D. Edwards ERP. Engineering trades enormous drawing sets with outside contractors and consultants. Departments exchange files with developers and construction firms every week. All of it ran through a single SFTP and FTP server the city hosted itself, in its own DMZ.

The Server in the DMZ That Needed Patching Year After Year

That server ran CrushFTP, a self-hosted file transfer product with a public record of critical vulnerabilities landing year after year. For three consecutive years, a vendor advisory meant urgent, drop-everything patching of an internet-facing server that every department depended on. The city’s IT team carried all of it: the operating system, the perimeter, the patch windows, and the maintenance in between. And because the server sat in the DMZ by design, reachable from the internet so that vendors and contractors could deliver files, every one of those vulnerabilities was a live question rather than a theoretical one.

This was a standing condition, not a bad year. As long as the city self-hosted its transfer service, every flaw in someone else’s code was the city’s emergency.

A Residency Mandate and Two Workloads on One Server

The obvious question is why a transfer server was still self-hosted at all. The answer is a hard requirement: as a municipal government, the city must keep its data and servers hosted within a Canadian region. The requirement is mandatory, not aspirational, and it is why the service sat in the city’s own DMZ. In-country had been read as in-house. But Canadian residency did not require self-hosting.

The server also did two jobs at once. It was the machine endpoint for the nightly general-ledger extracts headed into J.D. Edwards, and it was the human channel for departments exchanging files with outside firms. A replacement that handled one job and not the other would have split the estate into more tools, not fewer.

So the requirements wrote themselves. The replacement had to be run by a team whose entire job is running it, so the maintenance and security overhead left the building for good. It had to keep data and servers in Canada. It had to speak SFTP and FTP, so vendor systems could reconnect without redevelopment. And it had to give non-technical staff a browser instead of an FTP client, so one platform could carry both workloads.

The city selected Files.com to be that platform.

Two Sites in Canada, Scoped Vendor Feeds, and an Outbound-Only Agent

Files.com became the city’s single file transfer service: managed, hosted in Canada, with nothing internet-facing left inside the city’s network to defend.

Residency was answered in configuration on day one. The city provisioned separate test and production sites, both stored in Files.com’s Canadian region, AWS Canada Central, each with a geo-restriction allow-list limiting access to Canada, and both running under the city’s own domain and branding.

The machine workload moved first. Two cloud systems, Xplor for recreation management and Computrol for fuel management, push daily general-ledger CSV extracts into Files.com over SFTP and FTP, each carrying hundreds of transactions. Each vendor connects through a dedicated service account limited to its own upload folder. Inside the city’s network, a Files.com Agent lands arriving files on a network path used by J.D. Edwards. The Agent connects outbound only, so the integration required no inbound firewall rule and put no listener back in a DMZ. The city’s existing SSIS packages now read from that path instead of pulling files off an FTP server. The first vendor’s scheduled nightly feed was running about three weeks after the Files.com site was activated, and both integrations were then moved into production.

The people came second, deliberately. The city began a soft rollout in Engineering, whose consultants and contractors exchange CAD and PDF drawing sets running to tens of gigabytes. Those now move through password-protected Files.com share links with expiration dates, and staff work entirely in the browser, with nothing to install on either end. Engineering staff hold group and folder admin rights over their own project folders, adding users and granting access themselves rather than routing every request through IT. The exchange is transient by design: a default expiration clears what arrives, and anything that constitutes an official city record is filed into the city’s OpenText records system, which remains the system of record.

Unattended Daily Feeds and Nothing Left to Patch

With Files.com in production, the city replaced a server it had to defend with a service it only has to use.

• The two daily vendor feeds run unattended into J.D. Edwards, with nobody moving files between systems by hand.
• The mandatory residency requirement is met without self-hosting: both sites live in AWS Canada Central behind a Canada-only allow-list.
• A vendor’s critical advisory is no longer the city’s emergency, because there is no internet-facing transfer server in the DMZ left to patch.
• Machine and human workloads share one governed platform: the same site that feeds the ERP carries drawing sets of tens of gigabytes between Engineering and its contractors, while Engineering staff administer access to their own project folders.

The pattern also repeats cheaply. The next vendor system that needs to deliver files to the city is a scoped service account and an upload folder, landing on the same internal path through the same Agent, with no new infrastructure and no new firewall conversation.

Residency Without Self-Hosting

The lesson in the city’s move is about the mandate itself. The requirement that data and servers stay in Canada says where the data must live. It never said the city had to patch the server. The city kept every byte in Canada and got out of the business of defending internet-facing infrastructure.