Deployment

di-framework supports applications deployed to Cloud Foundry and applications compiled to WebAssembly components for wasmCloud. Choose the integration that matches the target runtime:

The Cloud Foundry package configures an application at runtime; the platform CLI and manifest remain responsible for pushing it. The wasmCloud extension provides its build, development, application deploy and destroy, backing-service commands, and managed-platform commands through the main di-framework executable. Application deploy never runs Pulumi; Pulumi is used only for explicit wasmcloud platform lifecycle of a managed target and for kube platform provisioning.

Both platform entrypoints use the TypeScript @di-framework/platform package. The extension's local entrypoint provisions Docker/k0s and a registry; kube manages Kubesolo and invokes the shared existing-cluster entrypoint through its persistent Pulumi stack. Kube installs an exact published package version from npm by default; local tarballs are a development option. Its embedded Helm client remains for status inspection and legacy cleanup. Its example workspace uses an external deployment target and pins the framework to 5.3.0. Native services are consumed through @di-framework/wasmcloud; the platform and example helpers provision their backends and credentials. See native service bindings for the build and runtime contract.

In 5.3.6, wasmCloud backing services add independently requested Redis and NATS instances. Tenant developers create BackingService resources with wasmcloud service; the platform controller provisions them and projects Kubernetes ServiceBinding configuration. Automatic wiring into application deployments remains outside this release.

Application-authored private service bindings (@ExportService/@ServiceBinding) are a separate in-process contract: callers receive a named DI proxy and do not configure a URL. They are not wasmCloud host capabilities and are not mapped onto independently deployed components by the CLI.