City of Las Vegas Moves Four-Protocol File Exchange from One Server to 128 Files.com Child Sites

The City of Las Vegas is the municipal government of Nevada’s largest city, serving more than 640,000 residents across 133 square miles through departments ranging from Municipal Court and public safety to planning, business licensing, HR, and parks and recreation.

Every one of those departments exchanges files with outside parties: vendors, contractors, partner organizations, records processors. For years, all of that traffic entered and left the city through a single on-premise transfer server, owned, patched and kept online by the city’s own systems administrators.

The city moved that four-protocol perimeter to Files.com while preserving its .gov identity and keeping the endpoint inside its existing security scanning and review. What once ran through one city-operated server now spans 128 Files.com child sites under the same account and governance regime.

One Server Carried Every Department’s External Exchange

The server spoke FTP, SFTP and FTPS, with WebDAV alongside, because the city’s counterparties spoke all of them. Everything about it belonged to a small systems administration team: keeping it patched, keeping it reachable from the internet, keeping every protocol working, and fielding the problem whenever a partner’s connection failed. It was an internet-facing system inside the city’s own infrastructure, and some of the transfers crossing it carried personally identifiable information.

Meanwhile the load on it only grew. More departments needed governed exchange with outside vendors, and each new counterparty added to what the same small team had to support. The city had outgrown operating its own transfer perimeter.

Why the City Couldn’t Just Switch It Off

An external file endpoint is not something a government cuts over casually. Outside organizations connect to it, each over whatever protocol their own systems speak, and none of them can be asked to change on the city’s schedule.

Whatever replaced the server also had to live under city governance rather than around it. The city’s security team has a third-party vendor run periodic scans across every domain entry the city exposes, and a transfer endpoint that could not sit inside that scanning was not an option. Transfers carrying PII are held to the city’s own security review before they run.

So the replacement had a specification before it had a name. Keep every protocol partners already used: FTP, SFTP, FTPS and WebDAV. Present an address that belongs to the city, not to a vendor. Fit inside the city’s security scanning and review. And take the operation of the server itself away from the systems team entirely.

The city selected Files.com to be that hosted endpoint.

A Hosted Endpoint on the City’s Own .gov Domain

Files.com now hosts the city’s transfer estate over all four protocols, so an outside partner connects the same way it always did. The endpoint carries the city’s name: using the Files.com custom domain capability, a subdomain of the city’s own .gov domain points at the account through a CNAME, with dedicated IP addresses behind it. A vendor logging in sees a City of Las Vegas address.

Inside, Files.com folder permissions and child sites keep departmental and vendor access bounded under one account. Vendors and partners log into scoped folders to drop off and retrieve files, while city staff sign in through Okta, the city’s existing single sign-on. External users authenticate with credentials limited to their own folders. Where a workload needs a separate administrative boundary, the city uses Files.com child sites with their own users and settings.

None of it sits outside the city’s security regime. The platform’s domain entry is included in the periodic scans the city’s security vendor runs across every city domain, and transfers carrying PII moved onto the platform only after it had cleared the city’s own security review.

From One Server to 128 Child Sites

With the hosted endpoint in production, the City of Las Vegas retired its on-premise transfer server and replaced a system it operated with a service its departments use.

• The city no longer runs an internet-facing transfer server. Patching, availability and protocol support for the exchange perimeter are Files.com’s job now, not the systems team’s.
• Partners kept their connections. The same protocols work as before, at an address on the city’s own domain.
• Bringing a new department’s vendor exchange onto the platform is configuration, not infrastructure: folders, permissions and credentials on an estate that already exists. Planning, business licensing and safety teams have come on since, and use keeps spreading across departments.
• The estate has grown to 128 child sites, each a bounded space for a department or workload, all under one account and one governance regime.

The third point is the one that compounds. Every department that arrives gets the same boundary, the same city-branded address and the same governance the first one got, and adds nothing new for the systems team to keep alive.

A Perimeter the City Governs but No Longer Operates

Today, when a Las Vegas department needs to exchange files with an outside vendor, nobody stands anything up. The department gets folders or a child site on Files.com. The vendor gets a credential and connects over the protocol it already uses, to an address that carries the city’s name. The city’s security vendor scans that endpoint along with every other domain the city exposes. What used to be a server a small team kept patched and online at the edge of an entire government is now a platform the same team administers: they decide who reaches what, and Files.com keeps it running.

The city did not move its vendors to a portal to get there, and it did not move them off its own domain. The protocols stayed, the .gov address stayed, and the security regime stayed. A government’s external file-transfer perimeter can move to a hosted platform inside its existing scanning and review, and the only thing that leaves the building is the server.