Getting started on Anchr.ing
Create your account, set up your sign-in with a test and a production environment, and register your first apps in the dashboard.
- You get
- An account, a sign-in setup with a test and a production environment, and your first apps registered.
- For
- Founder, Backend developer
- Time
- About 15 min
- Products
- Sign-in
Anchr.ing runs the identity provider for you. You get an account on the platform and one sign-in setup (in the SDK and the URLs: a project), your own identity provider with two environments: test to build against and prod for real users.
1. Create your account
Create your account: you sign in to the platform through Anchr.ing's own hosted login. Enter your email, type the code that arrives, and you are in the dashboard. Add a passkey on your account page afterwards if you like.
2. Set up your sign-in
The dashboard starts you on Set up your sign-in: pick a name and an ID. The ID is permanent: it becomes your two hosts and the passkey domain of each environment.
https://acme.test.anchr.ing: testhttps://acme.prod.anchr.ing: production
The dashboard checks the ID as you type. IDs that use www, api, admin, prod or test as a part, or contain anchr, are reserved. The project shows as provisioning for a few seconds while its databases, keys and users are created.
3. Pick an environment
Its pages sit in the dashboard's sidebar (Apps, Users, Connections, Billing, Support, Flags, Settings and Logs; webhooks and server keys are tabs under Apps), with a Test / Production switch at the top. Everything below starts in test.
Teammates: add them on the project's dashboard under Members, with or without production access; they sign in to Anchr.ing with that address. An account has one sign-in setup below Enterprise; on Enterprise, more come from the switcher at the bottom left (New project).
4. Register your apps
In the dashboard, Apps (test), add one app per client. An example with a browser app, a CLI and the API they call:
spa (public, PKCE)http://localhost:5173/auth/callbackacme-apitest_…cli (public, device grant)acme-apitest_…resourceacme-apiSet the audience on the web and CLI apps too: an access token's aud is the app's audience, or its client id when none is set, and your API accepts only acme-api. Other kinds: web (server-rendered, confidential), native (desktop and mobile, PKCE) and service (machine to machine, see Service to service).
5. Install the SDK
bun add @anchring/auth # or: npm i @anchring/authUse one file per surface, each importing its own entry point, so the browser bundle carries no server code and nothing reads process.env in the browser:
// web/auth.ts
import { createAuth } from '@anchring/auth/browser';
export const auth = createAuth({ project: 'acme', env: import.meta.env.VITE_AUTH_ENV ?? 'test', clientId: import.meta.env.VITE_AUTH_CLIENT_ID });
// api/auth.ts
import { createAuth } from '@anchring/auth/server';
export const auth = createAuth({ project: 'acme', env: process.env.AUTH_ENV ?? 'test', audience: 'acme-api' });
// cli/auth.ts (tokens persist in ~/.config/anchring/tokens/<issuer host>/<client id>.json)
import { createAuth } from '@anchring/auth/cli';
export const auth = createAuth({ project: 'acme', env: process.env.AUTH_ENV ?? 'test', clientId: process.env.ACME_CLI_CLIENT_ID });The project and environment determine the issuer (https://acme.test.anchr.ing), discovery, keys and endpoints. Then follow the guide for each app you registered.
Runnable examples for every app type: examples on GitHub.
Every option, error and token type: the SDK README.