Deployment
di-framework supports applications deployed to Cloud Foundry and applications compiled to WebAssembly components for the platform. Choose the integration that matches the target runtime:
Target | Integration | Use it for |
|---|---|---|
| Discover | |
| Classify Worker bindings, read wrangler declarations, and inject them through the DI container. | |
| Build a di-framework HTTP application as a WASI 0.3 component, develop locally, and deploy from a workspace | |
| Create a local Kubesolo cluster with the wasmCloud operator and verify deployed apps against PostgreSQL, Redis, NATS, configuration, secrets, and HTTP services. | |
| Run isolated copies of the platform as |
The Cloud Foundry package configures an application at runtime; the platform CLI and manifest remain responsible for pushing it. The platform 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 platform cluster lifecycle of a managed target and for kube platform provisioning.
Both platform entrypoints use @di-framework/platform 6.x from di-framework/platform. The extension's local entrypoint provisions Docker or Podman/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 links DI Framework 6 with @di-framework/bindings and @di-framework/cli-plugin-platform (di-framework platform deploy). See native service bindings for the build and runtime contract.
Platform backing services let tenant developers create BackingService resources with platform service for Redis, NATS, blobstore, dedicated PostgreSQL, and egress. platform deploy wires PostgreSQL through serviceName and, on tenant targets, egress through allowedIpNameLookups. Blobstore uses configFrom, not serviceName; Redis and NATS use explicit ServiceBinding resources. Those capabilities are in published @di-framework/platform 6.0.7. di-framework-kube still installs 6.0.2 unless you pass --platform-package.
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.
One-command local platform example
platform-examples deploys the Meshtastic collector and site with one pulumi up. Install Bun, Pulumi, Docker or Podman, and the framework CLI with the locally built platform extension containing this work. From an examples checkout:
bun install creates stack dev in deploy/.pulumi-state and records containerCli. pulumi up starts k0s and the registry, builds deploy/tenant-host locally (wash 2.8.0 plus wasi-tls), creates tenant meshtastic and user dev, approves MQTT egress, provisions the shared mesh-objects blobstore, writes the tenant kubeconfig, and deploys both services. The first host-image build compiles wash and can take about ten minutes. This example vendors @di-framework/platform 6.0.2 and pushes its own host image into the cluster registry. Other installs use published @di-framework/platform 6.0.7 and the default wasi-tls host image.
meshSiteUrl is http://mesh-site.meshtastic.localhost:28180/. The console command prints its loopback URL on a free port. Re-running pulumi up redeploys changed sources; pulumi destroy removes the cluster, volumes, network, and generated kubeconfigs.
Next steps
Cloud Foundry - Connect an application to platform metadata and bound services
Cloudflare Workers - Inject Worker bindings through the DI container
Platform - Build and deploy WebAssembly components
Platform backing services - Request Redis, NATS, blobstore, PostgreSQL, and egress services
Kubernetes with di-framework-kube - Deploy examples and verify real service bindings
Private service bindings - Named in-process contracts without URLs
Remote actors - Cross-process actor RPC independent of wasmCloud
Platform actors - Single-host actor workloads and tenant or non-tenant storage
HTTP static assets - Live directory serving and host-side packaging
CLI - Install extensions and use the canonical command tree