qURL™ vs Your Own Token Proxy
What a homemade capability URL has to get right, and the two commands that replace it.
A homemade capability URL is a proxy that checks a secret token before passing requests to your app, plus a tunnel or public route to reach it. You then own token issue, expiry, single use, revocation, and teardown. qURL does that job with two commands: qurl publish keeps the app off the public internet, and qurl share prints a single-use link that expires within 24 hours.
Asked to give one person temporary access to a private app, many developers and coding agents reach for the same build: generate a random token, put a small proxy in front of the app that checks it, and expose the proxy through a tunnel. That works. This page covers what it takes to make it work well, and when building it is still the right call.
Share one app from the command line
qurl publish http://127.0.0.1:3000
qurl share <CRID>Architectural Difference
A homemade capability URL has five parts, and each one is yours to get right:
- A route in: the proxy needs a public address, usually a tunnel such as ngrok or Cloudflare Tunnel, which puts a front door to the app on the internet for anyone to probe.
- Token issue: unguessable tokens from a secure random source, stored hashed, and compared in constant time.
- Expiry and single use: a clock on every token, and an atomic check that marks a token used so two requests cannot both redeem it.
- Revocation: a way to end one token early without restarting the proxy or touching anyone else’s.
- Teardown: stopping the proxy and the tunnel when the work ends, so the route does not outlive the need.
qURL covers the same five with two commands. qurl publish registers the app and connects outbound, so the app gets no public address to probe. qurl share prints a link for one recipient; with no flags it opens once and expires within 24 hours. With an account, the API revokes one link without touching the others, and qurl stop <CRID> stops serving the app.
Neither approach tells your app who the recipient is. A qURL link grants access to whoever opens it, and opening it admits that network address for the session, so keep your app’s own sign-in for anything sensitive.
Feature Comparison
| Feature | qURL | Your Own Token Proxy |
|---|---|---|
| A route in | An outbound connection; the app gets no public address | A tunnel or public route to your proxy |
| Issuing tokens | qurl share, the SDK, or the API | Your code: random tokens, stored hashed |
| Expiry | Set on each link; at most 24 hours without an account | Your code |
| Single use | The default for qurl share | Your code, with an atomic redeem |
| Revoking one recipient | Revoke that link through the API; other links keep working | Your code |
| Adding the app’s own credential to requests | Yes: add request headers with an advanced CLI setup | Yes: the proxy can add any header |
| Code you maintain | None | The proxy, the token store, and the tunnel setup |
Which one to use
Choose qURL to
One person or agent, one private app, for a while: a client preview, a contractor’s look at an internal page, or a private test target for an agent. Two commands, nothing to maintain, and the app never gets a public address.
When building your own is the better choice
Build your own when the proxy needs custom per-request rules or must run on a network that cannot reach LayerV.
Frequently Asked Questions
What is a capability URL?
A URL that carries its own access authority: whoever holds it can use it, within its expiry, use limits, and policy. A qURL link is one, and so is a homemade token link. Either way, treat the link as a secret.
Is a random token in a URL secure enough?
It can be, if the token is long and random, sent only over HTTPS, kept out of logs and referrer headers, and limited in time and uses. The risk sits in the parts around it: a proxy exposed through a public tunnel can be found and probed, and a token that never expires keeps working wherever it was pasted.
Can qURL add my app’s Authorization header?
Yes. Give an agent access to a private app that needs an Authorization header without building a separate proxy. This requires an advanced CLI setup: a program that runs qurl supplies the headers through the CLI’s local control interface. See the qurl CLI README on GitHub (layervai/qurl-integrations, apps/cli/README.md).
How is this different from a public tunnel?
A public tunnel exposes an endpoint and can protect it with authentication. With LayerV, your local app stays hidden from public scans. You create a private, expiring way in for one resource at a time. A teammate or AI agent can use the app without a public deployment or access to your wider network.
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.
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.
New to qURL? Start at qurl.link