A Steel Building Manufacturer Serves Builder Portal Media From Private Azure Blob Storage Through Files.com

A North American manufacturer of pre-engineered steel building systems designs and manufactures customized buildings for the low-rise, non-residential market.

Those buildings do not reach customers directly. They are sold and erected through a network of independent builders, and that network runs on content: the product images and PDF documents the manufacturer publishes to its builder portal. The portal read that media straight from Azure Blob Storage accounts. The manufacturer wanted those accounts private and the portal unchanged, with a controlled layer answering for the media in between.

A Portal Reading Straight From Azure Storage

Serving images and PDFs straight out of storage is convenient. A plain URL works in any browser, with nothing to maintain. At the manufacturer, a multi-terabyte marketing archive had built up in the same storage the portal depended on.

As part of its Azure security standards, the manufacturer set a requirement for that storage: every account private, reached only through a layer the company controls.

The problem was never Azure. The problem was that an external-facing application and a multi-terabyte content estate had been built on direct reads from that storage. A private storage account needs something in front of it that the portal can reach. Without that layer, the portal's media goes dark and the marketing archive is stranded with it. The fix had to do three things at once: hold the archive at multi-terabyte scale, keep the portal's media reachable to the people who need it, and connect back to the Azure storage the manufacturer was keeping, through access the company controls.

Files.com in Front of Private Azure Storage

The manufacturer put Files.com in that position: the destination for the content that moved, and the controlled front for the storage that stayed.

The Azure Blob accounts the manufacturer retained are private, and Files.com connects to them through its Azure Blob remote server integrations. Files.com reaches the storage, so the storage itself never has to answer the portal directly. The portal media and marketing assets held there are reached through Files.com, under controlled access.

The large marketing archive came off Azure entirely. It moved onto Files.com storage itself, so the security work never had to wait on marketing to find a new home for years of accumulated content.

For the system administrator who runs the platform, wiring those connections was not a project.

Private Storage, and Nothing Stranded

With the content re-homed, the manufacturer serves portal media under governed access from private storage, and lost neither the portal nor the archive.

• The Azure storage accounts involved are private and are reached through Files.com.
• The builder portal's images and PDFs kept flowing. They are hosted behind Files.com under controlled access.
• Files.com storage grew into the terabytes, driven largely by the marketing content moved onto it, so making the Azure accounts private did not depend on first re-architecting where marketing's files lived.
• The Azure storage the manufacturer kept stayed exactly where it was: private and fronted through Files.com, not migrated.

The Access Model Changed and the Portal Did Not

Today, the manufacturer keeps builder portal content available while the supporting Azure storage accounts stay private. The security requirement no longer dictates whether the portal works.

Files.com separated the portal's availability from how its storage is reached. The access model changed. The business built on it did not have to.