Choose where each service runs
Your database does not have to be hosted in the same way as your queue or file storage. Wildo separates a service’s role from its hosting model, so supported local and managed choices can be made per environment.
The application uses the resolved connection. You choose the provider, supply its operating authority and plan any data migration when changing services.
Example — Use a managed database with a self-hosted broker
An environment can select MongoDB Atlas for records and retain RabbitMQ inside its own stack. Each keeps its own configuration and credential path; the application does not need vendor-specific hosting decisions scattered through its business operations.
For engineers
Keep hosting and brand separate
This is a configuration fragment using the current schema, adapted from the production environment. Add it to the selected environment’s backingServices; account details and secrets remain outside this excerpt.
backingServices: {
mongodb: {
source: BackingServiceSource.MANAGED,
provider: 'atlas',
database: 'application-records',
},
rabbitmq: {
source: BackingServiceSource.SELF,
vhost: 'application-work',
},
}
source selects the hosting model. provider selects a brand recognized by the provider resolver. The declaration does not create a vendor account or migrate data. Provider provisioning uses the operator authority available to the selected environment, and runtime delivery uses the generated application credentials.
Check the actual provider resolution
| Kind | Current managed resolution |
|---|---|
| PostgreSQL | Named RDS, Cloud SQL, Azure, Supabase, Neon or Render entries; generic managed fallback |
| MongoDB | atlas |
| S3 | Recognized minio and aws brands resolve first, independent of source; otherwise source selects AWS for managed and MinIO for self-hosted |
| Redis, RabbitMQ, ClamAV, immudb | No managed provider in this resolver |
PostgreSQL’s unrecognized brand falls back to its generic managed entry. S3 dispatches recognized brands first and otherwise falls back by source. MongoDB has no generic managed fallback. Resolving a name is not the same as being served: see the next section.
Check what can actually execute
A resolved provider name describes a selection; it does not prove that a provisioning implementation exists. So a declaration is accepted only when it resolves to a provider AND a provider module can serve it. wildo config validate, wildo config sync and wildo lock check refuse anything else with one shared check, naming the environment, the kind, what was declared and what that kind can be declared as instead. Today the servable managed choice is MongoDB Atlas; every other kind is declared self-hosted.
| Layer | What to verify |
|---|---|
| Accepted declaration | The service fields and hosting/provider combination pass their schema |
| Resolved provider | The resolver selects the intended provider enum |
| Executable module | A registered module implements the operations needed, such as planning, provisioning or credential minting |
| Operator-supplied connection | The selected runtime receives a compatible address and credentials when infrastructure is supplied externally |
| Runtime authority | The application’s delivered credential has the required scope and the service is reachable |
The built-in provider catalog currently has a self-hosted PostgreSQL module, but no modules for its managed PostgreSQL enum entries, and its AWS S3 module cannot yet deliver a credential. Those declarations are refused rather than recorded: those names are not a claim that Wildo provisions RDS, Cloud SQL, Neon, AWS S3 or the other listed offerings.
Separate provider resolution from workload selection
The local workload policy is shared by Compose and Kubernetes. An explicit managed cache, broker or S3 choice would suppress those local workloads; while no module serves them, such a choice is refused before any stack is generated. Omission retains their baseline local workloads. This distinction matters: removing a container does not prove a replacement was provisioned.
Before changing a hosting choice, check the provider connection, runtime credential, generated deployment and existing data separately. The common application contract reduces hosting-specific code; it does not remove service compatibility or migration work.