Dargo Access: restrict who can visit your apps with an email-PIN gate

What is Dargo Access?

Dargo Access sits at the network layer, in front of your app. When it's on:

1. A visitor opens your app's URL.
2. Instead of seeing the app, they see a small sign-in page asking for their email.
3. If their email is on the allowlist you set, we send them a 6-digit code.
4. They enter the code; we drop a session cookie; they're now signed in.
5. Every subsequent visit during the session window goes straight to the app — no extra prompt.

The app underneath doesn't know any of this is happening. Ghost still thinks it's serving readers; Nextcloud still thinks it's serving files. Dargo Access is invisible to the app and to the people you've granted access to.

When you'd want this

• Family photo storage on Nextcloud — only you, your partner, and your parents should ever load it.
• An internal team tool like a self-hosted Stirling-PDF or n8n that should never get crawled by Google.
• A staging Ghost blog you and an editor are reviewing before the public launch.
• Anything you'd normally hide behind a VPN but don't want to make people configure a VPN client for.

How to turn it on

1. Sign in to my.dargo.net and open the device the app is installed on.
2. On the app card, click the small shield icon in the top-right corner (next to the open-in-new-tab arrow).
3. In the Dargo Access modal, paste the list of emails or domain wildcards that should be allowed in.
4. Pick a session length (default 30 days) — how long verified visitors stay signed in before they're asked to verify again.
5. Click Turn on. The shield icon turns green to confirm.

The change is immediate. Any open visitor session that hasn't been verified gets bounced to the sign-in page on their next request.

The allowlist format

The allowlist accepts two kinds of entries, one per line:

• Full email addresses — alice@example.com means exactly that person.
• Domain wildcards — @your-company.com means anyone with an email at that company.

You can mix them. Casing doesn't matter. Anything that doesn't look like an email or a wildcard is silently ignored.

What visitors actually see

The sign-in page is a single field — "Email address" — and a "Send code" button. It tells the visitor which app/host they're trying to reach, but it doesn't reveal the allowlist. After they submit:

• If they're on the allowlist: they see "We sent a 6-digit code to your email. Enter it below." and a 6-digit input.
• If they're not: they see the same message (we deliberately don't say "you're not allowed" — that would reveal whether a given email is on the list to anyone who guesses). No code is sent and no email is charged.

The code is valid for 10 minutes and is single-use. If they fat-finger it, they can request a new one from the same page.

How long the session lasts

After a visitor enters the right code, we drop a secure HTTP-only cookie on their browser scoped to the app's hostname. That cookie is valid for the session length you set when turning Dargo Access on — 30 days by default, configurable per app from 1 hour up to a year.

If the visitor signs in from a second device (their phone after authenticating on a laptop), they verify again on that device. Sessions are per-browser; we don't share auth across devices.

Email cost

Every code we email is one transactional email and counts toward your monthly Dargo email budget — same pool that Ghost's password resets, n8n's notifications, and your other apps' sends draw from. At normal allowlist sizes (a few people, mostly returning) this is negligible — maybe 5–20 emails a month per protected app for a small private site.

Rejected emails (addresses not on the allowlist) do not consume your budget. We check the allowlist before sending.

What it doesn't protect against

Dargo Access is network-level authentication — it controls who can reach your app at all. It is not a substitute for application-level auth. Specifically:

• If your app has its own admin password (Ghost, WordPress, Discourse, Nextcloud — all of these), keep that password strong. Dargo Access verifies a visitor is an allowed human; it doesn't make them an admin of your app.
• Anyone who has the session cookie can use it until it expires. If a visitor shares their browser with someone else, that someone else is in too. Treat session length the way you'd treat a "remember me" checkbox on any login form.
• Email is the only factor. If an allowlisted visitor's email account is compromised, the attacker can request a PIN and get in. For higher-stakes apps, pair Dargo Access with the app's own login (e.g. Nextcloud's 2FA).

Turning it off

Open the same Dargo Access modal from the shield icon → Turn off. After confirmation the gate is removed within a couple of seconds and the app becomes publicly reachable again. Existing visitor sessions are dropped — there's nothing to renew because there's no gate to renew against.

Turning it on again later doesn't restore the old allowlist or sessions — start fresh.

Custom domains

Dargo Access works the same way for custom domains (blog.your-company.com) as it does for the free *.mydargo.com subdomains. You configure it the same way in the portal, and the gate intercepts at the same network layer for both. No DNS changes needed when toggling.

Common questions

Can my allowlisted visitors share the URL with someone else?

They can share it, but the recipient still has to be on the allowlist to actually get in. The URL alone isn't a key.

Does the gate slow my app down?

For verified visitors with a session cookie: imperceptibly. The gate adds one network hop and one cookie check, both microseconds. The first-time auth round-trip (email round trip) is the only meaningfully slow part, and that happens at most once per session.

Can I see who has signed in?

Not in v1. We log allowlisted sign-ins on the server side but we haven't surfaced them in the portal yet. If you need a "recent sign-ins" view for a specific app, open a support ticket and we'll prioritise.

Does it work for apps that use websockets / Server-Sent Events?

Yes. The session cookie flows through both regular HTTP and upgrade requests, so chat-style apps that hold open a connection work normally once the visitor is signed in.

What to do next

Pick one of your installed apps that should be private, click the shield icon, add your email, and turn it on. Then open the URL in an incognito window — you'll see exactly what your visitors will see. If anything feels off, open a ticket from inside the portal and we'll walk through it.