TL;DR
- Fullscript's new warehouse sites run automated picking robots that depend entirely on stable, high-throughput WiFi, so we designed a network stack that can survive almost anything
- Ashland, VA was our first build: dual fiber ISPs with separate last-mile terminations, Starlink as a third WAN path, stadium-grade Ubiquiti UWB-XG access points for the robot zone, and robot traffic isolated on dedicated VLANs with uplinks split across two IDF locations
- Chandler, AZ takes everything we learned and pushes it further: a web-style optical distribution framework, dual power feeds with independent UPS units and an on-site generator, 10Gbps primary AP uplinks with 1Gbps backup paths, and, because three ISP options apparently weren't enough, a Unifi 5G cellular device for out-of-band access
- The throughline across both sites: don't design for the normal case, design for the failure case
A first for IT at Fullscript
This is the first Builder’s Blog post from Fullscript's IT department, and we wanted to start with something that felt representative of the kind of work we do: infrastructure decisions that aren't glamorous on the surface, but ones where the wrong call can bring a warehouse to a standstill.
When our operations team came to us with plans for a new automated warehouse in Ashland, VA, it wasn't a typical network buildout request. This wasn't a corporate office where a flaky connection means someone refreshes their email twice. This was a site where robots (actual autonomous picking robots) would be pulling orders from shelves and communicating in real time to a local production server. No WiFi meant no robots. No robots meant no orders fulfilled. The stakes were clear from day one.
We decided early that the benchmark we'd hold ourselves to wasn't "warehouse-grade." It was hospital-grade. Hospitals don't get to have network downtime. Neither would we.
Ashland, VA: The first build
Starting with the constraint that mattered most
The robot picking system at Ashland is the operational heartbeat of the site. Robots communicate continuously with a local production server to receive task assignments: which shelf, which item, where to bring it. That communication happens over WiFi. Lose the WiFi, lose the robots. Lose the robots, and you've got a very large, very quiet warehouse accomplishing nothing.
At the same time, the site pulls order data from Fullscript's systems in real time as orders are placed and routed. The internet connection had to be just as bulletproof as the internal network.
That gave us two clear design mandates: rock-solid internal wireless, and rock-solid WAN connectivity. We treated them as separate problems that needed the same level of engineering attention.
WiFi: going beyond standard enterprise coverage
For most enterprise WiFi deployments, you're solving for people: density, roaming, throughput per device. For the robot zone, we had a different set of requirements. The devices are low to the ground, they move constantly through dense shelving environments, and they absolutely cannot tolerate dropped connections or roaming gaps that cause even a brief interruption to their task stream.
Our answer was the Ubiquiti UniFi UWB-XG, a high-density access point normally used for large venues like arenas and stadiums. These APs are engineered for environments with hundreds of concurrent clients in a tight area, with radios and antenna configurations designed to handle high client density without sacrificing per-device reliability.
We deployed 7 of these APs specifically for the robot zone, mounted at 6 feet off the ground rather than ceiling height. That positioning was intentional: ceiling mounts in a warehouse with tall shelving can create coverage shadows at floor level where the robots operate. We used Ekahau WiFi planning software to model signal propagation and determine the exact placement, pitch, and angle of each AP before a single mount went in the wall. No guesswork, no walk-around-and-see-how-it-feels. We modelled it, validated it, and deployed to spec.
The robot network is also completely segmented on its own VLAN, isolated from general site traffic. This isn't just a security posture; it's a performance decision. We didn't want a firmware update on a corporate laptop competing for bandwidth with a robot mid-pick.
For an additional layer of redundancy, the uplinks from the robot zone APs are split across two separate IDF locations. If one IDF goes down, the APs connected to the other keep the robots running. This is a pattern we'd revisit and expand significantly at our second site.
MC-LAG and the switching stack
The switching infrastructure at Ashland runs on the Ubiquiti UniFi platform, using Multi-Chassis Link Aggregation (MC-LAG) for core redundancy. For the uninitiated: MC-LAG lets you bundle links from a single device across two separate switches, so if one switch fails, the connection stays up through the other. You get the throughput benefits of link aggregation and the fault tolerance of having no single point of failure at the core.
This matters in a warehouse because the consequences of a core switch failure are immediate and total. With MC-LAG, a switch can be taken offline for maintenance or fail unexpectedly, and connected devices don't notice.
WAN: three paths, separate last miles
For internet connectivity, we implemented a tiered WAN design:
Primary and secondary: Two independent fiber ISPs with separate last-mile terminations, meaning the physical cables entering the building come from different carriers and follow different paths. This is an important distinction from a simpler "dual ISP" setup where both connections share infrastructure at some point before they reach you. Separate last-mile terminations mean a backhoe taking out one carrier's conduit on one side of the building doesn't take out both your connections.
Tertiary: Starlink as a third WAN path. Satellite connectivity gives us a path to the internet that has almost no infrastructure overlap with ground-based fiber: different physical medium, different routing, different failure modes. In a true worst-case scenario where both fiber providers have outages simultaneously (rare, but not impossible), Starlink keeps the site connected.
All three are managed through the UniFi gateway with automatic failover. The site traffic prefers the primary fiber, falls to the secondary if the primary fails, and rolls to Starlink if both fiber paths are down.
Chandler, AZ: taking everything further
Ashland proved the model. Chandler is where we refined it.
With the lessons of Ashland's design and deployment behind us, we went into Chandler with a mandate to eliminate every remaining single point of failure we could identify: in the fiber runs, in the power infrastructure, and in the WAN. Here's what that looked like in practice.
A web-style optical distribution framework
The fiber backbone at Chandler uses what we're calling a web-style ODF (Optical Distribution Framework), a topology that gives us redundant physical paths between every part of the network.
In a traditional star topology, each IDF (Intermediate Distribution Frame, essentially a local network closet at different points in the building) has a home run back to the MDF (Main Distribution Frame, the central network hub). That's clean and simple, but it means an IDF is entirely dependent on its single fiber run back to the MDF. Cut that run, and that IDF is an island.
At Chandler, each IDF still has its home run back to the MDF, but each IDF also connects to at least one neighbouring IDF. That creates a web of interconnections rather than a pure hub-and-spoke layout. If any single fiber segment fails, traffic can reroute through an adjacent IDF to maintain connectivity. The physical layer itself becomes fault tolerant.
This is the kind of design you see in data centres and large hospital networks, where physical path redundancy isn't optional. We brought it to our warehouse.
Power: redundancy at every layer
Network gear failing because of a power issue is, frankly, embarrassing. It's also entirely preventable. At Chandler, we designed power redundancy in from the start at multiple levels:
- Dual power feeds from separate circuits: each IDF and the MDF receive power from two independent circuits on different electrical panels. If one circuit trips or a panel has an issue, the other feed keeps the equipment running.
- Independent UPS units at each IDF and MDF: not a central UPS feeding everything, but dedicated battery backup at each network location. This means a UPS failure in one location doesn't affect the others, and runtime calculations are simpler and more predictable.
- An on-site generator: for extended power outages, a generator ensures that all critical network and security infrastructure stays online. The UPS units bridge the gap during generator startup.
Every piece of active network gear in Chandler has a path to power that doesn't share a single point of failure with any other path. That's the design goal, and that's what we built.
10Gbps uplinks with 1Gbps fallback
The access points at Chandler are connected via 10Gbps primary uplinks, with a 1Gbps secondary backup connection routed through a separate physical path. The failover is handled at the switch level: if the primary 10Gbps path goes down, the AP automatically falls over to the 1Gbps backup without manual intervention.
With the increasing density of wireless clients and the higher throughput demands of modern WiFi standards, 10Gbps uplinks are quickly becoming the sensible baseline for high-density enterprise deployments. Chandler won't be bandwidth-constrained anytime soon.
Dual power supplies on IDF switches
The switching hardware in Chandler's IDFs has dual power supplies, meaning two independent PSUs per switch, fed from the two separate circuits mentioned above. A PSU failure or a circuit issue takes down one power path, not the switch. This is standard practice in data centre environments and, increasingly, the right call for any infrastructure where uptime is non-negotiable.
WAN: the four-horsemen edition
Chandler replicates the Ashland WAN model of dual fiber ISPs with separate last-mile terminations, plus Starlink, and adds one more layer on top of that.
We're deploying a Ubiquiti UniFi 5G cellular device as a fourth WAN path. Its primary purpose is out-of-band management: a dedicated path for IT to access the network infrastructure even if all other WAN links are down, without competing with production traffic. But it also serves as an ultimate last-resort uplink if, in some extraordinary sequence of events, both fiber ISPs and Starlink are simultaneously unavailable.
We'll be honest: if all four WAN paths fail at the same time, we have bigger problems than we can solve with a cellular backup. But the 5G device costs very little relative to the peace of mind it provides, and having a reliable OOB path has practical value every single day, not just during disasters.
What the hospital comparison actually means
We've used the term "hospital-grade" a few times, and it's worth being precise about what we mean by it, because it's not just marketing language.
Hospital networks are designed around the principle that the cost of downtime is measured in human outcomes, not just productivity metrics. That framing shapes every decision: redundant physical paths, redundant power, redundant WAN, segmented traffic for critical devices, and rigorous pre-deployment validation using planning tools rather than intuition.
Our warehouses aren't hospitals. But the cost of our downtime is real: robots that stop picking, orders that stop flowing, and a supply chain that serves healthcare practitioners and their patients. Applying the same design discipline feels appropriate.
What's next
Chandler is in active deployment as of this writing. We'll follow up with a post-deployment retrospective once the site is fully operational, including how the failover scenarios actually perform in practice, not just in theory.
For any other engineering teams thinking about warehouse or operations infrastructure: the investment in redundancy pays itself back the first time something fails and no one notices.
