Features

Everything between the tray icon and the tunnel

Start with the short version if you decide budgets — or jump to the technical deep dive if you run the infrastructure.

For decision makers

The short version — no jargon

Six things Valenius means for your organisation, before we get technical.

🏠

Your data stays in your house

Valenius runs on your own servers. VPN keys, employee device data, and logs never leave your company — there is no vendor cloud they could leak from, and no third party to trust.

🏛️

An EU company, built for GDPR

Stranto Business Solutions GmbH is based in the EU. No US CLOUD Act exposure, no overseas data transfers to explain to your data protection officer. GDPR compliance comes from the architecture itself — whether you self-host or use our EU managed cloud.

🔑

Employees without admin rights

Your staff connect to the VPN with one click on their laptop, or a tap in the mobile app — without holding administrator rights on their machines. Fewer privileges means fewer security incidents and fewer support tickets.

📖

Open source you can verify

The core platform is published under the AGPLv3 license. Your security team — or anyone else — can read exactly what the software does. No black box, no hidden phone-home.

💶

Costs you actually control

The Community edition is free with no device limit and no trial clock. You pay only if you want automation (Pro) or want us to host it for you — and you can stop any time without losing your setup.

🔌

Works with what you have

Already running a WireGuard® VPN? Valenius manages it from day one — no rip-and-replace, no migration project. Your existing server, firewall, or VM keeps doing its job.

For engineers

The long version — every detail

How Valenius actually works: the client architecture, the management plane, and the Pro automation layer.

Client experience

One-click connect — without elevation

A privileged system service owns the WireGuard® tunnel; users talk to it through a tray app over a local IPC channel that authenticates the calling user. No UAC prompts, no sudo, no shared admin password — and per-user profile separation built in.

After the tunnel comes up, Valenius probes your server through the tunnel and only flips to a green checkmark once the probe succeeds — so “connected” means verified end-to-end, not just “interface up”.

  • Per-user profiles — users see and manage only their own
  • Admin-pushed profiles are protected from deletion; user-uploaded ones are not
  • Auto-connect on unknown networks, with a trusted-network exclusion list
  • Verified-connectivity indicator (in-tunnel health probe)
  • Simultaneous multi-VPN on desktop — run your company VPN and a customer VPN at once, with automatic conflict detection
🖱️
Under the hood
  • Windows: system service + tray app · x64 & ARM64
  • Linux: systemd root daemon + GTK3 tray · .deb package
  • macOS: background daemon + menu bar app · Apple Silicon & Intel
  • IPC: named pipe / Unix socket, caller identity verified by the OS
  • Verification: HTTPS probe through the tunnel, retried up to 30 s
Client experience

The same one-tap experience, now in your pocket

The Android and iOS apps share one codebase, so they get the same connect/disconnect flow and the same verified-connection checkmark as the desktop clients — the app keeps showing your VPN profiles even through a brief connectivity blip, instead of flashing an error.

New devices are activated by scanning a QR code — no typing configs on a phone keyboard.

  • QR code pairing to activate and bind a new device in one step
  • TOTP and push-to-approve MFA built into the app (Pro)
  • Config encryption at rest via the platform keystore (Android Keystore / iOS Keychain)
  • One active VPN profile at a time — an OS-level limit on both Android and iOS, not a Valenius restriction; the app still shows and manages your full profile list
📱
Under the hood
  • Android: Flutter app · Android Keystore-backed encryption
  • iOS: same Flutter codebase & feature set as Android
  • Pairing: QR scan → device bound to a customer, no manual approval round-trip
  • Reconnect: profile list stays visible through brief connectivity blips (e.g. right after unlocking the phone)
Central management

An admin panel that sees your whole fleet

Every client maintains a heartbeat plus a long-poll channel to your backend. A device shows online seconds after the user opens the tray app — and offline the moment they quit it, because the client actively signs off instead of waiting for a timeout.

  • Live online/offline presence and version per device
  • Push WireGuard® configs remotely — staged centrally, claimed by the device on its next poll
  • Per-device settings: heartbeat interval, auto-connect profile, trusted networks
  • Activate, deactivate, and remotely delete profiles centrally
  • Audit log of every connect, config push, and admin action
  • Self-service config delivery: QR codes for mobile, printable config cards, and email
  • Trigger a client to connect remotely — no user interaction required
  • Encrypted one-click backup & restore of the entire deployment
  • Server-side liveness detection & Kill Tunnel (Pro) — ping-confirmed status, and a forced disconnect that works even if the client is unreachable
  • Per-client connection history — connect/disconnect events with LAN/WAN IP
  • Per-client traffic statistics (Pro) — auto-refreshing dashboards per device, per customer, and fleet-wide, with configurable data retention
  • Redacted diagnostic log collection — request logs from a device centrally, or let the user send them; API keys, VPN keys, and secrets are stripped on the device before upload
Valenius admin panel Overview page: client counts, presence, and a fleet-wide traffic dashboard

