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 |
| Backup | No concrete provider |
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. Inspect the resolved infrastructure section of wildo-saas.lock.json after synchronization; a syntactically valid choice alone is not evidence of a supported provider.
Check what can actually execute
A resolved provider name and a lockfile entry describe a selection; neither proves that a provisioning implementation exists. The lockfile can record the authored selection even when no provider module contributes an executable plan.
| 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. Those names are not a claim that Wildo provisions RDS, Cloud SQL, Neon or the other listed offerings. This does not prevent using an externally supplied PostgreSQL connection; its configuration and operational responsibility remain separate.
Separate provider resolution from workload selection
The local workload policy is shared by Compose and Kubernetes. Explicit managed cache, broker or S3 choices suppress those local workloads, even though a managed cache or broker has no provider in the resolver above. 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.