Cloudless Remote User Access
You set up cloudless remote user access by linking user devices to private servers. This approach uses direct peer tunnels and local identity keys instead of third-party clouds. Teams often build these links with self-hosted VPN servers or peer-to-peer mesh networks. Still, once a user joins the network, broad server roles can expose sensitive data. How to build cloudless remote user access To start, admins pick a self-hosted network tool that runs on local hardware. You generate cryptographi
User Provisioning (SCIM) + Remote Browser Isolation (RBI): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up cloudless remote user access by linking user devices to private servers. This approach uses direct peer tunnels and local identity keys instead of third-party clouds. Teams often build these links with self-hosted VPN servers or peer-to-peer mesh networks. Still, once a user joins the network, broad server roles can expose sensitive data.
How to build cloudless remote user access
To start, admins pick a self-hosted network tool that runs on local hardware. You generate cryptographic key pairs on each user laptop and on each target server. Next, you register the public keys inside a local coordination server that you control. This local server helps devices find each other and trade network routes in private.
Once two machines know each other's routes, they build an encrypted tunnel across the internet. Traffic flows straight from the user laptop to the internal server without cloud stops. Next, you tie local server accounts to an internal directory or a key authority. When a developer starts a session, the target server checks their signed key locally.
You also set up host firewall rules on each machine in your private network. These rules block traffic from unknown peers and limit which ports a user reaches. For databases and internal apps, you map directory groups to local database roles. Each role grants basic rights to read tables, write rows, or run host scripts.
What local network tunnels solve and what they miss
A cloudless network setup solves data residency and third-party trust issues right away. Your raw traffic and session metadata stay inside machines that your own team manages. External cloud outages will not block your engineers from fixing a broken local server. Host firewalls and peer keys also hide your internal ports from public internet scanners.
Still, network tunnels and static server roles only check who logs in at start. Once the peer tunnel opens and the database checks the role, network checks stop. The native setup cannot inspect individual queries or shell commands as they run live. A developer with a valid read role can still pull a full customer table.
User Provisioning (SCIM) + Remote Browser Isolation (RBI): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Static roles also make it hard to mask sensitive columns during a live query. If a table holds emails, phone numbers, or card numbers, the query returns everything. You must build custom database views for every single table to hide those fields. Also, revoking a peer key takes extra work when an engineer only needs one fix.
Managing day-to-day maintenance on local links
Running your own remote links means your team must rotate keys on a schedule. When someone leaves the team, you must remove their public key from every host. If you use a local certificate authority, you should set short lifetimes for certs. Short lifetimes force clients to renew their keys often against your internal directory server.
You also need a central place to store logs from all your target servers. Without a central log store, audit trails stay scattered across dozens of local disks. Collecting database query logs and host command logs helps you review past user actions. Pairing strong local network links with runtime query checks gives you full safety.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What does cloudless remote user access mean for a security team?
It means remote workers reach internal servers without routing traffic through external vendor clouds. All key checks, routing servers, and encrypted tunnels run on hardware you control.
How do user devices find internal servers without a cloud service?
Teams run a small coordination server on their own network with a static address. User devices talk to this host to get peer IP addresses and open tunnels.
Why are network tunnels and host roles not enough for data safety?
Network tunnels and login roles only verify a user when the session first starts. They do not filter single commands or mask card numbers and emails in results.