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

URL: https://antideploy.com/platform/authentication

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.

## At a glance

- **Email and password**: Sign-up and sign-in work from the first minute
- **Users in your Postgres**: A neon_auth schema in your own database, ready to join on
- **Cookies or JWTs**: Sessions for your server, signed tokens for your backend
- **Origins handled for you**: Your address and any custom domain are registered automatically

## 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](https://antideploy.com/agent.md)

**Your agent runs**

```bash
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
```

Related: `POST /api/v1/auth`, `GET /api/v1/auth/env`, `GET /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](https://neon.com/docs/auth/quick-start/nextjs)

**In your project**

```bash
# 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
```

## 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.

## 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. |

## 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 |

## 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.

## Authentication questions, answered.

Anything else? Write to us and a person answers.

[support@antideploy.com](mailto: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](https://antideploy.com/platform/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](https://antideploy.com/platform/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.

## 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](https://antideploy.com/platform).

- [Hosting](https://antideploy.com/platform/hosting)
- [Static sites](https://antideploy.com/platform/static-sites)
- [Deployments](https://antideploy.com/platform/deployments)
- [Database](https://antideploy.com/platform/database)
- [File storage](https://antideploy.com/platform/file-storage)
- [Email](https://antideploy.com/platform/email)
- [AI models](https://antideploy.com/platform/ai-models)
- [Cron jobs](https://antideploy.com/platform/cron-jobs)
- [Custom domains](https://antideploy.com/platform/custom-domains)
- [Environment variables](https://antideploy.com/platform/environment-variables)
- [Logs and monitoring](https://antideploy.com/platform/logs-and-monitoring)
- [Security checks](https://antideploy.com/platform/security-checks)
- [Console](https://antideploy.com/platform/console)
- [Agent API](https://antideploy.com/platform/agent-api)

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.

To set this up, give your coding agent this sentence:

```text
Set this project up to deploy on Antideploy. Fetch https://antideploy.com/agent.md and follow it.
```