Sign-in, roles, plans, feature flags and support chat from one token, checked offline in your API. Point your coding agent at the docs and it wires up the rest.
const auth = createAuth({
project: 'acme', env: 'prod', audience: 'acme-api', access, flags,
});
app.use('/api/*', auth.middleware()); // offline: no call per request
// Role, plan and flag: one token, one guard
app.post('/api/reports/export',
auth.require('report:export', {
plan: ['team', 'scale'],
flag: 'bulk-export',
}),
exportReports);When a user signs in, their token carries their identity, organisation and roles, their plan and payment status, and everything your feature flags target. Your API checks it all in one guard, offline, with cached keys.
sub · amrorg.rolebilling.planflag()Each part reads from or writes to the user's token, so they agree with each other without glue code.
Passkeys, passwords, email codes, social logins, and enterprise SSO with SCIM. Hosted pages in your brand, in English and Danish.
Teams, invites, custom roles and org switching inside your app. Permissions are typed and checked offline.
Our own billing engine: plans, proration, dunning, invoices and EU VAT with reverse charge and OSS. Charges run through your Adyen account.
Roll out by plan, org, role or percentage. Evaluated offline from the token, with a kill switch and a change log.
Talk to signed-in users and visitors with their plan, roles and flags beside each conversation. Support access is time-limited and audited.
llms.txt, rule files for Claude Code, Cursor and Copilot, and an MCP server that plans the integration and explains errors.
Sign in with the accounts your users already have
Your API checks tokens on its own, with no call per request. Per-route rules ask for a recent second factor or a permission. Your frontend gets the user as a signal or a hook, and your tests sign tokens offline.
import { createAuth } from '@anchring/auth/server';
const auth = createAuth({ project: 'acme', env: process.env.AUTH_ENV ?? 'test', audience: 'acme-api' });
const perms = auth.permissions({
roles: { member: ['report:read'], admin: ['report:*'] },
context: async (user) => ({ role: await roleOf(user.sub) }),
});
app.use('/api/*', auth.middleware()); // tokens checked offline
app.use('/api/billing/*', auth.middleware({ policy: { requireMfaWithin: '15m' } })); // a recent second factor
app.delete('/api/reports/:id', perms.guard('report:delete', (c) => loadReport(c.req.param('id'))), removeReport);Hono, Express or any framework. A revoked session stops at its next refresh (minutes), or at once with back-channel logout.
The docs are written for coding agents as much as for you. Your agent reads the rules, plans the integration with the MCP server, and writes code that uses the SDK as documented.
claude mcp add anchring -- npx -y @anchring/mcpRules for the agent: add CLAUDE.md to CLAUDE.md
Add Anchr.ing sign-in to this app with @anchring/auth:
project acme, environment test. Protect the API,
and gate exports on the Team plan.A typical stack joins a sign-in provider, a billing service, a flag service and a chat tool with webhooks and your own code. Anchr.ing does the same jobs from one token.
Each of these is a capable product on its own; product names are trademarks of their owners. You can also use Anchr.ing for sign-in only and keep the rest.
A customer's employees sign in through their company's identity provider, set up per organisation in your dashboard or by the customer's own admin.
The ID you pick becomes two hosts: one for testing, one for real users. They share nothing but the name: separate users, keys, apps and webhook secrets. In test, mail to your users lands in the mail log instead of being sent.
https://acme.test.anchr.inghttps://acme.prod.anchr.ingimport { createAuth } from '@anchring/auth/server';
// Same code in both environments: only AUTH_ENV changes.
export const auth = createAuth({
project: 'acme',
env: process.env.AUTH_ENV ?? 'test', // 'prod' after the promote
audience: 'acme-api',
});
app.use('/api/*', auth.middleware()); // offline verification, no call per requestSign up, pick an ID, and get a test and a production environment with their own hosts.
Add your browser app, API or CLI in the dashboard and copy its client ID.
Sign users in from your app and check their tokens in your API, a few lines each.
Copy apps, webhooks and settings from test to prod in one step, then swap in the prod client IDs.
Read the getting-started guideExport your users from the provider you have today and upload the file in the dashboard. It is converted in your browser, checked, and imported into the environment you pick.
Not a flag on production: its own users, keys and apps, and mail kept in a log instead of sent. Every feature works there on every plan.
Your API verifies tokens with cached keys, so a slow or unreachable sign-in service doesn't slow your API down.
You get your own database, signing keys and secrets, in test and in production, so your data never sits next to anyone else's.
OpenID Connect, OAuth with PKCE, WebAuthn, SAML and SCIM. Any OIDC library works; the SDK just makes it shorter.
environments, test and production
social providers built in, plus any OpenID Connect
providers to import your users from
calls to us when your API checks a token
Every customer gets its own namespace with separate test and production databases. Our server reaches each one only through that environment's own database user, so a query that forgets a filter, or a token from one customer used against another, is refused by the database itself.
Servers at Hetzner in Germany and Finland, sign-in mail through Brevo in France, and a GDPR data processing agreement with every customer.
Sub-processorsSimon ApS, Hellerup, Denmark (CVR 38213458). Founder-led: support replies come from the people who build it.
About usA database per project and environment, argon2id passwords, keys encrypted per project, and a disclosure policy.
Security overviewNightly backups kept for 30 days, at most 24 hours of data at risk and 4 hours to restore. Your API keeps checking tokens while we are down.
Service statusPlans grow with your sign-in apps and monthly active users. APIs and backend services are free, and test environments include everything, always.
For hobby apps and trying it out.
For your first product in production.
For growing products, and your first business customers' SSO.
For products at volume.
Sign-in, organisations and roles, billing, feature flags and support chat for your apps, as one system built around the user's token. Your apps use it through OpenID Connect and one SDK for browsers, servers and CLIs.
No. Your sign-in is a standard OpenID Connect provider with discovery, so any OIDC or OAuth library works. The SDK makes the common cases a few lines and adds offline permissions, policies and webhook verification.
In the EU, on Hetzner servers in Germany and Finland. Anchr.ing is run by Simon ApS, a Danish company, under a GDPR data processing agreement. The security page has the details.
On the Sovereign plan: a dedicated EU deployment, or the same software on your own servers under licence, so you can start hosted and move it in-house later.
Build everything. Test environments have every feature on every plan; the plan decides what production gets and how many users it counts.
Yes. Import users from Auth0, Clerk, Firebase, Supabase, Amazon Cognito or Keycloak in the dashboard. Passwords carry over where the provider exports the hashes; where it doesn't, you email every user a link to set a new one, from the dashboard. Your apps switch by changing their issuer and client ID.
Create your account, set up your sign-in, register your apps: all in the dashboard.