Deploy & Operate

New to Control Core? Start with Quick deploy — it takes you from zero to a working enforcement setup in 60 minutes using Docker Compose. This section covers everything beyond that first deployment: production configurations, Kubernetes and Helm, scaling, and multi-Bouncer topologies.

Control Core is customer-infrastructure only: the Control Plane and Bouncers run in your environment; policies, logs, and configuration stay under your operational and data-residency boundaries. Commercially, Kickstart is the 90-day trial path and Custom is the annual perpetual production path; packaging aligns to deployed Bouncers, while governance workflows for policy, security, compliance, and CIAM teams are not positioned as seat- or per-decision-metered. See Licensing and deployment options.

Control Core deploys as two customer-managed services:

1. Control Plane
2. Bouncer (deploy Sandbox first, then Production)

Distribution is managed directly by Control Core. Contact info@controlcore.io to request deployment artifacts.

Deployment topologies

1. Sidecar deployment

Use a Bouncer sidecar when you want workload-local interception with the smallest blast radius and the clearest ownership boundary.

• Best for Kubernetes services, internal APIs, and per-workload MCP or AI routes
• Keeps enforcement close to the protected resource
• Ideal when sandbox and production workloads are deployed separately
• Minimal touch when the OEM partner already deploys per-service workloads

Troubleshooting: If the sidecar is running but decisions are not enforcing, check the Bouncer registration and sync status in Settings -> PEPs and verify the workload is sending traffic through the sidecar listener. Common causes: wrong TARGET_HOST, missing API key, or policy sync not yet healthy. Full reference: /troubleshooting

2. Reverse proxy / AI Pilot deployment

Use a centralized Bouncer when multiple LLM, MCP, API, or agent routes should be governed from a shared ingress or gateway tier.

• Best for shared AI gateway patterns and centralized traffic management
• Lets platform teams apply controls without modifying each protected service
• Useful for prompt controls, MCP authorization, and cross-service audit visibility

Troubleshooting: If gateway traffic reaches the backend without policy effects, check the upstream host mapping and verify the gateway Bouncer is attached to the correct resource and environment. Common causes: host-header mismatch, route bypass, or a resource linked to the wrong environment. Full reference: /troubleshooting

3. Deep API embedding (OEM)

Use the headless OEM API when an external platform needs to generate, validate, test, and deploy controls entirely through API calls.

• Best for OEM platforms and agent-first parent systems
• Downstream tenants do not need access to the interactive Control Plane UI
• Works with workspace_id, source_metadata, and expires_at metadata for time-bounded access flows

OEM API-first lifecycle (recommended):

1. Bootstrap Control Core API access (/devdocs, token, environment API keys)
2. Register or verify bouncer/resource bindings
3. Run generate -> validate -> test -> deploy for each control intent
4. Verify readiness + decisions + audit evidence through APIs
5. Disable/archive/reactivate controls by lifecycle status as parent workflows change

Troubleshooting: If OEM-generated controls appear in the Control Plane but do not enforce, check the deployment environment, the target resource/bouncer binding, and whether expires_at has already elapsed. Common causes: deploying to the wrong environment, stale resource binding, or intentionally expired access windows. Full reference: /troubleshooting

For hardened multi-infra production standards, see:

• Production PBAC Blueprint
• OEM API-First Embedding

60-minute runbook

Required inputs

