01
Sign in as yourself.
Connect using your organization’s existing sign-in. Each profile requires the same verified identity that downloaded it.
Private access. A familiar way in.
Go Supi!
Your team. Your tunnel. Your rules.
Open-source SAML single sign-on and access control for OpenVPN Community. Your team signs in with its work identity. You set the rules.
v0.10.0 is here: opt-in Prometheus metrics and the completed move to owner-bound profiles. Start with the deployment guide.
A watchful little companion.
A very Supi state of mind.
A very Supi state of mind.
01 / Work identity
02 / Group access
03 / Session control
The project / 01
Your people. Your resources.
A connection on your terms.
Your team already has a work identity. SupiVPN connects that identity to VPN access: browser-based SAML sign-in, groups and session rules, with OpenVPN Community carrying the traffic.
Built in Go and self-hosted on your infrastructure, SupiVPN gives you control over access decisions. Group IP pools let your network rules distinguish traffic by team.
See how the pieces fit Features / 02
Familiar sign-in.
Thoughtful control.
02
Access by group.
Organize access around your teams, with policies matched to each group.
03
Sessions with boundaries.
Set connection limits and session duration for each group. Keep access on your terms.
Get started / 03
A fresh VM.
Your first tunnel.
Start on Debian 13 with signed packages and systemd. The guide takes you from a clean VM through identity setup to a working VPN, with checks along the way.
Let APT do its part.
Packages for amd64 and arm64 are available from apt.supivpn.com. The supivpn metapackage installs the node, controller and local operator CLI together. You can also choose packages separately. No Go SDK or source checkout needed.
Set up the signed repositoryMake the rules yours.
Connect your identity provider, then choose group priorities, address pools, session lengths and connection limits. The minimal setup is a starting point; the guide links to the full configuration.
Explore your access policyTake the tunnel for a spin.
Review the network rules, start the services, sign in and connect. Check who gets access, who is denied and what happens after a reboot before adding your own private resources.
Run the connection checksStart small. Plan for more.
This is a minimal deployment for evaluation. Production deployment guidance, including active-active HA, and infrastructure as code are planned. The project is still in development.
The architecture / 04
Different tools.
One access model.
Your identity provider knows your people. SupiVPN decides who gets access. The VPN carries the traffic. Clear responsibilities give us room to add more ways to connect the pieces.
Explore the diagram: hover, focus or tap a component. Press Escape or tap outside to close its details.
01 / Access decisions
Identity provider
Who is signing in?
Your organization’s identity provider authenticates the person and supplies signed group membership. SupiVPN verifies that response before using it for access decisions.
Today: standard SAML IdPs. Okta is the documented setup example; each deployment still needs interoperability checks.
Your organization’s sign-in and group membership.
Standard SAML IdPs todayVia browser
SupiVPN controller
Turn identity into an access decision.
The controller verifies sign-in, evaluates group and session rules, and creates a decision for the matching connection. It also handles profile downloads. It does not carry VPN traffic.
Today: SAML. Additional authentication protocols are planned and still require implementation and security testing.
- Authentication integration
- SAML today
- Access policy
- Groups, sessions & profiles
State
State backend
Remember the state that matters.
Shared storage coordinates pending logins, one-time decisions, replay protection and session state across controller instances. Its consistency guarantees are part of the authorization model.
Today: PostgreSQL. Other shared storage backends are planned. IP leases remain local to each Go agent.
Shared login, decision, replay and session state.
PostgreSQL todayController Go agent
Access decisions via agent API
02 / VPN traffic
VPN client
The team’s way in.
A person uses an existing VPN client and follows the browser sign-in flow. After access is approved, the client’s tunnel carries traffic to the VPN node.
Today: OpenVPN Connect and OpenVPN 3 Linux with browser authentication. Linux imports a downloaded .ovpn file after SAML sign-in.
Your team’s way into the network.
OpenVPN client todayTunnel
VPN node
Apply the rules. Carry the packets.
One Go agent applies access decisions and assigns IPs from shared local group pools. Unmodified OpenVPN handles the tunnels: UDP by default, with a second process when TCP fallback is enabled.
Both transports use the same profile ownership checks, access policy and address pool on the node.
- Go agent
- Applies decisions & assigns IPs
- VPN transport
- OpenVPN carries the traffic
Traffic
Your resources
Where the connection takes you.
Private services and networks sit beyond the VPN node. Group IP pools let deployment-level network rules distinguish traffic by group.
Routes, firewalls, DNS and any Internet egress are configured by the deployment. The controller and database do not relay these packets.
The services and networks your team needs to reach.
Your routing & network rulesBring your SAML IdP.
Okta is a setup example, not a requirement. Standard SAML IdPs can supply the verified identity and groups that SupiVPN uses.
More ways to sign in.
Additional authentication protocols around the same access-policy model. SAML is the current implementation.
More storage choices.
Additional state backends with the same consistency guarantees. PostgreSQL is the shared store available today.
New protocols and storage backends still need implementation and testing. They are not configuration options yet.
Explore the technical architecture Working together / 05
Works with OpenVPN®.
SupiVPN works alongside unmodified OpenVPN® Community software. SupiVPN handles sign-in and access policies, while OpenVPN® provides the VPN transport.
Use OpenVPN® Connect , downloaded separately from its official website, or OpenVPN 3 Linux. See the client import guide for each workflow and its validation limits.
SupiVPN is currently in development. Build with us / 06
Early days.
Room for your ideas.
SupiVPN is built in the open by Stanislav Kazachkov (@enotf). The code, architecture, Debian packages and deployment guide are public. Try the minimal setup, share a use case or help improve what comes next.
Follow the build.
See what changed in each release. On GitHub, choose Watch → Custom → Releases to hear when the next one lands.
Browse releasesBring your use case.
Which identity provider does your team use? What makes VPN access awkward today? Share the workflow you would like SupiVPN to support.
Share an idea on GitHubMake a small difference.
Clearer docs, a focused test or a code fix all help. Local unit tests need no cloud account or real identity provider; docs can be edited directly.
Find your way in A few good questions / 07
Before you dive in.
Who is SupiVPN for?
Teams exploring self-hosted access to private networks and services using their existing work identity. SupiVPN brings SAML sign-in, group policies and session controls to OpenVPN Community. You operate the infrastructure and configure its routing and firewall rules.
How does sign-in work?
The VPN client opens your browser. You confirm that you started this connection, then sign in with your identity provider. SupiVPN verifies the SAML response and evaluates group and session policy. Its Go agent applies the decision on the VPN node; OpenVPN carries the tunnel traffic. Since v0.7.0, confirmation is on by default. Only approve a connection you started.
How do I get my VPN profile?
Sign in with your organization first. With Server URL enabled in v0.8.0, OpenVPN Connect opens the browser for SAML sign-in, then imports through a one-use link. On Linux, sign in on the website, download the .ovpn file and import it into OpenVPN 3 Linux. Your IdP password stays out of the VPN client. Read the import guide and tested client coverage.
Is every profile tied to its owner?
Yes. v0.10.0 requires an active profile and its verified SAML owner. This binds an account, not a physical device; Device ID is diagnostic information. Existing bound UDP-only and UDP/TCP profiles remain valid, and schema 12 is unchanged.
The v0.8/v0.9 migration window has ended. Replace unbound profiles on v0.9.1 or a later v0.9.x patch before upgrading. Drain and stop legacy listeners, remove their configuration and update server components together. Updating Lambda alone does not disconnect an existing tunnel. Follow the migration guide.
Can I use TCP when UDP is blocked?
Yes, from v0.9.0. UDP remains the default; operators can enable TCP/443 as a backup in the same profile. Both transports share one agent and the node’s address pool, without reserving half for TCP. TCP is off by default. See the transport setup and tested client coverage.
Switching creates a new tunnel and requires SAML authorization again. If an established UDP tunnel silently loses connectivity, the old slot must first be released; recovery can take roughly two minutes plus sign-in and network time. Existing connections are interrupted. Initial fallback from an unavailable UDP endpoint is a separate, faster case.
How do I block a profile or inspect sessions?
The local operator CLI can inspect services, list profiles with their recorded owner, block profiles and request session termination. It requires root on a combined Debian node/controller host; the database may be external. Blocking prevents new admission and does not disconnect established tunnels or ban an account. Lambda uses the separate temporary administration procedure.
Can I monitor it with Prometheus?
Yes, from v0.10.0. See sessions, address pools and controller availability without adding a sidecar. Metrics are off by default and enabled in configuration. VM components use a separate TLS port; public Lambda requires a dedicated Bearer token from Secrets Manager, supported by Prometheus. Keep the VM port reachable only by your monitoring hosts. See the metrics and scrape configuration.
Which identity providers and protocols are supported?
SAML is the authentication protocol implemented today, with Okta as the documented setup example. Other SAML providers need interoperability checks against the IdP requirements. Additional authentication protocols and storage backends are planned; PostgreSQL is the current shared store.
Can SAML assertions be encrypted?
Yes, from v0.7.0. RSA-OAEP and AES-GCM encryption is off by default. You can accept both signed plaintext and encrypted assertions while switching over, then require encryption. HTTPS and signature checks still apply. See the encryption guide.
Can I use it in production today?
The Debian deployment guide covers a minimal setup for evaluation. Production deployment guidance, active-active HA deployment instructions and infrastructure as code are planned. Review the current limitations and security model before choosing it for a deployment.
Can the database live on another host?
Yes. The controller can use an external PostgreSQL server with verified TLS and separate runtime and migration identities. The setup helper supports this from v0.6.1; v0.6.0 requires manual setup. Follow the external database guide for the requirements and migration steps.
What happens if a VPN node fails?
Existing tunnels do not move between nodes. A client connecting to another node must sign in again and receives a different VPN IP; existing TCP and SSH sessions are lost. Active-active nodes provide another place to connect, not seamless session failover. See the failure behavior.
Is SupiVPN open source? How can I help?
Yes. SupiVPN is licensed under AGPL-3.0-only. You can read the code, contribute improvements, share your use case or support development. Sponsorship is voluntary and includes no services, priority support or exclusive features.
Keep it open / 08
Good code needs
a keepalive.
Help sustain the open-source work behind SupiVPN: maintenance, security testing and documentation.
One-time or monthly. Your choice.
Support is voluntary and includes no services, priority support or exclusive features.
Good connections start with a hello