We built a VPN Control Center for an agency's own team.
A multi-brand agency asked for self-service over the secure access we run for them: add a user, reset a password, remove a leaver, all from their own team. Here is what we built, and why it is one of the strongest managed-services moves we know.
In this article 4 sections
- A multi-brand agency asked for self-service over the VPN we run for them: add a user, reset a password, remove a leaver, without opening a ticket.
- The ask: build my own people the tooling, so easy a junior operator can run it without breaking anything.
- We templated our internal operator toolkit across their gateways (one source of truth, generated per gateway), then built a VPN Control Center into the customer portal: role-based access, per-user rules, and a discover-and-onboard flow for new gateways.
- End state: their team runs day-to-day secure access from a menu. We own the plumbing underneath.
Routine VPN changes for the agency came to us as requests. Add a user. Reset a password. Remove someone who left. The agency asked for the next step: put those everyday operations in the hands of their own team, so they set their own tempo.
The ask, in short: build the tooling so their own people can run it, simply enough for the most junior operator to use without breaking anything.
Why they asked us, and not a console
Because the thing they wanted self-service over was infrastructure we architected and operate: the gateways, the per-tenant certificate authorities, the credential lifecycle. Anyone else would have had to reverse-engineer the setup first. We could make the abstraction correct on the first try, because we built what it abstracts.
One toolkit, not one per tenant
Multiple tenants, separate gateways, separate certificate authorities, and the tooling had to be identical to operate across all of them so the customer learns one workflow. The clean move was not to hand-write per-tenant scripts, which is multiplied maintenance and guaranteed drift. Treat our own internal operator toolkit as a template and generate each tenant's set from it, substituting the per-gateway constants.
Concretely: five canonical operations (add user, reset password, remove user, list users, rotate credentials), generated per gateway, each script talking only to its own gateway over the OPNsense REST API, with rotatable credentials and everything running locally with no external service in the loop. Then the operator-experience layer the customer actually asked for: a master reference table, a per-gateway how-to, and a login banner that points any operator at exactly the command they need.
=== secure-access operator toolkit ===
add-user | reset-password | remove-user | list-users | rotate-api-credentials
per-gateway how-to: /etc/<gateway>-howto reference: /etc/vpn-operationsCattable from any login. The junior operator's safety net is a banner, not a wiki page nobody opens.
The Control Center in the portal
Then came the "can you also" moment, and the toolkit became a product feature. A VPN Control Center inside the customer portal: a menu module with role-based access control, a gateway selector, a per-user access-rule editor, and an add-a-gateway flow with auto-discovery. Paste a gateway's URL, key, and secret, hit discover, and the module reads the certificate authority and instance off the box and onboards it with no new code.
Routine user changes handled by our team, on request.
Generated operator scripts for every tenant
Their operators self-serve. We maintain one template.
A Control Center in the portal
Role-based access, and new gateways that self-onboard via discovery.
Each step, the customer trusted us with more of the build, not less of it.
The end state
Deployed to production. When a new gateway arrived, it onboarded itself through the discovery flow, with no new code written for it. Their team runs day-to-day secure access from a menu, every future gateway self-onboards, and we own the plumbing while the customer drives.
“We ran the VPN and handed your team the controls, and kept the keys to the engine room.”
Straight answers
Can my own team manage VPN users on managed infrastructure?+
Yes, and it can be engineered properly. In this build the customer's operators got generated tooling and then a portal module with role-based access, over gateways we run.
Does EuroVPS build custom tooling for customers?+
When the engagement calls for it. This one went from operator scripts to a production portal feature.
Can OPNsense be managed through its API?+
Yes. Every operation in this build went through the OPNsense REST API rather than the console, which is our house rule, because scripted operations are repeatable and reviewable.
Who looks after the self-service tooling?+
We do. Self-service moves the routine operations to your team, while the gateways, the certificate authorities, and the module itself remain our responsibility.
Is self-service access management safe for junior staff?+
That was the design brief, verbatim: so easy the most junior operator can run it without breaking anything. The guardrails live in the tooling (one command per task, role-based access in the portal), not in a warning document nobody reads.
Want your team to run its own operations?
Tell us which operations your team wishes it could run itself. If the right answer is tooling, we'll build the controls and keep the plumbing.
Talk to an engineerYou’ve reached the end.
Put the reading to work
What are
you running?
Tell us about the workload, traffic and recovery requirements. Start with the server builder, or talk through the details with an engineer.
Written by the engineers who build and run the infrastructure it describes.Talk to an engineer