Skip to content
For enterprise

Identity your security team signs off on.

Every customer and environment isolated with its own database and keys, EU hosting, policies per route, and a contract with your limits and terms. Hosted by us, or on your own servers.

The problem

Identity is too important for a black box

Shared databases and long sub-processor lists make every vendor review slower.

Off-the-shelf plans don't fit: you need custom limits, terms you can negotiate and someone to call.

Rules like a recent second factor for payments or an IP allow-list end up hand-coded in every service.

How Anchr.ing helps

Enterprise, without the enterprise suite

Isolated by design

Each customer and environment has its own database, signing keys and encrypted secrets.

Policies in code

A recent second factor, a maximum session age or an IP range per route, enforced offline by the SDK.

SSO and SCIM without limits

As many SSO connections and organisations as you need, with SCIM provisioning and enforced SSO.

Hosted or on-premises

Run on Anchr.ing in the EU, or the same software on your own servers under licence.

Isolation by design

Isolation your security review can check

Each customer has its own namespace, with test and production in separate databases. Our server reaches each through that environment's own database user, so a query that forgets a filter, or a token used against the wrong customer, is refused by the database itself. Keys and secrets are protected separately, as the security page describes.

How customers are kept apartEach customer has its own namespace with separate Test and Production databases. Each environment holds its own users, apps, sessions and tokens, signing key and database user. A request from customer A's production app reaches only A's production database: a query from it towards customer B is refused by the database itself, and test never trusts production. A's production app Anchr.ing server Customer Aown namespace TestUsersAppsSessions, tokensSigning keyDatabase user ProductionUsersAppsSessions, tokensSigning keyDatabase user Test never trusts production Customer Bown namespace TestUsersAppsSessions, tokensSigning keyDatabase user ProductionUsersAppsSessions, tokensSigning keyDatabase user The databaserefuses How customers are kept apartEach customer has its own namespace with separate Test and Production databases. Each environment holds its own users, apps, sessions and tokens, signing key and database user. A request from customer A's production app reaches only A's production database: a query from it towards customer B is refused by the database itself, and test never trusts production. A's production app Anchr.ing server Customer Aown namespace TestUsersAppsSessions, tokensSigning keyDatabase user ProductionUsersAppsSessions, tokensSigning keyDatabase user Test never trusts production Customer Bown namespace Test Production The database refuses
One token

Every check reads the same token

When a user signs in, their token carries who they are, their organisation and role, their plan and payment status, and what your flags target. Your API checks it in one guard, offline, and your UI reads the same answers.

Identitywho signed in, and howsub · amr
Rolesthe organisation and what it allowsorg.role
Billingthe plan and its payment statusbilling.plan
Flagswhat is switched on for this userflag()
In your code

Security policy, enforced in your API

A failed policy answers with the standard step-up challenge, so the app asks for a second factor and retries.

api/auth.ts
import { createAuth } from '@anchring/auth/server';

const auth = createAuth({
  project: 'acme', env: 'prod', audience: 'acme-api',
  policy: { maxSessionAge: '12h', allowIps: ['10.0.0.0/8', '2001:db8::/32'] },
});

app.use('/api/*', auth.middleware());
// Payments need a second factor from the last 15 minutes
app.use('/api/payments/*', auth.middleware({ policy: { requireMfaWithin: '15m' } }));
The plan

Enterprise in numbers

Prices in euros, excluding VAT. Test environments include every feature on every plan.

€2,000

and up a month, by agreement

Unlimited

enterprise SSO connections with SCIM

Unlimited

projects, each with test and production

Unlimited

monthly active users

Questions

Before you start

Where is our data?

Hosted in the EU, and the sub-processors page lists every company involved and where. On-premises, it never leaves your servers.

Can we have our own terms?

Yes. The standard terms and DPA are public, and an Enterprise agreement can add yours, with limits set for your volume.

How does on-premises work?

You run the same software on your own servers under licence, with private images and updates from us. Start hosted and move in-house later, or the other way round.

Talk to us about Enterprise

Tell us about your users, your requirements and your timeline.

We reply within one business day.
Who it's for

For developers

The Free plan

For startups

The Startup plan

For B2B SaaS

The Team plan

For agencies

The Team plan

For scale-ups

The Scale plan

Sovereign and public sector

The Sovereign plan

Compare all plans

Every plan side by side, and the questions people ask before paying.