Skip to content
ContractShield

Deployment Overview

ContractShield supports three deployment models. Choose based on your latency requirements and architecture.

Comparison

ModelLatencyComplexityUse Case
Embedded~1msLowSingle service, monolith
Sidecar~2-5msMediumKubernetes, microservices
Centralized~5-20msHighMulti-service, shared policies

The PDP runs inside your application process.

import { contractShield } from '@cshield/pep-express';


app.use(contractShield({
  contractsDir: './contracts',
}));

Pros:

  • Lowest latency
  • Simplest setup
  • No network dependencies

Cons:

  • Contracts bundled with app
  • Restart required for updates (unless using Pro hot-reload)

Sidecar

The PDP runs as a separate container alongside your app.

docker-compose.yml
services:
  api:
    image: your-api
    environment:
      - CONTRACTSHIELD_URL=http://pdp:8080


  pdp:
    image: contractshield/sidecar
    volumes:
      - ./contracts:/contracts
import { createClient } from '@cshield/client';


const shield = createClient({
  url: 'http://localhost:8080',
});


app.use(async (req, res, next) => {
  const decision = await shield.check(req);
  if (!decision.allowed) {
    return res.status(403).json(decision.error);
  }
  next();
});

Pros:

  • Update contracts without app restart
  • Consistent policies across languages
  • Better resource isolation

Cons:

  • Network latency
  • Additional container to manage

Centralized

A shared PDP service for multiple applications.

┌─────────┐     ┌─────────┐     ┌─────────┐
│  App A  │     │  App B  │     │  App C  │
└────┬────┘     └────┬────┘     └────┬────┘
     │               │               │
     └───────────────┼───────────────┘
                     │
              ┌──────┴──────┐
              │  Central    │
              │    PDP      │
              └─────────────┘

Pros:

  • Single source of truth
  • Centralized audit logs
  • Cross-service policies

Cons:

  • Single point of failure (needs HA)
  • Higher latency
  • More complex ops

Next Steps