A Public-Sector AI Company Retired Microsoft Azure Blob Storage SFTP and Standardized Government Onboarding With Files.com

A US public-sector AI software company builds private AI assistants for city and county governments. Each one is constructed entirely from the government’s own records: board and council minutes, staff reports, zoning codes, master plans, internal policies. Its roster of local governments grew steadily.

That model has one structural consequence. Before any assistant exists, the government has to hand over its records. Every engagement begins with a delivery: decades of minutes, planning case files, scanned documents, whole databases. For the company, file intake is not back-office plumbing. It is the first thing every new client does. As more governments signed on, the intake side job scaled one-for-one with the thing the business most wanted to grow.

Client Records Came In Through a Storage Endpoint an Engineer Had to Run

Intake ran through the infrastructure that happened to be closest to hand: an Azure Blob Storage container with its SFTP endpoint switched on. When a new government signed, an engineer cut a credential for it and administered the account by hand. It worked, in the sense that files arrived. Everything around it was a tax. The endpoint needed key management, patching, and user administration, all of it done by hand at a small company serving a growing roster of government clients. And a government’s first hands-on contact with the company was a bare storage login.

The deliveries were not small. Government record libraries arrive as database dumps, large individual scanned files, and compressed directories running to hundreds of gigabytes. The people sending them are agency staff, and many are not file-transfer specialists. The intake had to absorb all of that, and it was doing so as an engineering side job.

The arrangement fit while the roster was small. With a handful of clients, cutting a credential by hand for each one was a minor task, and a young AI company was not going to divert engineers to build an intake portal. Growth changed the arithmetic. Every new client meant another credential to cut and another account to administer, and the work sat on the critical path of every engagement.

What replaced it had to take uploads from agency staff who might have nothing but a browser, and from municipal IT departments that already run SFTP clients. It had to keep every government’s records apart from every other’s, and carry individual files of tens of gigabytes and deliveries far larger. It also had to run without an endpoint to patch or credentials hand-built against a storage account, while presenting a government client with something better than a raw login.

A Folder, a Credential, and a Dropoff for Every Government

The company selected Files.com to provide that intake layer. The first government’s flow was stood up as its own workstream. New clients then came onto the same pattern.

Each government gets its own folder on the Files.com site, with a dropoff area inside it for inbound records. A client whose IT department runs an SFTP client connects with a Files.com SFTP account, scoped through folder-based permissions to that client’s folder and nothing else. Staff who have only a browser upload through the web interface or a Files.com Inbox, an upload page that requires no account and no installed software. Either way, the files land in that government’s dropoff area and enter the processing that turns a records library into that client’s knowledge base.

The endpoint itself became Files.com’s job to run. There is no server for the company to patch and no key management carried as a side project. Each client’s account is provisioned and scoped on the platform, and standing up the next one means creating a folder and a credential.

Intake Became a Standard Part of Onboarding

With intake in production on Files.com, the company replaced an engineering exception with a standard step in bringing on a client.

New clients are now told during onboarding that their SFTP is being set up on Files.com. Intake no longer trails the engagement as a separate engineering task; it is part of the standard script. Client records now arrive by the terabyte through the same channel.

The Handover Is Now Part of the Product

The company sells AI built entirely from what its clients hand over, and since the move to Files.com, the handover runs through the platform. Bringing on a city used to begin with an engineer cutting a credential against a storage container. Today it begins with the client being shown their own intake: here is your folder, here is your account, start sending records. An agency clerk with a browser can deliver the same library a municipal IT department delivers over SFTP, and either way the records land isolated and in the right place, ready for processing.

A storage container wearing an SFTP endpoint had turned every new customer into a credential and maintenance task. A managed, per-client intake on Files.com turned that same moment into a standard step of onboarding. For a company whose product begins the day the records arrive, that first day now works like the rest of it.