# qURL vs frp: Share an App Without Running a Server > qURL vs frp: frp is a self-hosted reverse proxy that needs a server with a public IP; qURL needs no server or account and gives no public URL. Source: https://layerv.ai/compare/qurl-vs-frp/ --- [← All Comparisons](https://layerv.ai/compare/) # qURL™ vs frp A reverse proxy you host, or a link with nothing to host. frp is an open-source reverse proxy: you run frps on a server with a public IP and frpc next to your app, and it forwards TCP, UDP, HTTP and HTTPS. qURL needs no server or account: qurl publish keeps the app off the public internet, and qurl share prints a link that works once and expires within 24 hours. Facts checked October 14, 2026 against each vendor’s documentation. [Download the data](https://layerv.ai/data/localhost-tunnels/tunnels.json) frp (fast reverse proxy) exposes a service behind NAT through a server you control. qURL is an MIT-licensed CLI that publishes a local app without a public route and hands out one link per recipient. ## How qURL and frp differ frp has two parts. frps runs on a machine with a public IP; frpc runs beside your app, connects out to frps, and registers proxies by port or domain. Visitors reach the app on the server’s port or domain. For HTTP proxies frp can require basic auth; STCP and XTCP proxies admit only visitors who hold a preshared key; tokens or OIDC authenticate frpc to frps. qURL connects out from your machine too, but it gives the app no public address. qurl publish registers the app and prints its CRID, the app’s stable ID; qurl share turns the CRID into an access link for one recipient. Opening the link admits that recipient’s network address for the session; by protocol design, other addresses get no response. ## From a running app to a link you can send qURL CLI ``` qurl publish http://127.0.0.1:3000 qurl share ``` frp ``` ./frps -c ./frps.toml (on the server) ./frpc -c ./frpc.toml ``` ## qURL and frp, side by side __qURL CLI compared with frp, with the source for each value__ | Question | qURL CLI | frp | | ----------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Account needed before the first URL | No. The first publish creates the device identity [our test](https://layerv.ai/research/qurl-behaviour) | No; you run frps on your own server [github.com](https://github.com/fatedier/frp) | | What the URL looks like | A qurl.link access link per recipient; the app answers at r\_.qurl.site, a name absent from Certificate Transparency logs [our test](https://layerv.ai/research/qurl-behaviour) | Your server's IP and remotePort for TCP/UDP; your own domain (customDomains or subdomain) for HTTP/HTTPS [github.com](https://github.com/fatedier/frp) | | Who can reach it | No one until a link is opened; then the opener’s public IP for that session, including other devices behind that IP [layerv.ai](https://layerv.ai/docs/qurls.md) | Public: anyone who reaches the server port or domain; STCP/XTCP proxies only to visitors with the secret key [github.com](https://github.com/fatedier/frp) | | Warning page shown to visitors | None [our test](https://layerv.ai/research/qurl-behaviour) | Not documented [github.com](https://github.com/fatedier/frp) | | Visitor access control | Single-use access link by default; link and session lifetimes. IP allow and deny lists and other rules can gate links through the API, not the CLI [layerv.ai](https://layerv.ai/docs/qurls.md) | HTTP basic auth (httpUser/httpPassword) on http proxies; secretKey for STCP/XTCP visitors; token or OIDC authenticates clients, not visitors [github.com](https://github.com/fatedier/frp) | | Link expiry | Yes. qurl share returned a 24-hour link in our no-account test; no-account links are capped at 24 hours [our test](https://layerv.ai/research/qurl-behaviour) | Not documented [github.com](https://github.com/fatedier/frp) | | Single-use links | Yes, the default for qurl share [our test](https://layerv.ai/research/qurl-behaviour) | Not documented [github.com](https://github.com/fatedier/frp) | | Protocols | HTTP(S), WebSocket, SSE; no raw TCP [our test](https://layerv.ai/research/qurl-behaviour) | TCP, UDP, HTTP, HTTPS; secret STCP and peer-to-peer XTCP modes [github.com](https://github.com/fatedier/frp) | | Free-tier limits | Without an account: up to 3 active resources, with links that last up to 24 hours [github.com](https://github.com/layervai/qurl-integrations/blob/main/apps/cli/README.md) | No service tier; you run frps on your own server [github.com](https://github.com/fatedier/frp) | ## Which one to use ### Choose qURL to Share an app with a person or an agent without renting a server, opening a port, or putting a domain in front of it. Each link works once and expires on its own. ### When frp is the better choice Choose frp when you want the whole path on infrastructure you control, need TCP or UDP, or are exposing a long-running service such as SSH or a game server. ## Frequently Asked Questions Do I need a server to use frp? Yes. frps runs on a machine with a public IP, and frp has no hosted public server. frpc on your own machine connects out to it. Is frp open source? Yes, under the Apache-2.0 license. The qURL CLI is open source too, under MIT. Who can open a qURL link? Whoever holds it, once: with no flags, qurl share prints a single-use link. Opening it admits the network address it was opened from for the session, which lasts 1 hour by default for an app published from the CLI. Other devices on the same public IP address, such as an office or café network, can reach the app until the session ends, so keep your app’s own sign-in for anything sensitive. By default a link admits whoever opens it; access rules set through the API, such as IP allow and deny lists, can restrict that. Can my coding agent share my app with qURL? Yes. Give Claude Code, Cursor, or Windsurf the qURL skill (https://layerv.ai/skills/qurl/SKILL.md) and ask it to share the app: it installs the qurl CLI, publishes the app privately, and gives you an address to send. The agent applies the private access rules you choose. For named recipients, give it their email addresses so it can send invitations. Recipients verify their email in the browser and save a passkey; they never send you their email verification code. The agent checks policy support before sharing and keeps the app private if the deployment cannot support it. For one person right away, ask it for a one-time link instead. Codex starts with network access off, so save the skill file for it first. ## Related Resources [Open-source ngrok alternatives →](https://layerv.ai/compare/open-source-ngrok-alternatives/) [qURL vs Pangolin →](https://layerv.ai/compare/qurl-vs-pangolin/) [qURL vs zrok →](https://layerv.ai/compare/qurl-vs-zrok/) [ngrok alternatives with authentication →](https://layerv.ai/compare/ngrok-alternatives-with-auth/) [Every localhost tunnel, compared →](https://layerv.ai/compare/localhost-tunnels/) [frp ↗](https://github.com/fatedier/frp) ## Share your app without an account Paste one prompt into your coding agent, or install the qURL CLI and publish the app yourself. No sign-up, no API key. [Get the agent prompt ↗](https://layerv.ai/vibe-coding/) [Install the CLI ↗](https://layerv.ai/cli/) New to qURL? Start at [qurl.link ](https://qurl.link/) --- *This markdown version is auto-generated from [https://layerv.ai/compare/qurl-vs-frp/](https://layerv.ai/compare/qurl-vs-frp/) for AI agents. Curated agent resources: [llms.txt](https://layerv.ai/llms.txt). For the full interactive experience, visit the HTML version.*