Managed deployment
Redgold operates the build, publication and deployment path for your managed application. You define the expected behavior and review the change under your account's approval policy. The platform carries the approved schema, pipeline, transform and supporting artifacts into the managed runtime.
Application and environment provisioning are coordinated during onboarding. Fully managed deployment does not require the customer to operate Kubernetes, a registry or a deployment controller. The configured repository, environment, domain and status surface identify where the application is delivered.
From source to a running revision
flowchart LR
Change[Reviewed application change] --> Checks[Required checks]
Checks --> Publish[Versioned artifacts and route publication]
Publish --> Desired[Git-backed desired deployment state]
Desired --> Reconcile[Managed runtime reconciliation]
Reconcile --> Verify[Revision and application smoke check]
| Boundary | What happens | What the result establishes |
|---|---|---|
| Review | Evaluate schemas, pipelines, transforms and tests together | The application behavior is approved |
| Checks | Validate the affected contract and implementation | The checked revision passed the required checks |
| Publication | Publish the affected versioned artifacts and route definitions | The runtime can obtain the approved artifacts |
| Desired state | Generate deployment configuration in Git | The intended environment revision is recorded |
| Reconciliation | Deployment controllers apply that desired state | The runtime is converging on the requested revision |
| Verification | Inspect revision and exercise the application | The intended behavior reached the target environment |
Underlying service builds publish container images; pipeline and transform publication follows the affected artifact path. A pipeline edit does not imply a new standalone service for that application. Kubernetes and ArgoCD provide the managed reconciliation layer, while the customer works with the application contract and its delivery evidence.
Verify behavior as well as health
For the support-triage example, a healthy rollout is only the first check. Send the committed support-request fixture and compare its returned category and priority with the expected values. If the change concerns persistence or retry behavior, include an authorized read or duplicate-submission check.
Keep the approved revision, required check results, deployed revision and smoke result together on the delivery issue. A merged pull request alone does not prove the application was published. A successful health check alone does not prove the new business behavior is correct.
Recover at the failed stage
If checks fail, correct and re-review the source change. If publication or reconciliation fails, Redgold investigates that stage using the intended revision. If the expected revision is live but acceptance fails, capture the smallest sanitized reproduction and review the application contract.
A rollback also needs compatibility review: reverting code does not automatically undo stored records or external effects. Keep schema evolution and application retry semantics explicit so recovery preserves the intended data behavior. The supervision guide describes the corresponding issue and agent decisions.
External repositories and services
Agents can work on external repositories with their existing CI and deployment systems. Those releases follow the external repository's policy unless managed Redgold deployment was explicitly configured. A managed application can also call an authorized external service; publishing the application does not deploy or manage that service itself.
Follow the application workstream for the full customer workflow, or verify a managed deployment for the delivery checklist.
Local evaluation sandbox
To evaluate the request path on a single machine without the cluster, there is a docker-compose sandbox at resources/self/selfhost/compose/. It runs the minimal path — postgres, the engine (data-engine-service), the dynamic-transport-service edge, and the dataflow-executor — from the same images CI publishes, resolving credentials from a local .env. This is the sanctioned local exception to the GitOps-only deploy path: a generated compose artifact for a desktop or laptop, not a cluster deployment.
It is for evaluating the request path, not parity — there is no ArgoCD, secret manager, cold-tier storage, observability, or identity provider in the sandbox. Bring it up with ./smoke.sh (bounded, self-terminating) and see that directory's README.md for the quickstart, the manual smoke recipe, and what is degraded versus a cluster deployment.