PlatformAuthentication

Sign-up and sign-in, for your app's users.

Q: Where are my users stored?

In a neon_auth schema of your application's own Postgres database, so your tables can join on them and you can read them with any client.

Your coding agent switches on sign-in while it builds. Your users sign up with an email and a password, their accounts are rows in your own Postgres database, and your code can join on them. There is no auth provider to open an account with.

Read the API contract

Email and passwordSign-up and sign-in work from the first minute
Users in your PostgresA neon_auth schema in your own database, ready to join on
Cookies or JWTsSessions for your server, signed tokens for your backend
Origins handled for youYour address and any custom domain are registered automatically

01How it works

Switched on while your agent builds.

A login page written against a pretend user store is a login page nobody tested. Your agent turns the real service on first.

One call, before the login page.

Your agent switches sign-in on before it writes the login form, so the form is built and tested against the real service. If your app has no database yet, one is created first, and it counts against your database allowance. The variables go into your .env by a redirect, so the cookie secret is never printed.

Asking twice returns the same service, nothing is made twice
Localhost works while you build, and your app's address and any custom domain are registered for you on every deploy
A service you chose yourself, such as Clerk or Auth0, always wins

See what your agent reads

Your agent runs

$ API=https://antideploy.com/api/v1

# 1. switch on sign-in, once per project
$ curl -X POST "$API/auth?applicationId=$APP_ID" \
    -H "Authorization: Bearer $TOKEN"

# 2. write its variables into .env (the answer holds a secret)
$ curl -fsS "$API/auth/env?applicationId=$APP_ID" \
    -H "Authorization: Bearer $TOKEN" >> .env

POST /api/v1/authGET /api/v1/auth/envGET /api/v1/auth

The Next.js library, or plain HTTP.

In Next.js, install the Neon Auth library and follow Neon's quickstart. The two variables it asks for are already set. In any other stack it is Better Auth over HTTP at NEON_AUTH_BASE_URL: sign up, sign in, read the session, or take a signed token your backend can verify.

The library is a beta, so Neon's quickstart is the source of truth for its code
A request that changes anything needs an Origin header that is your app's own address
A backend verifies a token against the keys at the JWKS address

Neon's Next.js quickstart

In your project

# Next.js
$ npm install @neondatabase/auth@latest

// any other stack: Better Auth over HTTP at NEON_AUTH_BASE_URL
POST  /sign-up/email    {"email", "password", "name"}
POST  /sign-in/email    {"email", "password"}
GET   /get-session      the signed-in user, from the cookie
GET   /token            a JWT; verify it with NEON_AUTH_JWKS_URL

02What you get

Accounts you own, in your own database.

The service runs for you, but the data is yours: the people who sign up are rows in a schema of the database your app already uses.

Your users are rows in your Postgres. Sign-up writes to a neon_auth schema in your application's own database, next to your tables. Join your own data on the user table like any other, and read it with any client.
Email and password, on from the start. People can sign up and sign in with an email address and a password as soon as sign-in is on. Email verification is off by default, which suits a first version.
A cookie for your server, a JWT for your backend. The session cookie is set by the service itself. GET /token returns a signed JWT that a separate backend can verify against the public keys at NEON_AUTH_JWKS_URL.
Trusted origins, without the configuration. Antideploy registers your app's address, every domain apps are published under, and any custom domain you attach, when sign-in is switched on, on every deploy and when a domain is added. A request from an origin nobody registered is refused.
Bring your own if you prefer. Clerk, Auth0, Supabase Auth or your own sessions in Postgres all work. A service you chose yourself wins, and Antideploy leaves it alone.
No second system to keep in step. There is no user table to mirror into your database and no webhook to keep it in sync, because the users are already there.

03Reference

The variables your app receives.

Set by the platform in the running app, and written to your .env by your agent for local work.

