Skip to content

Deployment model

Centiceps separates publication from deployment. Publication creates an immutable revision; deployment selects a revision for a named environment.

A deployment identifies:

  • the environment;
  • the target kind (api or shared-flow);
  • the target bundle name;
  • the immutable revision;
  • the actor and deployment time.

The control plane validates environment-scoped dependencies, records deployment intent in durable storage, and publishes an invalidation signal. Gateway pods receive the resulting runtime generation through the gateway backend.

Each gateway reports the generation it currently serves. Environment status compares deployment intent with the hashes reported by the gateway fleet.

Skew is an operational signal, not a readiness failure. A gateway that could not apply a candidate continues serving last-known-good configuration and remains available while operators investigate.

Rollback creates a new deployment that points the environment at a previous revision. It does not mutate or reconstruct the old artifact.

revision 10 ── deployed
revision 11 ── deployed
revision 12 ── failed apply on part of fleet
revision 10 ── selected by rollback

Run at least:

  • two gateway backend replicas over shared Postgres and Redis;
  • multiple gateway pods behind a readiness-aware load balancer;
  • durable Postgres storage and an explicit backup policy;
  • Redis configured for the failure modes required by quota, cache, and registry use;
  • one or more control-plane replicas, sized for administrative activity.

The Python sidecar is optional per gateway pod and is needed only when deployed bundles contain reachable Python callouts.