How a Hopbox Goes from Box to Live Branch in 10 Minutes
The problem every multi-site enterprise knows
Section titled “The problem every multi-site enterprise knows”You sign a lease on a new location. You need it connected to your network. What follows is a familiar sequence: raise a ticket with the ISP, wait for the circuit, send an engineer, configure the router, set up VPN tunnels, add firewall rules, plug into the monitoring stack, test, troubleshoot, test again. Two to four weeks if everything goes right. Longer if it does not.
Multiply that across 50, 200, or 580 sites and you have a full-time job that never ends. Every new store, warehouse, branch office, or collection centre is the same process from scratch. The same delays. The same coordination overhead.
This is the problem Hopbox was built to solve.
What zero-touch provisioning actually means
Section titled “What zero-touch provisioning actually means”Zero-touch provisioning (ZTP) is not a marketing term at Hopbox. It is a literal description of what happens. Nobody touches the device configuration at the branch. Nobody needs to.
Here is how it works.
Every Hopbox appliance ships from the warehouse pre-loaded with firmware. The device has a unique identity baked in. Its configuration lives on the Hopbox Controller, waiting for the device to come online and pull it.
The person at the branch site does one thing: plug it in.
Spoke templates: configure once, deploy everywhere
Section titled “Spoke templates: configure once, deploy everywhere”Before any device ships, the network team builds a spoke template in the Hopbox Controller. A spoke template defines everything a certain type of site needs: VPN tunnel peers, firewall rules, mwan3 failover policy, content filtering profile, DNS protection settings, monitoring parameters, and application-aware routing rules.
You create one template per vertical or site type. A retail store template. A warehouse template. An NBFC branch template. Each template captures the decisions your network team has already made for that class of site.
When a new site is added to the Controller, you select the template, fill in the site-specific details (location name, WAN addresses if static, VLAN tags if needed), and assign the device serial number. That is the entire provisioning step. One form. No CLI. No config file to hand-edit.
When the device boots at the branch and contacts the Controller, it pulls the full configuration generated from that template. Every retail store gets the same firewall rules, the same content filtering, the same VPN topology, the same monitoring. Consistent. Repeatable. Auditable.
If you need to change something across all retail stores, you update the template. The Controller pushes the updated config to every site using that template. One change, 580 sites updated.
Templates turn branch deployment from a per-site engineering task into a per-vertical design task. You do the thinking once. After that, it is just shipping.
The default path: DHCP WAN
Section titled “The default path: DHCP WAN”The most common scenario is the simplest. The branch has a broadband connection with DHCP. The ISP router hands out an IP address automatically. No static IP is needed.
The Hopbox appliance connects its WANA port to the ISP router. It gets a DHCP lease. It reaches the internet. From there, it contacts the Hopbox Controller, authenticates, and pulls its full configuration: VPN peers, firewall rules, mwan3 failover policy, Charcoal content filtering rules, DNS protection settings, syslog forwarding targets, and monitoring parameters.
No engineer. No CLI. No manual configuration.
The fallback: USB tethered WAN
Section titled “The fallback: USB tethered WAN”Sometimes the broadband line is not ready yet. The ISP is still provisioning. Or the Ethernet cable has not been run to the rack location. But you still need the branch online today.
This is where WANUSB comes in.
Any staff member at the branch can tether a mobile phone via USB. The Hopbox appliance picks up the tethered connection as a WAN interface. It uses this temporary link to reach the Hopbox Controller and pull its configuration.
Once the configuration is applied, the device knows about its permanent WAN interfaces, including any static IP settings that may be needed for the production links. When the broadband line goes live and the Ethernet cable is plugged in, the device fails over to the permanent WAN. The USB tether is no longer needed.
This means there is no chicken-and-egg problem. You do not need the production WAN to be ready before you can provision the device. A phone in someone’s pocket is enough to bootstrap the entire branch.
The static IP case
Section titled “The static IP case”Some branches have ISP circuits that require static IP configuration. ILL links, MPLS circuits, or enterprise broadband plans with fixed addressing. In these cases, the device cannot simply DHCP its way online.
Two options:
First, if the static IP details are known in advance, pre-configure them in the Hopbox Controller before the device ships. The device firmware includes a minimal bootstrap config that handles the initial connection. Once online, it pulls the full config including the static IP WAN settings.
Second, if the static IP details are not available at ship time, use the USB tethered WAN path. Tether a phone, let the device pull its config (which includes the static IP WAN settings), and then plug in the production circuit. The device applies the static IP configuration and brings up the permanent link.
Either way, nobody at the branch needs to know what a static IP is.
What happens in those 10 minutes
Section titled “What happens in those 10 minutes”Here is the timeline from the moment someone plugs in the power cable.
Minute 0 to 1: Boot and WAN negotiation. The appliance powers on, runs its boot sequence, and negotiates a WAN connection. On DHCP, this takes seconds. On USB tether, it takes a little longer while the phone link stabilises.
Minute 1 to 3: Controller handshake and config pull. The device contacts the Hopbox Controller over an encrypted channel. It authenticates using its unique device identity. The Controller pushes the full site configuration: VPN tunnel definitions, failover policies, firewall rules, content filtering rules, DNS settings, and monitoring parameters.
Minute 3 to 5: Tunnel establishment. VPN tunnels come up. OpenVPN, WireGuard, or IPSec, depending on the site configuration. Multi-active tunnels with Forward Error Correction (FEC) start negotiating with the hub. The device builds encrypted connections to the head office and any other sites in its mesh.
Minute 5 to 7: Route convergence and traffic flow. Routes converge. The mwan3 failover engine evaluates all available WAN links and sets policy routing. Traffic starts flowing through the tunnels. UPI terminals, POS systems, ERP clients, and SaaS applications at the branch can now reach the corporate network.
Minute 7 to 10: Monitoring active and first verdicts. The device starts streaming metrics and logs to the Hopbox monitoring stack. WAN health data flows into the analytics engine. Within minutes, the dashboard shows the new site with live ISP identification, latency measurements, packet loss numbers, and the first anomaly verdicts. The branch is not just connected. It is observed.
Why it works on any link
Section titled “Why it works on any link”Hopbox is transport-agnostic. The device does not care what kind of WAN link it sits behind. Broadband, ILL, LTE, MPLS, USB tethered mobile, or WiFi tethered. It supports dual-WAN with automatic failover from the moment it comes online.
No static IP is required at the branch for the default DHCP path. The VPN tunnels work behind CGNAT, behind double-NAT, behind whatever the ISP puts in the way. This matters in India, where ISP infrastructure varies wildly between cities and between providers in the same city.
What you get at scale
Section titled “What you get at scale”This is not theoretical. Hopbox manages the largest single deployment of 580+ retail stores on one SD-WAN network. Every one of those stores was provisioned with zero-touch. Every one runs dual broadband plus LTE backup. Every one streams metrics to a central dashboard.
When a new store opens, the device ships from the warehouse. Someone at the store plugs it in. Ten minutes later, UPI payments are flowing, the POS is connected, and the NOC can see the site on the dashboard.
No engineer visit. No VPN configuration spreadsheet. No firewall rule copy-paste. No “works on my bench but fails in the field” surprises.
The verticals
Section titled “The verticals”The same provisioning model works across every vertical Hopbox serves.
Retail chains. 580+ stores. UPI, cloud POS, loyalty systems. Dual broadband plus LTE backup. FEC on VPN tunnels keeps payment packets flowing even on lossy links.
Pathology and diagnostic labs. Collection centres in tier-2 and tier-3 cities. No IT staff on site. Encrypted connectivity for LIMS and patient records. Plug in, pull config, send reports.
Warehouses. HHT barcode scanners need low-latency, loss-free connectivity. FEC recovers dropped packets without retransmission. Warehouse staff plug the Hopbox in and start scanning.
NBFC and financial services branches. Compliance requires encrypted connectivity. Dual MPLS plus broadband for resilience. Content filtering built in.
Branch offices. SaaS, VoIP, cloud applications. Enterprise-grade connectivity without enterprise-grade complexity.
The bottom line
Section titled “The bottom line”The traditional branch deployment model treats every site as a bespoke engineering project. Hopbox treats it as a shipping problem. Configure once in the Controller. Ship the box. Plug in. Go live.
Ten minutes. No engineer. Any link.
That is what autonomous SD-WAN looks like in practice.
Ready to see it work? Get in touch at sales@hopbox.net or visit hopbox.net.