Variable	What it holds
`NEON_AUTH_BASE_URL`	Where the service answers. The Next.js library and plain HTTP both use it.
`NEON_AUTH_COOKIE_SECRET`	The secret that signs session cookies. Different for every application, and never shown after it is written.
`NEON_AUTH_JWKS_URL`	The public keys a backend uses to verify a JWT.
`VITE_NEON_AUTH_URL`	The same base address, available to a Vite front end at build time.

04Defaults

What is on, and what is not.

The service is set up for a first version. These are its defaults.

Setting	Default
Email and password	On
Email verification	Off
Password reset emails	Sent by the service from a shared sender, which is rate limited and suits development
Google and GitHub sign-in	Not set up. They need an OAuth app of your own with the provider.
Session cookie	`HttpOnly`, `Secure`, set by the service itself
Signed token	A JWT signed with EdDSA, verified against the JWKS address
Rate limit	About nine sign-up or sign-in attempts per ten seconds from one address, then `429` with an `x-retry-after` header

05Before you commit

Here's where it stops.

A platform that only tells you what it is good at is one you find the edges of in production. These are sign-in's.

Verification emails are off
Email verification is off by default, and the emails the service sends, such as a password reset, come from a shared sender that is rate limited and suits development.
No social sign-in set up for you
Google and GitHub sign-in need an OAuth app of your own, so they are not switched on automatically. Your agent leaves them out unless you ask.
About nine attempts per ten seconds
Sign-up and sign-in are limited per address, then the service answers 429. Through the Next.js library every visitor reaches the service from your app's server, so they share that allowance.
The Next.js library is a beta
Neon's library may change, so its quickstart is the source of truth for its code. The plain HTTP interface is the stable one.
It needs a database of ours
The users live in the Postgres Antideploy created. A project that connects to a database of its own cannot use it, and keeps the sign-in it has.

06Questions

Authentication questions, answered.

Anything else? Write to us and a person answers.

support@antideploy.com

What is it built on?

Neon Auth, which is Better Auth run by Neon. Antideploy switches it on for your application's own Postgres database and registers your app's addresses with it.

Where are my users stored?

In a neon_auth schema of your application's own Postgres database, so your tables can join on them and you can read them with any client.

Do I pay per user?

Antideploy does not charge per user. Sign-in is included in your plan, and the only allowance it uses is the database it needs, which counts toward your database limit: 1 on Free and Go, 3 on Pro and 5 on Scale.

Can users sign in with Google or GitHub?

Not out of the box. Social sign-in needs an OAuth app of your own with the provider, so your agent leaves it out unless you ask for it.

Does it send verification or password-reset emails?

Email verification is off by default. The service sends emails such as a password reset from a shared sender that is rate limited and suits development. For mail your own app sends, use Antideploy email.

What are the rate limits?

Sign-up and sign-in are limited to about nine attempts per ten seconds from one address, and a tenth is answered with a 429 and an x-retry-after header. Show a person a message to try again rather than an error. Reading a session is far looser.

Can I use Clerk, Auth0 or Supabase Auth instead?

Yes. A service you chose yourself wins. If your project sets its own NEON_AUTH_BASE_URL, or connects to a database of its own, Antideploy leaves sign-in alone.

How do I know who is signed in on my server?

In Next.js the library reads the session for you. In any other stack, call GET /get-session with the visitor's cookie, or take a JWT from GET /token and verify it against the keys at NEON_AUTH_JWKS_URL.

Which plans include it?

Every plan. It needs a database, so it counts toward your database allowance.

+The rest of the platform

Everything else your app can use.

Every service is created by your coding agent, wired into your app, and included in the plans. See the whole platform.

Facts on this page were checked against the live platform on 5 October 2026.

Add sign-in. In one sentence.

Paste the sentence into your agent. It switches sign-in on, writes the variables into your project and builds the login page against the real service.

Start from GitHub or a folder

Sign-up and sign-in, for your app's users.

One call, before the login page.

The Next.js library, or plain HTTP.

Verification emails are off

No social sign-in set up for you

About nine attempts per ten seconds

The Next.js library is a beta

It needs a database of ours

Add sign-in. In one sentence.