Codapult provides the foundation and evidence map for enterprise production deployments. Use this page to connect automated verification with the deployment configuration and acceptance steps that complete your launch.
Evidence matrix
| Area | Built-in evidence | Production acceptance |
|---|---|---|
| SAML SSO | SSO adapter and authorize/callback route tests cover missing input, redirects, profile failures, and successful mocked exchange. | Run one real IdP acceptance flow with the production callback URL, tenant mapping, logout/session policy, and certificate rotation procedure. |
| SCIM provisioning | SCIM token, authentication, user lifecycle, organization scoping, and route tests cover the supported resources. The endpoint is rate-limited. | Run a provider-specific sync against a staging organization and verify create, update, deactivate, reactivation policy, and token rotation. |
| Tenant isolation | Organization-aware route tests cover membership and forbidden organization access; database queries carry organization scope where the feature is organization-owned. | Add an integration fixture for every new organization-owned resource and test cross-tenant reads, writes, exports, jobs, and search indexes before release. |
| Billing webhook retry/idempotency | Provider adapters verify raw signatures and normalize provider events. Verified provider event IDs are durably claimed before side effects, repeated deliveries are acknowledged, and failed claims remain retryable. Subscription updates are safe to reapply by provider subscription ID. | Reconcile different valid events when a provider delivers them out of order. Never treat event deduplication as a substitute for provider reconciliation or a billing ledger. |
| Job retry and dead letter | BullMQ provides durable retries and failed-job state; outgoing webhook deliveries have bounded backoff, dead-lettering, and replay. The memory adapter is development-only and deduplicates explicit jobId values. | Use BullMQ/Redis in production, alert on failed/dead-lettered jobs, and rehearse replay with an idempotent handler. |
| Backup and restore | The deployment runbook contains Turso, PostgreSQL, and local recovery procedures plus isolated-restore validation. | Configure provider retention, assign an owner, record RPO/RTO, and perform a restore drill against a non-production target. |
| Migration rollback | Migration docs define append-only migrations, expand/contract changes, forward fixes, and isolated restore. | Do not rely on automatic rollback. Record the rollback or forward-fix decision for each production migration. |
| Observability | Structured logs, request IDs, PII redaction, Sentry, OpenTelemetry, health checks, and queue diagnostics are documented. | Configure alerts, log retention, trace sampling, dashboard ownership, and provider-specific thresholds. |
| Rate limits | Auth, SCIM, AI, billing, admin, and public API paths have route/unit coverage for throttling behavior. | Memory rate limiting is not shared across instances; use a distributed store or an edge/provider limit for multi-instance deployments. |
| Security headers and CSP | next.config.ts, the request nonce path in proxy.ts, CSP unit tests, and security-boundary E2E checks provide automated evidence. | Verify headers and CSP on the deployed hostname after every proxy, domain, analytics, or third-party script change. |
| Disaster recovery | The deployment runbook covers database, object storage, application rollback, health checks, and release evidence. | Define incident roles, communication channels, RPO/RTO, regional failure assumptions, and the restore decision authority. |
| Data retention | Account export/deletion, logger redaction, Sentry scrubbing, and the data retention policy provide a recommended baseline. | Configure and verify provider-specific backup, log, trace, webhook-payload, and object-storage retention; document legal or contractual overrides before launch. |
Verification commands
Run the deterministic evidence before a release:
pnpm type-check
pnpm test
pnpm test:e2e --project=chromium e2e/security-boundaries.spec.ts
pnpm exec vitest run src/app/api/auth/sso src/app/api/scim src/app/api/webhooks src/lib/jobs src/lib/cspFor a production-like staging environment, add the manual checks:
- Complete a real SAML login with the configured enterprise IdP.
- Run a SCIM sync and verify membership changes in the target organization only.
- Send a signed duplicate payment event and confirm the final subscription state is correct.
- Fail a webhook delivery, observe retry/backoff, move it to the dead-letter state, and replay it.
- Restore the database and object-storage versions into isolated targets and run the security-boundary suite.
- Trigger a controlled error and queue failure, then verify logs, traces, alerts, and runbook ownership.
Boundaries
The automated suite uses provider mocks where an external identity provider, payment provider, Redis, or cloud backup would otherwise be required. A green test suite proves the application contract; it does not prove that the customer's IdP, database retention, Redis failover, alert routing, or restore permissions are configured correctly.
Keep the evidence artifact with the deployment commit, migration output, backup identifier, environment, operator, and timestamps. This turns production readiness into a repeatable release record rather than a one-time assertion.