Shared storage

Elevate and zero-access follow Better Auth storage. There is no plugin topology option and no in-memory product adapter.

Wire this for every compose guide, including a single Worker. Labs use sqlite or D1 — not Better Auth's memoryAdapter.

What Better Auth already provides

Do not pass process-local Map stores into elevate / zeroAccess. Package memory factories are test primitives, not a deploy path.

Pattern

export const auth = betterAuth({
  secret: process.env.BETTER_AUTH_SECRET!,
  database,
  secondaryStorage, // shared DO / Redis / KV
  session: {
    cookieCache: { enabled: false },
    storeSessionInDatabase: true,
  },
  rateLimit: { storage: "secondary-storage" },
  plugins: [
    ...passkeyStack.plugins,
    loginFactors(),
    elevate({
      passkeyCounterGuard: passkeyStack.controller,
      // secondaryStorageSecurity from runElevateStorageConformance
      passwordOnlyIfNoStronger: true,
      elevatedTtlSec: 300,
    }),
    zeroAccess({
      // securityLevel: "strict",
      // recoveryIpAddressTrust: "trusted-edge",
      requireRecoveryExportAck: true,
      assertAccess: /* createZeroAccessAssertAccess(…) */,
    }),
  ],
});

Full production-shaped sketch: Quick start. Plugin option surface: Plugin contract · API.

Conformance

Method presence on a store is not enough. Run the package conformance harnesses against the same object Better Auth retains (runElevateStorageConformance, verifyZeroAccessSecondaryStorageConformance) and pass the returned capabilities into the plugins. Fail closed if the harness rejects the binding.

Security graduation

Passkey stack posture and zeroAccess securityLevel: "strict" are separate from storage. You can share Redis at standard while integrating; pin strict (and trusted recovery IP) when the edge story is real.

See gradual security on Passkey login and the hard rules on Checklist.

Next

• Compose paths: Use cases
• Elevate stores / claims: Elevate / sudo · API — Elevate
• Blind store: Vault composition · API — Zero-access