• CONTROL_PLANE_PUBLIC_URL (for example https://controlplane.customer-domain.com)
• TLS cert/key or ingress-managed TLS for the Control Plane domain
• DATABASE_URL and REDIS_URL
• GitHub controls repo URL, branch, and token
• Bouncer API keys for Sandbox and Production

Network and domain requirements

Use customer-owned DNS and TLS.

Recommended:

• No public database or Redis endpoints.
• Restrict ingress to required domains and paths.
• Allow outbound from Control Plane only to approved endpoints (GitHub, optional telemetry endpoint).

Helm deployment (recommended)

1. Extract deployment package.
2. Update values file with your environment.
3. Deploy chart.

helm upgrade --install controlcore ./controlcore \
  --namespace controlcore \
  --create-namespace \
  -f values.customer.yaml

Minimum values.customer.yaml pattern:

global:
  controlPlanePublicUrl: "https://controlplane.customer-domain.com"
  telemetryEndpoint: "https://business-admin.controlcore.io"

controlPlane:
  env:
    DATABASE_URL: "postgresql://<user>:<password>@<db-host>:5432/<db-name>"
    REDIS_URL: "redis://:<password>@<redis-host>:6379/0"
    SECRET_KEY: "<strong-random-secret>"
    JWT_SECRET_KEY: "<strong-random-jwt-secret>"
    GITHUB_REPO_URL: "https://github.com/<org>/<controls-repo>"
    GITHUB_BRANCH: "main"
    GITHUB_TOKEN: "<github-token>"

bouncer:
  enabled: true
  env:
    BOUNCER_ID: "bouncer-sandbox-01"
    BOUNCER_NAME: "Sandbox API Bouncer"
    BOUNCER_TYPE: "sidecar"
    ENVIRONMENT: "sandbox"
    PAP_API_URL: "https://controlplane.customer-domain.com"
    API_KEY: "<sandbox-api-key>"
    RESOURCE_NAME: "Customer API"
    RESOURCE_TYPE: "api"
    TARGET_HOST: "customer-api.default.svc.cluster.local:8080"
    ORIGINAL_HOST_URL: "https://api.customer-domain.com"
    SECURITY_POSTURE: "deny-all"

Docker Compose deployment

1. Extract deployment package.
2. Create .env.customer.
3. Start stack with your env file.

docker compose --env-file .env.customer -f controlcore-compose.yml up -d

Minimum .env.customer pattern:

CONTROL_PLANE_PUBLIC_URL=https://controlplane.customer-domain.com
DATABASE_URL=postgresql://<user>:<password>@<db-host>:5432/<db-name>
REDIS_URL=redis://:<password>@<redis-host>:6379/0
SECRET_KEY=<strong-random-secret>
JWT_SECRET_KEY=<strong-random-jwt-secret>

GITHUB_REPO_URL=https://github.com/<org>/<controls-repo>
GITHUB_BRANCH=main
GITHUB_TOKEN=<github-token>

BOUNCER_ID=bouncer-sandbox-01
BOUNCER_NAME=Sandbox API Bouncer
BOUNCER_TYPE=sidecar
ENVIRONMENT=sandbox
PAP_API_URL=https://controlplane.customer-domain.com
API_KEY=<sandbox-api-key>
RESOURCE_NAME=Customer API
RESOURCE_TYPE=api
TARGET_HOST=customer-api:8080
ORIGINAL_HOST_URL=https://api.customer-domain.com
SECURITY_POSTURE=deny-all

Bouncer resource auto-discovery parameters

These fields must be present for clean registration and linking:

• BOUNCER_ID unique per deployment unit
• BOUNCER_NAME human-readable label
• BOUNCER_TYPE (sidecar, reverse-proxy, or planned future type)
• ENVIRONMENT (sandbox or production)
• PAP_API_URL Control Plane API URL
• API_KEY environment-specific Bouncer key
• RESOURCE_NAME stable logical resource name
• RESOURCE_TYPE (api, webapp, database, ai-agent, mcp-server)
• TARGET_HOST internal service endpoint protected by Bouncer
• ORIGINAL_HOST_URL externally advertised endpoint
• SECURITY_POSTURE recommended deny-all

Use the same RESOURCE_NAME for Sandbox and Production counterparts when they represent the same business resource.

GitHub controls repository configuration

Control Plane requires:

• GITHUB_REPO_URL
• GITHUB_BRANCH
• GITHUB_TOKEN with least-privilege read/write scope for controls management

Operational checks:

1. Validate repo access from Control Plane runtime.
2. Validate branch exists and is protected per your policy.
3. Confirm controls sync status is healthy in the UI.

Security protocol baseline

• TLS 1.2+ for all external traffic.
• Customer-managed certificates and key rotation policy.
• Secrets from enterprise secret manager, not static files in repos.
• Environment-scoped API keys and scheduled rotation.
• Least-privilege IAM/RBAC for deployment and runtime identities.
• Backup and recovery policy for database and controls repository.

Verification checklist

1. Control Plane URL resolves and serves valid TLS cert.
2. Health endpoint is successful from your network zone.
3. Database and Redis connectivity checks pass.
4. Sandbox Bouncer appears in Settings -> PEPs.
5. Resource appears in Settings -> Resources with expected metadata.
6. A Sandbox control is enforced and audit events are visible.
7. /getting-started/wizard completes without failed checks.
8. GET /health/ready returns ready and GET /audit/export returns CSV evidence.

Support

• Documentation: Documentation Home
• General inquiries: info@controlcore.io
• Deployment and technical support: support@controlcore.io