Secure access
Give remote teams access without a VPN
Give a remote colleague or agent access to the app they need. Keep the origin private, reuse its cryptographic identity, and issue a fresh access link for each task.
Make access as simple as the work request
A contractor needs one dashboard, but access can require a client install, network setup, and a new set of ongoing permissions. The work should not wait for network enrollment. Give each task a direct, bounded way to reach the app.
| The usual fix | What to consider |
|---|---|
| VPN access | Client installation and network enrollment add steps when a collaborator needs only one web app. |
| Standing access policies | Ongoing membership needs review when the work is temporary. Issue a separate grant for each task. |
| IP allowlisting | Changing home and mobile addresses create maintenance work for remote teams. |
One app. One task. One access grant.
Keep the origin private. LayerV verifies access before the protected origin connection opens; your app serves the authorized task.
# Install the latest CLI and run qurl login first. qurl publish http://127.0.0.1:3000 # Copy the CRID printed by publish. qurl share <CRID> --ttl 1h
Send the returned access link to the recipient. The CRID identifies the resource and does not grant access on its own.
Publish the app
Start the HTTP app on loopback on this host. Publish it with the qURL CLI and save its CRID. Close any separate public route.
Issue an access link
Use the CRID to issue a fresh signed access link for this task through the CLI, SDK, or API. Keep your app login for verified user identity.
Set the access window
Set link expiry and supported use limits. An open session has its own lifetime; revoke the link or delete the resource when access must end early.
What to install, and how someone gets in
Give access with
An access link issued with the CLI, SDKs, or API ↗- 01Install the qURL CLI and enroll this machine with qurl login
- 02Keep the app running on loopback and publish it with qurl publish http://127.0.0.1:3000
- 03Restrict any old public route and verify it no longer reaches the app directly
- 04Issue an access link with qurl share <CRID>, or use the API for additional policy controls
- 05Use qurl stop <CRID> to pause local serving, or qurl delete <CRID> to retire the resource
Private access that travels with the work
Hidden until access is authorized
Keep the origin off the public internet. LayerV checks access before opening its connection to the app.
A stable name for every task
Reuse the CRID to issue new grants. The resource identity stays separate from its address and each access link.
Browser access
Recipients need no qURL CLI or LayerV account; retain the app’s sign-in when needed.
Controlled lifetimes
Set link expiry and use limits, with separate session-duration controls.
Built for
- Organizations with remote or hybrid workforces
- Companies that have experienced VPN-related security incidents
- Security teams managing multiple VPN appliances
- Organizations moving from VPN to zero trust
Questions
Do users need to install a VPN client or agent?
Browser recipients need no VPN client, qURL CLI, or LayerV account. This guide covers HTTP applications; use other connectivity tools where non-HTTP traffic is required.
How is this different from ZTNA products like Zscaler or Cloudflare Access?
Cloudflare Tunnel and ZPA App Connectors can also connect private origins outbound. LayerV focuses on issuing access links for individual resources; compare the workflows and policies your deployment needs.
What happens when a session ends?
That session closes. The resource remains published and other valid links or sessions can continue. Link expiry prevents new redemption; deleting the resource retires it.
Can LayerV fully replace our VPN?
LayerV can provide browser access to specific HTTP applications. Keep your VPN or other connectivity tools for network-level access, non-HTTP protocols, or traffic-routing requirements.