The actual admin panel — live fleet overview

Under the hood
  • Presence: periodic heartbeat + long-poll · offline sign-off on exit
  • Config push: staged server-side, claimed atomically by the device
  • Sign-in: OIDC against your identity provider + TOTP 2FA
  • Identity: persistent device GUID; new installs need admin activation
  • Delivery: QR / printable card / SMTP email · encrypted JSON backup & restore
  • Liveness (Pro): backend-side ping against the WireGuard® server, independent of client self-reporting
  • Traffic (Pro): per-peer byte counters sampled server-side · charts auto-refresh every 60 s
  • Diagnostics: fixed per-platform allowlist · redaction runs on the device, never on the server
Pro

Zero-touch peer provisioning

A lightweight sidecar runs next to your WireGuard® interface and gives the backend a management API. Approve a device in the panel — it gets a key pair, an IP from the interface subnet, and a complete config, without anyone touching a .conf file.

Setup is one enrollment token: the sidecar generates its own private key, sends a signing request to your backend, and receives its certificate automatically. The token is one-time and consumed on use.

  • Automatic key generation, preshared keys, and IP allocation
  • Peers reconciled on startup — server reboots never lose configuration
  • Multiple isolated customers on one host (one interface + port each)
  • Removing a device in the panel removes the peer on the server
  • Opt-in cross-customer profile sharing — a device can also carry a second customer’s VPN profile, useful for MSPs on shared infrastructure
Under the hood
  • Sidecar: single static Go binary, stdlib only, Docker Compose deploy
  • Enrollment: one-time token → CSR → cert signed by the internal CA
  • IP allocation: automatic from the interface subnet (CIDR)
  • Interface: lives in the host network namespace — survives container restarts
Pro

One-click proof that a server is actually reachable

Before you tell a customer their VPN is live, the admin panel can verify it for you. “Check ports” tests every inbound port the WireGuard® host needs — the UDP ports are confirmed with a real WireGuard® handshake, not a ping, so a pass proves the port is reachable, the server’s key matches, and peer provisioning actually works.

“Run test” goes further and has the server inspect itself: IP forwarding, NAT, firewall forwarding rules, upstream routing, and configuration drift. That catches the single most confusing VPN failure — a tunnel that connects, shows as connected, and carries no traffic at all. Nothing observed from outside the server can detect that.

  • Check ports — per-port pass/fail, with UDP ports confirmed by a real WireGuard® handshake
  • Run test — the server inspects its own IP forwarding, NAT, firewall rules, routing, and configuration drift
  • Catches the “connected but no traffic” failure mode, invisible from outside the server
  • The panel names each required port and exactly who must reach it — including a warning that the management port isn’t meant to be public, with the backend’s own IP shown for a single-address firewall rule
🩺
Under the hood
  • Check ports: real WireGuard® handshake per UDP port, not a synthetic probe
  • Run test: self-inspection of IP forwarding, NAT, firewall forwarding rules, routing, and drift
  • Requires: backend 1.11.x + sidecar 1.11.24
  • Availability: Pro
Pro

A fallback port that keeps your team connected — even on networks that block VPNs

Every Pro-managed WireGuard® server can also answer on UDP 443 — the port that hotel Wi-Fi, guest networks, and locked-down corporate firewalls almost always leave open, because it’s where HTTPS lives. Both ports stay live at once, with a per-customer toggle in the admin panel, and clients retry automatically on the fallback port the moment a connection attempt is blocked — no manual profile edit, no support ticket.

It’s a resilience layer most WireGuard®-based competitors simply don’t offer, because it takes a real management plane on the server side to run two ports safely and hand a client the right one automatically. For your users, a restrictive network stops being a reason to call IT.

  • Server listens on the primary port and UDP 443 simultaneously — toggle it per customer from the admin panel
  • Automatic client-side retry on the fallback port after a blocked connection attempt — no manual reconfiguration
  • Solves the single most common “the VPN doesn’t work from this hotel/office” support call
  • A resilience feature most WireGuard®-based competitors don’t have — it takes a management plane on the server, not just the protocol
🔀
Under the hood
  • Ports: primary port + UDP 443, both live, toggled per customer
  • Client retry: triggered from the existing post-connect verification loop (~20 s without a handshake)
  • Scope: UDP 443 specifically — helps where networks filter by port number, not where all UDP is blocked or the protocol is fingerprinted
  • Requires: sidecar 1.11.24 (server) + current Valenius client
Security

A management plane that assumes hostility

Every call between your backend and your WireGuard® servers is mutually authenticated TLS: the backend runs its own internal certificate authority, and a server without a valid client certificate gets nothing but a health endpoint.

On end-user machines, configs are locked to the system account and encrypted at rest on every platform — in both editions. Standard users can connect, but can never read a private key; even direct disk access doesn’t expose one.

Pro can also gate the tunnel itself: server-enforced multi-factor authentication means a user’s VPN session only carries traffic after a verified second factor — a direct building block for NIS2-style access controls.

