Add a login to your site with one DNS record.
Point login.yourdomain.com at us. We host the login page, keep it secure, and hand your app a signed cookie you verify with a few lines of code — in whatever language you already use. No SDK. No redirect dance. No token exchange.
We're not taking signups yet. Join the list and you'll be the first to know when you can create your login. Until then, see how it works.
Three steps. One of them is a DNS record.
You don't install anything. You tell us how your users should sign in, point a subdomain at us, and check a signature. That's the whole integration — and if you ever leave, there's nothing to rip out.
Create a login app
Name your domain, pick how users identify themselves and how they prove it, and choose where they land after signing in.
Add one CNAME
Point your login subdomain at the address we give you. We watch for it to resolve, and your login page comes up — secured, with nothing else to configure.
Verify the cookie
After sign-in we write a signed sl_session cookie to your parent domain. Your app checks the signature with your public key — locally, no network call.
A signature check, not a client library.
The session cookie is self-contained: data:signature, signed with your app's private key. Verifying it is pure local math against the public key you download from the console. No SDK to install, no callback to our servers, nothing to keep on the critical path of your page loads.
Which means it works in any language and any runtime — an Express middleware, a Django decorator, a Lambda@Edge function in front of CloudFront, or a Go handler. If a runtime can verify an Ed25519 signature, it can verify a Subdomain Login session.
// Public key from Application Settings → Cookie Config import { verify } from 'node:crypto'; const PUBLIC_KEY = `-----BEGIN PUBLIC KEY----- … -----END PUBLIC KEY-----`; export function requireLogin(req, res, next) { const [data, sig] = (req.cookies.sl_session ?? '').split(':'); if (data && verify(null, Buffer.from(data), PUBLIC_KEY, Buffer.from(sig, 'base64url'))) { req.userId = data; // signed by Subdomain Login return next(); } res.redirect('https://login.yourdomain.com'); }
Everything a login needs, none of what a platform demands.
The login page, the users, the abuse protection, and the audit trail are ours to run. The session, and the rest of your app, stay yours.
Email, username, phone, or access code
Choose how users identify themselves — or skip identification entirely with a shared access code for gated content.
Passwords, access codes, Microsoft Entra ID
Combine methods in sequence or let users choose. Bring your Entra tenant for workforce sign-in without building SSO yourself.
Back to where they were
After signing in, users land on the page they were trying to reach — or a destination you choose. No detour through a third-party domain.
Invite, import, and manage users
Add users from the console or send invitation links. Users can manage their own account and password after signing in.
Ed25519, RSA-PSS, or post-quantum ML-DSA-65
Pick the signature algorithm per app, and optionally encrypt the cookie payload. Verify with the standard library in your language.
Rate limiting and lockout built in
Failed attempts are throttled per identity and per source before they cost you anything — and we never bill them.
Every attempt, logged
See who signed in, from where, on what device — successes and failures — with retention you control.
Your logo, your colors
The login page carries your branding. Hide ours entirely if you'd rather it looked like you built it.
Nothing to uninstall
Leaving means deleting a DNS record and a middleware function. Your users, your routes, and your framework were never touched.
The SDK is where the lock-in lives.
Every hosted auth provider ships a client library that manages your session for you. That's convenient on day one and a rewrite on the day you want to leave. We don't ship one.
Typical hosted auth
- Install a framework-specific SDK and wrap your app in a provider
- Redirect to their domain, receive a code, exchange it for tokens
- Store, refresh, and rotate tokens the SDK decides how to handle
- Billed per monthly active user, whether they log in once or fifty times
- Switching providers means replacing the session layer
Subdomain Login
- One CNAME record — no package to install
- Users sign in on your own subdomain and come straight back
- A single signed cookie on your domain; your app verifies it locally
- Billed per login — a user who signs in once costs a twentieth of a cent
- Switching away means deleting a DNS record
Pay per login, not per user.
A cookie is cheap to sign, so we don't charge you monthly for users who aren't signing in. You pay for the login ceremony itself, in fractions of a cent, with no plan to pick and no tier to outgrow.
| event | what it is | price |
|---|---|---|
| login | Full authentication A user identifies themselves, proves it, and receives a freshly signed session cookie. |
$0.0005each |
| renewal | Session renewal A returning user's session is extended or re-signed without asking them to sign in again. |
$0.0001each |
| failed | Failed attempt Wrong password, bad code, rate-limited request. Logged for you, throttled by us, never billed — nobody can run up your bill by guessing. |
Free |
That's 20,000 logins — more than most side projects see in a year. No card needed to start; add one when the credit runs low.
Doing the math
A user who signs in once and is silently renewed three times in a month costs $0.0008 — under a tenth of a cent per active user.
No minimum, no tiers
Ten logins or ten million, the rate is the rate. There's nothing to upgrade to and no feature we hold back for a bigger plan.
Enterprise
Need SSO across many tenants, custom retention, or a contract? Join the list — we'll reach out to everyone on it before we open the doors, and that's the moment to tell us what you need.
Things people ask before pointing DNS at a stranger.
Does this work with my framework?
If your server can read a cookie and verify a signature, yes. There is no framework integration to support because there's no SDK — the entire contract is a cookie named sl_session containing data:signature, and a public key you download once. Node, Python, Go, Ruby, PHP, .NET, Rust, edge runtimes, static sites behind CloudFront — all the same few lines.
Why a subdomain instead of a script tag or a redirect to your domain?
Because the cookie has to live on your domain. Signing in at login.yourdomain.com lets us set a cookie for yourdomain.com directly, so the user is simply signed in when they come back — no code exchange, no token handoff, no third-party cookie problems. Your users also never leave a domain they recognize.
What can I put in the cookie?
By default just the user's identifier, signed. You can optionally include login time, expiration time, and an authentication ID, and optionally encrypt the payload with AES-256-GCM so only your servers can read it. Choose Ed25519, RSA-PSS, or ML-DSA-65 for the signature — the last one is post-quantum, for the cautious.
How do I sign users out?
Send them to login.yourdomain.com/logout. It clears the session cookie on your domain and returns them to the login page. Your app can also just stop honoring a cookie past whatever age you decide.
What happens if I stop using Subdomain Login?
Delete the CNAME and your middleware. Your users' identifiers are yours to export from the console first. Nothing else in your application referenced us — that's the point.
Who is this for?
Solo developers and small teams who want a working login in an afternoon without adopting a platform. Gating a client preview, a family app, an internal tool, or the first version of a SaaS. If you need SAML federation with a dozen enterprise IdPs and a SOC 2 report, you'll want something heavier — and we'll tell you so.
Be the first to know when you can create your login.
We're putting the finishing touches on before we open signups. Leave your email and we'll tell you the moment you can create an app, add the record, and verify the cookie — with the first $10 of logins on us.