parity
Agent-native application platform

Production parity for every agent

Give your agents a copy of production on every branch: your services, Postgres, Redis, S3, SMTP and Auth, isolated from everything else. Staging and production run on the same platform, from the same configuration.

Get early access
Sandboxclaude-1 · feature/team-invitesready
urlown hostname
https://web--team-invites--acme.env.parity.ninja
postgresnon-superuser
16.4 · migrated to 0042 · seeded
redisown instance
7.4 · 1,204 keys
s3per-sandbox key
acme-team-invites-7f3a
smtpSMTP sink
“Ana invited you to Acme” → bob@acme.test
authOIDC issuer
ana@acme.test · bob@acme.test · eve@acme.test
secretsOpenBao · write-only
6 keys · ••••••••
egressSNI allowlist
upload.exfil-drop.net · blocked
tokeninherited RBAC
hugo@acme.com · scope: claude-1
Agents

Your agents test their work end to end

Every console action is also a parity CLI command and an MCP tool. Your agents sign in as test users, read the email your app sends, and hand you work that has already run against your full stack.

claude-1 · feature/team-invitesSandbox token
$ parity up
✓ web, worker built from feature/team-invites
✓ postgres 16 · migrated
✓ ready https://web--team-invites--acme.env.parity.ninja
$ parity auth user create ana@acme.test --org acme --role admin
$ parity signin ana@acme.test
$ parity inbox wait --to bob@ --subject "invited"
{"subject": "Ana invited you to Acme", "links": ["https://…/accept?t=…"]}
Built-ins

The whole stack, per agent

Each of your agents runs your entire application with its own copy of every built-in, in its own namespace, with no network route to other agents or to production. Data comes from your seed job, never from production.

  • Postgres
    non-superuser · pgvectorDATABASE_URL
  • Redis
    7.4 · own instanceREDIS_URL
  • S3
    S3 API · bucket per sandboxAWS_ENDPOINT_URL_S3
  • ClickHouse
    26.8 · own instanceCLICKHOUSE_URL
  • SMTP
    SMTP sink · inbox APISMTP_URL
  • Auth
    OIDC issuer · test personasOIDC_ISSUER
Comparison

Beyond preview deploys and database branches

Database branches and preview deploys give an agent one part of your stack. Per‑PR environments run all of it, with your team's network access and credentials. A Parity sandbox runs all of it behind an egress allowlist, with a token scoped to the sandbox and a promote review before production.

ApplicationDatabase branchNot includedPreview deployWeb frontend and functionsPer‑PR environmentEvery serviceParity sandboxEvery service, worker and job
PostgresDatabase branchCopy-on-write branchPreview deployShared staging databasePer‑PR environmentOwn instanceParity sandboxOwn instance, migrated and seeded
Redis, S3, SMTP, AuthDatabase branchNot includedPreview deployShared with stagingPer‑PR environmentConfigured per providerParity sandboxOwn instance of each
Outbound networkDatabase branchNot includedPreview deployUnrestrictedPer‑PR environmentUnrestrictedParity sandboxAllowlisted by host name, blocked hosts reported
Agent credentialsDatabase branchDatabase passwordPreview deployProject-wide tokenPer‑PR environmentProject-wide tokenParity sandboxToken scoped to one sandbox
Agent testingDatabase branchNot includedPreview deployNot includedPer‑PR environmentBring your ownParity sandboxTest users, inbox API, CLI and MCP
Path to productionDatabase branchMigrations run separatelyPreview deployPromote the deploymentPer‑PR environmentSeparate production deployParity sandboxPromote review with checks

Typical setups; capabilities vary by provider.

Runtime

Kubernetes underneath, one file on top

You describe your application once in parity.yaml. Parity runs it on Kubernetes, with every environment in its own namespace behind a default-deny network policy, and supplies the right values for sandbox, staging and production. Sandbox Postgres matches production's version, extensions and role, so a migration that would fail in production fails in the sandbox first.

parity.yamlYAML
version: 1
project: shop
 
managed:
  db:    { type: postgres }
  cache: { type: redis }
  mail:  { type: email }
 
externals:
  stripe: { hosts: [api.stripe.com] }
 
env_groups:
  common:
    APP_URL: ${web.public_url}
 
services:
  web:
    build: .
    env_from: [common]
    depends_on: [db, cache, mail]
    externals: [stripe]
  worker:
    build: { from: web }
    command: npm run worker
 
jobs:
  migrate:
    service: web
    command: npm run migrate
    on: deploy
DATABASE_URL3 environments
sandbox
postgres://app@db:5432/shop
staging
postgres://app@shop-staging.db.internal:5432/shop
production
postgres://app@shop.db.internal:5432/shop
APP_URL3 environments
sandbox
https://web--team-invites--acme.env.parity.ninja
staging
https://staging.shop.example.com
production
https://shop.example.com
Namespace per environment
Each sandbox, staging and production get their own namespace, workloads and credentials.
Default-deny network
Traffic between environments is denied unless you route it.
Service discovery
Services reach each other and the built-ins by name. Parity sets each environment's connection strings.
Certificates and DNS
Every service you route gets a hostname and a TLS certificate, from sandbox to production.
Builds

From branch to production

Every merge to main ships to staging. When you promote a service, production runs exactly what staging ran, and a rollback redeploys the previous release.

  1. 01
    branchparity up
  2. 02
    sandboxper agent
  3. 03
    stagingon merge
  4. 04
    productionon promote
console.parity.ninja/acme/projects/shop/promote
The promote review in the Parity console: configuration and database changes for web and api, with checks before promoting to production.
Configuration
Every parity.yaml change, by file and by service, including the files it includes.
Database
Migrations already applied on staging, with the tables they change.
Checks
A secret missing in production blocks the promote. New egress hosts are flagged for review.
Security

Security and access control

  • 01

    Scoped credentials

    Sandbox tokens are short-lived and reach only their own sandbox: they can't promote, change staging or production, or widen the egress allowlist. Agents can't read secret values, connect to the production database or exec into production.

  • 02

    Secrets management

    Encrypted at rest in OpenBao and injected at runtime. Staging and production values never reach a sandbox, and the API never returns a secret value to an agent.

  • 03

    Egress control

    Outbound traffic passes an egress proxy that allows only the host names in your reviewed parity.yaml; network policy drops everything else. Every request by host name is logged by service, host and verdict, and new hosts are flagged in the promote review.

  • 04

    Audit logging

    Every API and MCP call is recorded with the person and, for agents, the agent acting for them. If the record can't be written, the change is refused.

  • 05

    Single sign-on

    SAML and OIDC with any identity provider. SCIM keeps users and groups in sync.

  • 06

    Role-based access control

    Granular permissions per project and environment, mapped from identity provider groups. An agent never exceeds the permissions of the person it acts for.

Get started with Parity

Parity is in early access. Leave your details and we'll schedule a technical walkthrough and set up your organization.

Early access