Running a Business on FOSS: Our Stack and Philosophy
Every piece of software in the Hopbox stack is free and open-source. Not “open-core with proprietary extensions.” Not “source-available with a restrictive license.” Every component, from the operating system on the CPE device to the monitoring stack in the cloud, is FOSS — licensed under GPL, MIT, Apache, BSD, or equivalent.
This isn’t an accident. It’s a deliberate business decision. Here’s the full stack, why we chose it, and what running a business on 100% FOSS actually looks like.
The Full Stack
Section titled “The Full Stack”On the Device (CPE)
Section titled “On the Device (CPE)”| Component | Software | License |
|---|---|---|
| Operating System | OpenWrt (Linux) | GPL-2.0 |
| VPN / Tunneling | OpenVPN | GPL-2.0 |
| DNS (stub) | dnsmasq | GPL-2.0 or GPL-3.0 |
| Firewall | nftables / iptables | GPL-2.0 |
| Routing | mwan3 (multi-WAN manager) | GPL-2.0 |
| Monitoring and logs | bash scripts and syslog | GPL-3.0 |
| Automation Target | Ansible (via SSH + Python) | GPL-3.0 |
In the Cloud
Section titled “In the Cloud”| Component | Software | License |
|---|---|---|
| Monitoring | Prometheus | Apache-2.0 |
| Dashboards | Grease | ? |
| Alerting | Alertmanager | Apache-2.0 |
| DNS (Authoritative and recursive) | BIND9 and PowerDNS | Apache-2.0 and GPL-2.0 |
| Automation | Ansible | GPL-3.0 |
| Reverse Proxy | Nginx | BSD-2-Clause |
| Container Runtime | Docker | Apache-2.0 |
| OS | Debian | DFSG-compatible licenses |
| Database | PostgreSQL and Clickhouse | PostgreSQL License (MIT-like) and Apache-2.0 |
Dashboard / Frontend
Section titled “Dashboard / Frontend”| Component | Software | License |
|---|---|---|
| Framework | SvelteKit | MIT |
| Language | TypeScript | Apache-2.0 |
| CSS | Tailwind CSS | MIT |
| Build Tool | Vite | MIT |
| Package Manager | pnpm | MIT |
| Runtime | Node.js | MIT |
Development and Operations
Section titled “Development and Operations”| Component | Software | License |
|---|---|---|
| Version Control | Git | GPL-2.0 |
| CI/CD | GitLab CI | MIT |
| Container Registry | Docker Registry | Apache-2.0 |
Why FOSS for Networking Infrastructure
Section titled “Why FOSS for Networking Infrastructure”Auditability and Trust
Section titled “Auditability and Trust”Our SD-WAN devices sit inside customer networks. They handle all outbound traffic. They run DNS resolution. They maintain encrypted tunnels. Customers are trusting us with their network traffic.
With proprietary software, that trust is based on faith. With open-source software, it’s based on the ability to verify. Any customer, security auditor, or researcher can:
- Read the OpenWrt source code running on the device
- Verify the OpenVPN implementation is standard, unmodified
- Inspect the Bind9 and PowerDNS configuration and confirm no DNS manipulation
- Audit the monitoring agents to confirm what data is collected
No Vendor Lock-In
Section titled “No Vendor Lock-In”Every component in our stack has alternatives. If PowerDNS or BIND9 doesn’t meet our needs, we can switch to Unbound or Knot. If Prometheus doesn’t scale, we can move to VictoriaMetrics or Thanos. We can evaluate alternatives.
This is not theoretical. In the networking industry, vendor lock-in is the default business model. Proprietary SD-WAN vendors use closed firmware, proprietary protocols, and licensing models that make migration impossible. Customers who commit to a vendor are stuck — even if the vendor raises prices, degrades support, or gets acquired.
Our customers are never locked in. The CPE runs Hopbox OS, a heavily modified OpenWrt. The tunnels use standard OpenVPN. If a customer leaves Hopbox, their device is still a capable router.
Security
Section titled “Security”Open-source software is not inherently more secure than proprietary software. But it benefits from:
- Public vulnerability disclosure. When a vulnerability is found in OpenWrt, OpenVPN, or Prometheus, it’s disclosed publicly, patched quickly, and documented in CVE databases. We can track and respond to every advisory.
- Community review. Critical components like OpenVPN have been formally verified and extensively audited. No proprietary VPN implementation has undergone comparable scrutiny.
- No security through obscurity. We don’t rely on attackers not knowing what software we run. Our security posture assumes the attacker knows the entire stack.
Business Advantages
Section titled “Business Advantages”Cost Structure
Section titled “Cost Structure”The obvious one: no software licensing fees. For a company deploying 1300+ devices, proprietary SD-WAN licensing can easily cost $50-200 per device per year. At our scale, that’s $45,000-$180,000/year in licensing alone — before you count the cloud-side software.
Our software cost is zero. Our costs are hardware, engineering talent, and infrastructure. This means:
- Lower prices for customers
- Higher margins for reinvestment in engineering
- No licensing negotiations, no true-up audits, no compliance overhead
Talent Pool
Section titled “Talent Pool”Engineers who work with FOSS tools bring their skills from previous jobs and take their skills to future jobs. The Ansible playbook patterns, Prometheus query language, Grafana dashboard design, and OpenWrt internals that our team learns here are directly transferable.
This works both ways:
- We can hire engineers who already know our stack (because it’s industry-standard FOSS)
- Engineers are more willing to join because they’re building marketable skills, not learning a proprietary system that only exists at one company
Flexibility and Speed
Section titled “Flexibility and Speed”When we need a feature, we can build it. When we hit a bug, we can fix it. When we need to understand behavior, we can read the source.
Examples from the past year:
- We patched an OpenWrt kernel module to improve mwan3 failover detection time. The patch was submitted upstream.
- We extended the Prometheus SNMP exporter to support additional MIBs specific to our ISP equipment. Contributed back to the project.
- We built a custom PowerDNS Lua script for per-site DNS policy. The PowerDNS documentation and source code made this straightforward.
With proprietary software, each of these would be a feature request ticket, a vendor meeting, a roadmap discussion, and a 6-12 month wait. With FOSS, they were engineering tasks completed in days.
Community Contributions
Section titled “Community Contributions”Using FOSS without giving back is technically permitted by the licenses but ethically hollow. Here’s how we contribute:
GNU Software Mirror
Section titled “GNU Software Mirror”We operate (at the moment of writing, only) public GNU software mirror at mirror.hopbox.net in India. This provides fast, local access to GNU project releases, reducing download times for developers and package managers across the region.
You can read more at https://blog.hopbox.net/blog/hopbox-public-gnu-software-mirror/ and download stats at https://mirrors.hopbox.net/goaccess.html
Upstream Patches
Section titled “Upstream Patches”We have been regularly patches to upstream OpenWrt project and team members maintain packages too.
Documentation
Section titled “Documentation”Part of telling about our operational experience is these blog posts here with FOSS tools. Learnings, configuration examples, and architecture decisions help other teams making similar choices.
Challenges
Section titled “Challenges”Running on 100% FOSS is not without friction:
Support
Section titled “Support”When something breaks at 2 AM, there’s no vendor support hotline. Our options are:
- Read the source code and fix it ourselves
- Search mailing lists, forums, and issue trackers
- Pay for commercial support where available.
In practice, our team’s depth of knowledge with these tools means we resolve most issues faster than a vendor support ticket would. But it requires investing in engineering talent.
Enterprise Sales Perception
Section titled “Enterprise Sales Perception”Some enterprise buyers are uncomfortable with “we run open-source software.” They want a vendor name behind every component. They want an SLA. They want someone to blame.
Our response:
- We provide the SLA. We’re the vendor. The fact that our software is open-source doesn’t reduce our accountability.
- The world’s critical infrastructure runs on FOSS (Linux, BIND9, BGP implementations). Open-source in networking isn’t experimental; it’s the norm.
- Auditability is a feature, not a risk.
This is a sales conversation, not a technical one. But it’s a real challenge, especially in regulated industries.
Integration Gaps
Section titled “Integration Gaps”FOSS tools are excellent individually but sometimes lack the polished integration of an all-in-one proprietary platform.
We mitigate this by investing in automation (Ansible deploys and configures the entire monitoring stack) and treating our infrastructure as code. The upfront configuration cost pays for itself in flexibility.
Keeping Up with Updates
Section titled “Keeping Up with Updates”1300+ devices running OpenWrt means tracking OpenWrt security advisories, kernel CVEs, OpenVPN updates and other patches. There’s no single vendor dashboard that shows “you’re up to date.” We built internal tooling to track component versions across our fleet and flag when updates are available.
Philosophy: FOSS in Critical Infrastructure
Section titled “Philosophy: FOSS in Critical Infrastructure”We believe critical infrastructure — the software that routes your traffic, resolves your DNS, and secures your tunnels — should be open-source. Not because open-source is always better, but because:
- Infrastructure should be inspectable. You should be able to verify what the software running your network actually does.
- Infrastructure should be replaceable. No single vendor should be able to hold your network hostage.
- Infrastructure should be improvable. When you find a problem, you should be able to fix it — not file a ticket and wait.
- Infrastructure knowledge should be shared. Network engineering shouldn’t be gated behind proprietary certifications and vendor-specific training.
This is the same philosophy that gave us Linux, nginx, BIND9, BGP, and the internet itself. We’re applying it to SD-WAN.
Running a business on mostly FOSS is not the easy path. It requires deep engineering talent, comfort with reading source code, and willingness to contribute upstream. But it produces a better product (auditable, flexible, vendor-independent), a better team (skilled in transferable tools), and a better business (no licensing overhead, full control of the stack).
If your stack has proprietary components, ask yourself: what would it take to replace each one with an open-source alternative? You might find the answer is “less than you think.”