Bring the supporting services together
Application behavior depends on services around it: a database for records, a cache for shared state, a broker for background work and object storage for files. Wildo brings their declarations, connection details and deployment inputs into one environment model.
Select the services your environment needs. Their templates carry operational details such as storage mounts and health checks, while you own the hosting and operating policy.
Example — Support records, background work and attachments
A task application stores records in PostgreSQL, sends work through RabbitMQ and keeps attachments in S3-compatible storage. These are different service roles, described together so their connections can be generated for the processes that use them.
For engineers
Declare a meaningful set
Adapted from the current local environment, this block belongs inside defineInfraEnvConfig. The imports and other environment fields are omitted here; BackingServiceSource comes from @wildo-ai/platform-config-lib.
backingServices: {
postgresql: {
source: BackingServiceSource.SELF,
host: 'localhost', port: 5432, database: 'wonder-todos-db',
},
rabbitmq: {
source: BackingServiceSource.SELF,
host: 'localhost', port: 5672, vhost: 'wonder-todos',
},
s3: {
source: BackingServiceSource.SELF, provider: 'minio',
endpoint: 'http://localhost:9000', bucket: 'wonder-todos-local',
},
}
The database name, broker virtual host and storage bucket identify different namespaces. The backing-service kind maps to an infrastructure capability; the runtime’s grants determine which connection material it receives. A declaration and permission to use that service are connected decisions, not the same decision.
Understand which workloads are emitted
Both Compose and Kubernetes consult selfHostsBackingService. The current omission policy is deliberate:
| Service family | Local-workload selection |
|---|---|
| MongoDB and PostgreSQL | Combines backing-service declarations with the platform database selection |
| Redis, RabbitMQ and S3 | Explicit managed selection removes the local workload; omission retains the baseline service |
| ClamAV and immudb | Requires explicit self-hosted selection |
| Backup | No workload is emitted |
MongoDB’s search process follows its database’s selection. Document rendering and telemetry are not additional backing-service kinds: their configuration has its own provider/runtime path. Do not add invented gotenberg or metrics keys to this block.
Follow the generated result
The Compose generator passes inclusion flags, host ports, internal ports, networks and data paths into the platform template. Stateful service directories follow the same selection. Kubernetes derives its workload list from the same self-hosting policy, then applies its own manifest and readiness mechanics.
Generation does not establish that credentials work or that a service has started. Inspect the resolved provider, generated workload and runtime diagnosis as separate steps. The backup declaration has no concrete provider; it must not be interpreted as a backup or restore service.