Deployment manifests & release workflows

Connect hosts, deployment and backing services

This selected Wonder Todos staging configuration retains its actual public helpers and values. Additional provider, backing-service, logging and CSP settings are omitted.

import {
  defineInfraEnvConfig,
  WildoEnvironment,
  WildoDeploymentRuntime,
  WildoLocationType,
  BackingServiceSource,
} from '@wildo-ai/platform-config-lib';
import { RuntimeEnvironment } from '@wildo-ai/saas-models';

export default defineInfraEnvConfig({
  environment: WildoEnvironment.STAGING,
  locationType: WildoLocationType.REMOTE,
  runtime: WildoDeploymentRuntime.DOCKER_COMPOSE,
  runtimeEnvironment: RuntimeEnvironment.STAGING,
  publicDomain: 'staging.wonder-todos.com',
  serviceHosts: {
    app: 'app', docs: 'docs', website: '',
  },
  deployment: {
    branch: 'staging',
    runtime: WildoDeploymentRuntime.DOCKER_COMPOSE,
  },
  backingServices: {
    mongodb: { source: BackingServiceSource.MANAGED, provider: 'atlas' },
    redis: { source: BackingServiceSource.SELF },
  },
});

website: '' selects the domain apex. The application and documentation receive their own host labels. These choices must agree with browser origins, reverse-proxy routing and deployment configuration.

Distinguish selection from provisioning

A managed backing-service entry chooses an external dependency. It is not proof that an account or database has been created. A self-hosted selection informs service composition; it still needs appropriate storage, credentials and operations.

The platform database and the application’s database are separate configuration choices. Changing a database selection does not migrate or transfer existing data.

Verify the environment as a connected whole

Inspect public URLs, internal service endpoints and the target runtime together. Check that each service reaches the intended environment’s dependencies and that its public links do not lead into another environment.

Recognize the output for each runtime

The generator writes under .wildo-saas/deploy/<environment>/k8s/ or compose/. Kubernetes output includes workload and service definitions, per-host routing and target-specific secret resources. Workers receive their service interface; minions are supporting process workloads.

Self-hosted backing-service population follows configuration. A managed selection does not require a duplicate self-hosted container solely to occupy the same category.

Inspect a concrete workload contract

The following selected Kubernetes frontend template excerpt preserves the source’s security, port and resource settings. Template image variables are intentionally shown: this is source input to rendering, not an already rendered manifest. Writable mounts and probes are omitted here.

- name: frontend
  image: {{imageRegistry}}/{{serviceName}}:{{imageTag}}
  imagePullPolicy: {{default imagePullPolicy 'Always'}}
  securityContext:
    allowPrivilegeEscalation: false
    readOnlyRootFilesystem: true
    capabilities:
      drop:
        - ALL
  ports:
    - name: http
      containerPort: 80
      protocol: TCP
  resources:
    requests:
      cpu: "50m"
      memory: "64Mi"
    limits:
      cpu: "250m"
      memory: "128Mi"

The static frontend has its own resource profile and HTTP probes in the full template. These settings are a workload contract, not a description of every backend or worker container.

Review secrets without turning them into source assets

The generator separates secret resources and adds an ignore-all file to its output directory. Kubernetes base64 encoding is not encryption. Limit access to rendered output and use the intended secret-delivery process for the target environment.

Check that the image actually used, the service port, writable mounts and probes agree. A syntactically valid workload can still reference an unavailable image or an incorrect endpoint.

Inspect the generated workflow

The workflow generator writes .github/workflows/deploy-<environment>.yml from deployment configuration and the application’s service Dockerfiles.

There is no general wildo deploy command behind this description. Inspect the actual generated workflow rather than assuming both runtime paths perform the same remote operation.

Keep the image being built and the image being deployed aligned

The CI workflow and manifest renderer have distinct image-tag inputs. The current config-sync call does not supply the renderer’s optional imageTag, so do not assume that generated manifests are pinned to the CI commit merely because the workflow builds a commit-tagged image.

Review emitted image references against the images pushed for that release. Treat a successful image build and a correct deployed image as separate checks.

Separate offline validation from runtime acceptance

wildo config validate --env production --domain manifest --deployment-artifacts

This validates persisted application YAML without deploying. Cluster admission, rollout readiness, application health and recovery remain target-runtime checks. Include the intended backing-service access and a representative authenticated operation in release acceptance.

Read Docker or Kubernetes for the runtime mechanisms and managed backing services for the dependencies around the application.