Straight answers about how AppTunnel works, what it costs, and what you're getting.
The AppTunnel server runs on your own infrastructure — a Windows Server, Linux VM, cloud instance, or any host you control. You deploy it, you own it entirely. AppTunnel.io never has access to your server, your network, or anything running inside your environment.
By default the server is a single self-contained binary with an embedded SQLite database — no external dependencies, nothing to provision. Enterprise deployments can switch to a PostgreSQL or MySQL backend for higher write throughput and multi-node clustering.
Nothing in your environment. AppTunnel.io has no access to your server, your users, your applications, your databases, or any data transmitted through your tunnels.
The only connection from your server to AppTunnel.io is a daily license validation request. That request contains your license key, the software version you're running, and aggregate usage counts (number of configured users, tenants, and tunnels). No personally identifiable information about your end users is included. No tunnel content is ever transmitted. Ever.
The server is a single statically-linked binary with no runtime dependencies. It runs on Windows Server or Linux. Compute and memory requirements are modest — typical small deployments run comfortably on a 2-core/4 GB host. Storage requirements depend on how many application files you're hosting.
The server needs outbound HTTPS to reach the license endpoint once per day. Inbound, it listens on two configurable ports: the admin web UI (default HTTPS :8443) and the WebSocket endpoint used by tray clients (default :8765). No other inbound ports are required.
Offline license options are available on the Enterprise plan. Contact us to discuss your specific requirements — we can accommodate environments that cannot maintain outbound internet connectivity.
For all other plans, the server requires a daily outbound HTTPS connection to the license endpoint. If the connection fails, there is a built-in grace period before any operational impact occurs, so brief network interruptions won't affect your users.
Yes, on the Enterprise plan. AppTunnel supports horizontal clustering — multiple server nodes sharing a PostgreSQL or MySQL backend, fronted by a load balancer of your choice. Tray clients reconnect automatically to any available node, so a single node going down doesn't interrupt your users or drop their tunnels.
For smaller deployments the default SQLite backend is a single-file database with no external dependencies — simple to operate, back up, and migrate. When you need HA or higher write throughput, switching to PostgreSQL or MySQL is a configuration change, not an architectural rebuild.
Tray clients will lose their tunnel connections when the server is unreachable, but they reconnect automatically once the server comes back online — no user intervention required. The tray client continuously monitors connectivity and re-establishes tunnels transparently in the background.
Applications that were already running at the time of a server outage will continue running — the app itself is already on the user's machine. Only new app launches and live tunnel connections are affected while the server is down.
AppTunnel uses a capacity-based license — not a named-user license. Each plan defines limits across multiple dimensions simultaneously: tenants, environments, applications, application versions, connected users, tunnels, and file stores. You purchase a block of capacity and distribute it however your deployment requires.
That capacity can be spread across as many AppTunnel server installations as you need. Running a production server plus a DR instance, or deploying regionally across multiple sites, all fall under the same license as long as combined usage stays within your plan's limits.
One connected tray client on one machine equals one user seat — counted by active connection, not by named account. If the same credentials are used to run the tray on three machines simultaneously, that counts as three seats.
This is intentional. A named-user model would let a single account be installed on any number of machines. Seat-based counting means each physical deployment consumes a seat, which accurately reflects actual usage and keeps the license meaningful.
When any capacity dimension reaches its limit — connected users, tenants, applications, or any other metric — AppTunnel enters a restricted mode for that dimension. The admin UI flags the violation and blocks creation of new resources beyond the limit. Everything already running continues without interruption; you're only prevented from adding more of that specific resource until you upgrade.
We don't cut off active sessions. The goal is to give you a natural upgrade moment, not disrupt a running deployment.
Yes. You can upgrade your plan at any time through the customer portal. Upgrades take effect immediately — your new license key is issued and validated on the next license check cycle.
Downgrades take effect at the end of your current billing period. If your current usage exceeds the limits of a lower tier, restricted mode will apply when the new license becomes active.
There's no self-serve free trial — AppTunnel is a self-hosted infrastructure product and a meaningful evaluation requires deploying it against your actual environment. But we do offer time-limited trial licenses tailored to your organization after a brief sales conversation.
The process: reach out, we'll talk through your use case and confirm fit, then issue a trial license scoped to your deployment so you can evaluate against your real applications and infrastructure. Use the contact form or email hello@apptunnel.io to get started.
Yes. Annual billing is available at a discount equivalent to roughly two months free compared to paying monthly. The discount is applied automatically when you select annual billing at checkout.
Credit and debit cards are accepted for all plans via Square. Enterprise customers can also pay by purchase order or wire transfer — contact us to arrange. We do not store payment card data on our servers; all payment processing is handled by Square.
Any TCP or UDP protocol. AppTunnel tunnels raw connections — it doesn't inspect or interpret the application protocol at all. SQL Server (TDS), PostgreSQL, MySQL, ODBC, proprietary database protocols, internal APIs, legacy socket-based services — if your application can connect to it, AppTunnel can tunnel it.
You configure each tunnel as a local port on the user's machine that maps to a remote host and port on your server-side network. The application connects to localhost:PORT exactly as it always has — completely unaware it's talking through an encrypted tunnel.
All tunnel traffic travels over an encrypted WebSocket connection (TLS) between the tray client and your AppTunnel server. The connection is established when the user logs in and stays active. No unencrypted data crosses the network.
The server supports TLS with either a self-signed certificate or your own certificate. For production deployments, you can bring your own certificate or use one issued by your internal CA.
A VPN puts the user's machine on your network — broad access to everything on that network, with all the complexity that entails. AppTunnel is tunnel-per-destination. Each tunnel is a named, explicit connection to a specific host and port. Users get exactly the connectivity they need for their assigned applications and nothing else.
There's also no VPN client to configure, no split-tunneling debates, no conflict with other software, and no IT onboarding ceremony. The tunnels connect automatically when the tray starts. To the user, it's invisible.
Yes. You can configure as many tunnels as your plan allows, each pointing to a different remote host and port with its own local port mapping. A user running two applications that connect to different databases can have two tunnels active simultaneously — one to each database, each on its own local port.
Tunnels are assigned per-user or per-group, so different users in the same tenant can have different tunnel access. You control precisely who can reach what.
Always-on. When the tray client authenticates, it establishes all permitted tunnels in the background automatically. The user doesn't click "connect" or manage tunnel state. By the time they click an app to launch it, the tunnel is already active and the application connects to its database just as it would on the local network.
AppTunnel is purpose-built for legacy Windows desktop applications: Visual Basic 6, Delphi, PowerBuilder, Visual COBOL, PowerBASIC, older .NET WinForms and WPF, and similar applications that have historically resisted remote delivery.
It handles the hard parts of deploying these applications: COM component registration, .NET assembly management, MSI and NSIS and Inno Setup execution, INI and config file placement, and custom PowerShell install scripts. All of this is configured in the admin panel — no changes to the application itself.
When a user launches an application, AppTunnel checks the installed version against the current version in the server. If an update is needed, only the changed files are downloaded — AppTunnel uses content-addressed storage (SHA-256) to track file identity, so unchanged files across versions are never re-transferred. Large shared libraries only download once, even if they're shared across dozens of app versions.
After downloading, AppTunnel runs any configured install actions (COM registration, MSI execution, etc.) automatically, then launches the application. The user experiences this as a brief "checking for updates" moment before launch — no separate update wizard, no reboot prompts.
Yes, through environments. Each tenant can have multiple environments — for example, Development, Staging, and Production. Each environment has its own application version pinning, its own tunnel definitions, and its own set of configuration variables. A new version of your application can run in Staging for internal testing before being promoted to Production, where your live users are.
Users are assigned to environments, so testers see the Staging version while regular users stay on the stable Production version. Promotion is a configuration change in the admin UI — no redeployment of anything.
From the admin panel, you generate a single pre-configured .exe for your tenant. It has your server address and tenant identity already embedded. Send it to users however works for you — email, shared drive, intranet, link in an onboarding document. There's no installer package, no ZIP file to extract, no configuration steps for the user.
The user runs the file, signs in once, and sees their application catalog. The tray also self-updates silently — when a new tray version is available, users get it automatically the next time they run it. All tray updates are cryptographically signed and verified before applying.
Yes. Application and tunnel access is configured per-user within each tenant. A user only sees and can launch the applications you've explicitly assigned to them. Tunnels work the same way — each tunnel is assigned to specific users or groups, and only those users get that tunnel connection when they log in.
AppTunnel has a five-level configuration hierarchy: Server → Tenant → Environment → Application → Version. Variables defined at a higher level are inherited and can be overridden at any lower level. This means you can set a database host at the environment level, override it for a specific app, and inject it into that app's INI or config file at launch time.
This is particularly useful for applications that read connection strings or environment-specific settings from config files — AppTunnel can write those values at launch without you touching the application code.
Per-user secrets — credentials, tokens, personal configuration values — are encrypted with AES-256-GCM using a key derived from the user's own credentials. The secret values are never stored in plaintext anywhere in the system.
Secrets are decrypted only at the moment they're needed, on the user's machine, during application launch. They're injected directly into the process environment or configuration without being written to disk unencrypted.
No. Per-user secrets are encrypted with user-specific keys. An administrator can define what secrets exist and set their values, but once a secret is set, the value is not readable through the admin UI or by any administrative query. This is by design — it means compromising the admin panel doesn't expose stored user credentials.
Every tray release is signed with an Ed25519 private key that never leaves the developer workstation. The corresponding public key is embedded in the tray client at build time. Before applying any update, the tray verifies the cryptographic signature — if it doesn't match, the update is rejected entirely. This means a compromised distribution channel or tampered update file cannot result in a successful install.
Yes. AppTunnel supports OIDC-based SSO with Microsoft Entra ID (Azure AD) and Okta across all surfaces: the server admin portal, per-tenant admin consoles, and the Windows tray client. Users log in with their existing corporate identity — no separate AppTunnel password required.
On the Enterprise plan, SCIM provisioning is also included, so user accounts are created and deactivated automatically as people join or leave your organization. SSO is available on the Professional plan and above; SCIM requires Enterprise.
Yes — SCIM 2.0 provisioning is an Enterprise plan feature. It integrates with Okta and Microsoft Entra ID to automatically manage the full user lifecycle inside AppTunnel: new employees are provisioned the moment they're added to the relevant group in your IdP, and access is revoked instantly when they're removed or offboarded.
This eliminates the manual support ticket loop that plagues SSO-only deployments — IT doesn't need to separately create or deactivate AppTunnel accounts on every hire or departure. Group membership in your IdP maps directly to tenant access and role assignments in AppTunnel.
SCIM provisioning requires the Enterprise plan and active OIDC SSO configuration. Contact us to discuss setup for your environment.
Yes, on all plans. AppTunnel includes built-in TOTP-based MFA for native username/password logins — users enroll an authenticator app (Google Authenticator, Authy, 1Password, etc.) and are prompted for a one-time code on each login. No additional infrastructure or third-party service required.
If you're using OIDC SSO, MFA is enforced by your identity provider (Entra ID or Okta). Configuring MFA policy in your IdP automatically applies it to all AppTunnel logins that flow through that provider.
A tenant is a completely isolated organizational unit within your AppTunnel server — its own users, applications, tunnels, environments, secrets, and file stores. Tenants share the same server infrastructure but are completely separated at the data and API layer. A user in Tenant A has no access to anything in Tenant B, and there's no configuration path that can create that access.
You can use tenants to represent different business units, customer organizations, or deployment environments that need full isolation from each other.
Yes. ISV and MSP deployment is a core use case. Each of your customers runs as an isolated tenant. You configure their applications, their environments, and their users independently. Each customer gets their own pre-configured tray executable. They never see or interact with other customers on the same server.
The Enterprise plan includes white-label options — contact us to discuss branding and packaging requirements for your customer-facing deployment.
File storage is deduplicated globally across tenants using content-addressed storage (SHA-256). If two tenants use the same runtime DLL or shared library, it's stored once on disk. However, tenants cannot see or access each other's files — the deduplication is transparent and doesn't create any cross-tenant access. Each tenant has its own file store view.
This makes large deployments storage-efficient without compromising isolation. Common shared runtimes (VC++ redistributables, .NET runtimes, etc.) only take up disk space once regardless of how many tenants or versions reference them.
Email hello@apptunnel.io for general questions, sales inquiries, or support. For privacy-specific requests, use privacy@apptunnel.io. You can also reach us through the contact form.
We respond within one business day. We're a small, focused team — you'll talk to people who know the product deeply.
Yes. The customer portal has a built-in feature request system. Submit an idea, describe the problem it solves, and our team reviews it. Suggestions that are a good fit for the roadmap are released to a public vote board — visible to all customers — so the broader user base can weigh in.
Vote tallies directly inform what we prioritize. Accepted items are published to an Enhancements In Progress list in the portal so you can track them from suggestion through release. Nothing gets buried in a ticketing system you'll never see again.
Yes. Use the contact form to tell us a bit about your situation, or email hello@apptunnel.io directly. We'll schedule a call to walk through your use case, answer technical questions, and make sure AppTunnel is actually the right fit before you purchase.
We're a small team and we know this product inside out. Send us a message — we respond within one business day.