MFA is per-group, not all-or-nothing — stronger checks for admins, lighter for everyday staff. Instead of typing a code, users can approve a connection with a tap and Face ID/fingerprint on a second device. And it’s scoped to user access only: machine-to-machine and site-to-site connections are never interrupted.

  • Internal CA, mutual TLS on every management call
  • Config encryption at rest on every client — included in both editions
  • System-only file permissions on every client config
  • OIDC + TOTP for the admin panel, audit log for accountability
  • AGPLv3 open-source core — audit it yourself
  • Server-enforced MFA for VPN access — verified second factor before the tunnel carries traffic (Pro)
  • Push-to-approve from a second device, as an alternative to typing a TOTP code
  • Fail-safe enforcement — if the MFA component is out of date or unreachable, gated peers stay blocked rather than let through
  • Fleet-wide remote API-key rotation — roll the client credential across every device from the panel, without reinstalling anything
🛡️
Under the hood
  • mTLS: internal ECDSA P-256 CA, client certs verified per request and pinned to the backend’s identity
  • At rest: OS-level encryption of stored configs — both editions, every platform
  • File ACLs: SYSTEM-only on Windows, root-only (0600) on Linux
  • Audit: connects, config pushes, and admin actions recorded
  • MFA gating: CA-signed session grants with an absolute expiry, enforced on the VPN server’s own clock (Pro)
  • Enrollment: scan-a-QR TOTP setup, available in the Windows tray, Linux tray, and mobile app
Operations

A fleet that updates itself

Clients check your backend — not a vendor server — for updates and install them automatically within the hour. Need it now? “Force update” in the panel triggers an immediate one-shot rollout on the next heartbeat. Every download is checksum-verified before a single byte is installed.

Pro appliances go further: the update agent starts the new version next to the running one, health-checks it repeatedly, swaps production only on success, and keeps watching afterwards — rolling back automatically if the new version misbehaves.

  • Automatic client updates served from your own backend
  • One-click forced rollout per device
  • SHA-256 verification before anything is written
  • Zero-downtime appliance updates with watchdog + auto-rollback (Pro)
  • Per-customer installer packages — backend URL & API key pre-baked, silent/MDM-ready
  • Staged rollout rings (Pro) — test a new appliance version on a subset of your fleet before going fleet-wide
  • Stable & beta release channels per OS — put pilot devices on beta, then promote beta to stable with one click
🔁
Under the hood
  • Clients: hourly update check + admin-triggered force update
  • Integrity: SHA-256 digest verified before install
  • Appliance: candidate container health-checked before the swap
  • Safety net: watchdog window with automatic rollback + volume backup
  • Deployment: pre-configured installer ZIP · silent install via /BACKENDURL= & /APIKEY=
  • Signing: Windows installers code-signed via Azure Trusted Signing
Automation & AI

Every admin action, available to your own tooling — and to an AI assistant

Anything an administrator can do in the panel, Pro can also do over a scoped REST API: create and edit clients and customers, provision peers, connect or force-disconnect a device, set MFA policy, mint QR pairing codes, pull traffic and audit data. The OpenAPI 3.1 specification is served openly from your own backend, so Visual Studio, Postman, n8n or an RMM can import it from the URL and generate a typed client — no token needed just to read the spec.

The same surface is also exposed as an MCP server — the protocol Claude, Gemini, OpenAI and Mistral use to call external tools. Point an assistant at your backend and ask it in plain language: “which clients haven’t checked in this week?”, “kill the tunnel on that stolen laptop”, “onboard a new customer called Acme”. Underneath, every request is an ordinary API call — same token, same permissions, same audit entry.

Access is yours to shape. A token carries only the scopes you tick, so a triage assistant can be allowed to look at the fleet without being able to change a single thing; adding the right to act is a deliberate, separate decision. Bind a token to one customer and it can never see the others. Revocation is immediate, and every action is recorded under that token’s name in the audit log.

  • Full REST API over the whole admin surface (Pro) — 50+ endpoints
  • Built-in MCP server — connect Claude, Gemini, OpenAI or Mistral directly
  • Publicly readable OpenAPI 3.1 spec — import it into Visual Studio, Postman or any generator
  • Per-token scopes — read-only assistants are a first-class option, not a workaround
  • Optional per-customer token binding — an MSP can hand a tenant a token that only ever sees their own fleet
  • Every call audit-logged and instantly revocable
  • Works with n8n and other workflow tools — as an MCP tool or a plain HTTP request
🤖
Under the hood
  • REST: bearer-token auth, RFC 9457 problem details, per-token rate limiting
  • Spec: OpenAPI 3.1, generated from the running server so it never drifts
  • MCP: Streamable HTTP transport, 50+ tools, one per API operation
  • Scopes: read and write granted separately per resource family
  • Private keys: behind their own scope — never handed to an assistant by default

See it on your own infrastructure

The Community edition is free, self-hosted, and has every feature you just read about except the Pro automation.