BambooVPN
One VPN account across 5 platforms for BambooVPN
One VPN Account, Every Device
We rebuilt BambooVPN from a bare OpenVPN mobile app into a complete multi-platform VPN business in five months. One Node.js backend is the single source of truth for accounts, subscriptions, and servers. Apple, Google, and Stripe billing all reconcile to one account, so users sign up once and their plan follows them to iOS, Android, Windows, macOS, and the browser.
Single codebase
Unified identity
Industry
Consumer Privacy & VPN
Client
Per Markus Akerlund & Jim
Engagement
End-to-end Product Architecture & Cross-Platform Development
Outcome
Five native surfaces sharing one account & subscription
Tech Stack
Next.js, Node, Express, MongoDB, Flutter, WireGuard, Stripe, RevenueCat, Superwall, Adjust
A look inside the live platform — scroll to explore →
Can you take over a half-built app and turn it into a real product?
Yes. BambooVPN came to us in December 2025 as a thin shell. It was one OpenVPN-only mobile app with no user accounts. Purchases were locked to a single device's app-store receipt. There was no web sales channel, no support tooling, and only basic server CRUD for admin.
Over five months we rebuilt it into a full multi-platform VPN business. It now has accounts, web checkout, Windows and macOS apps, a browser extension, a dedicated-IP product line, and a 12+ module admin console.
How does one subscription work across iOS, Android, web, and desktop?
One Node.js backend is the single source of truth for accounts and subscriptions. Apple, Google, and Stripe purchases all reconcile to one account through Superwall and RevenueCat. Every client asks the same backend one question: does this user have access.
So users sign up once and their plan follows them to every device. VPN buyers expect one subscription everywhere. The product started with purchases locked to a single device and no accounts at all.
How do we sell VPN subscriptions outside the app stores?
We built a Next.js user dashboard with a 3-step Stripe checkout and billing management. App stores take a 15-30% commission on every sale. Web checkout avoids that.
Stripe webhooks activate the subscription on the same central account the mobile apps use. A customer who buys on the web can open the phone app and connect right away.
How do you stop payment webhooks from dropping paying customers?
Every billing webhook goes through RabbitMQ with retries, backoff, and dead-letter queues, keyed by idempotent transaction IDs. So a Stripe or Superwall outage delays a paying customer's activation instead of dropping it.
Failed events sit in a dead-letter queue where they can be replayed, not lost. No one pays and then waits on a support ticket to get access.
How does per-user VPN key management work at fleet scale?
Each user gets a unique WireGuard key leased from a pre-generated per-server peer pool stored in MongoDB. The API leases a slot on connect and releases it on disconnect. A cron job sweeps stale leases every 10 minutes.
This runs across a fleet of about 32 servers on 5 hosting providers, with OpenVPN as a fallback. WireGuard runs on port 443 with an MTU of 1280. Adding a new region is as cheap as running one script.
What internal tools does the business get?
A 12+ module admin dashboard: server fleet CRUD, plans, IP pool, analytics, cancellation surveys, a push notification composer, security monitoring, feature flags, and support tickets. Admin events stream in real time over SSE.
The business went from no customer lookup at all to full operational visibility.
How do you handle security and abuse on a public consumer API?
Bot detection auto-bans clients above 100 requests per minute, backed by tiered rate limiting, NoSQL-injection sanitization, and progressive IP bans. Auth uses JWT access tokens with hashed refresh tokens on a 30-day TTL.
A July 2026 internal security audit produced a P0 remediation list, and that remediation is the current engineering priority. We would rather disclose that than pretend the work is done.
The Result
One codebase produces five native surfaces sharing one account and one subscription. Most VPN startups do not get this right until v3.
0 surfaces
Single codebase
iOS, Android, desktop, and browser
0 account
Unified identity
One subscription across all devices
0 friction
Region expansion
New regions added with a single script
0%
Per-user IPs
Dedicated IPs follow the user
How long does a rebuild like this take?
Five months. We took the product over in December 2025 and shipped accounts, three-way billing, a web dashboard, Windows and macOS apps, a Chrome extension, the dedicated-IP line, and the admin console by May 2026.
Some pieces, like the macOS App Store and Chrome Web Store listings, were code-complete and waiting on store review at that point.
Is this a fit for my product if it is not a VPN?
The pattern reuses well beyond VPNs. It fits any multi-platform subscription app, webhook-heavy billing setups, inventory or seat allocation, internal ops consoles, and browser extensions.
If your users buy on one device and expect access everywhere, this is the same problem.