Runtime & Infrastructure
Replica-sets, placement, volumes, networking, and the console
Runtime & Infrastructure
The runtime layer turns your deployments into running, healthy, networked replicas — and gives you the primitives (volumes, networks, console) to operate them.
Workloads and replicas
Each git/image/template service instance runs as a regional workload — a replica-set managed by Parslinks:
- Release = which immutable deployment the workload runs
- Placement = how many replicas per region (your declared intent in the catalog)
- Replica = an observed running member of that workload
At steady state a region may have N ready replicas. Historical deployments keep their image/artifact and frozen runtime spec even when nothing runs them.
Rollouts follow a strict order: materialize the new revision (rolling,
start-first — or stop-first recreate when a volume is attached), pass the health
gate (readyReplicas >= desired), repoint the alias, then drain old replicas.
On failure the alias never moves; existing healthy replicas keep serving.
Health checks
Probes run from outside your container image: HTTP or TCP health checks
configured on the service. A replica is only counted ready once it passes these
probes and appears in the platform endpoint's upstream list — running is not
ready.
Don't add HEALTHCHECK CMD curl … style directives to your Dockerfile for
Parslinks; they aren't used for readiness.
Volumes
A volume is a logical regional disk scoped to (project, environment, region, name) with RWO semantics: exactly one live consumer at a time.
- Attach/detach is not a deployment — it's a storage operation.
- Attaching forces single-replica in that region (
desiredReplicas = 1); the runtime reportsVOLUME_REPLICA_LOCKif intent conflicts. - Declared size is grow-only metadata; snapshots are crash-consistent tar/filesystem copies (adapter-managed databases may offer application-consistent dumps).
- Volumes survive service deletion by default; you choose whether deletion wipes them.
Networking model
| Layer | What it is |
|---|---|
| Project network | Bridge or overlay network all project containers share |
| Platform endpoint | The per-workload stable VIP; load-balances ready replicas only |
| Edge origin | The public entry point that maps Host → endpoint VIP |
Public TCP ports bind on the platform endpoint once, not per replica. Private
service-to-service DNS ({service}.{env}.internal) also targets the endpoint.
Console
Every replica has an interactive shell available from the dashboard — a managed PTY into that specific replica, gated behind project admin permissions. Sessions are time-limited (idle timeout 30 minutes, max session 4 hours).
Console sessions target the runtime replica identity, so what you see matches what serves traffic — including which revision is live.
Isolation
Customer workloads run untrusted: no Docker socket access, no cluster manager API, no privileged mode, and every container lives on a project-scoped network. Only the platform's labeled edge component can join multiple projects' networks.