Containers to Components
If you use desktop container tools like Docker Desktop, you should feel at home with Cosmonic Desktop: a dashboard app that integrates with a local runtime, which in turn pulls artifacts from registries and runs them as managed workloads. This page maps container concepts onto their Cosmonic Desktop equivalents—and highlights where we do things differently.
The mapping
| Container concept | Component concept | What's different |
|---|---|---|
| Container image | Wasm component | Both are OCI artifacts—components come from the same registries you already use (and are typically far smaller). |
| Container | Workload | Workloads are declaratively specified groups of one or more components. |
| Dockerfile build | Component build | Paste a GitHub/GitLab repo URL and let Desktop draft the workload; project scaffolding with a watch-rebuild-restart loop is available under Settings → Labs. |
| Compose file | Workload spec | Workload specs are plain YAML on disk (runtime.wasmcloud.dev/v1alpha1)—the same schema Cosmonic Control runs on Kubernetes, so the local spec deploys to a cluster unchanged. |
| The Dashboard | Desktop views | Workloads and Logs views over live daemon state, with more inventory views under Settings → Labs. |
| Docker Hub + registries | Any OCI registry | Registry credentials and mirrors are supported; images are digest-pinned at apply time. |
Published ports (-p) | Built-in HTTP ingress | HTTP workloads are served from one listener on 127.0.0.1:8200 (by default), routed by hostname—the workload's expanded row links straight to its address. |
| Volumes | hostPath volumes | Paths must already exist and be writable by your user—the runtime never creates them (details). |
| Environment variables for secrets | Secret references | Specs reference secrets in your OS keychain, 1Password, or AWS Secrets Manager; plaintext never appears in YAML, the API, the UI, or logs. |
| Docker Engine in a VM | cosmonicd daemon | A per-user daemon embedding the wasmCloud runtime—no virtual machine layer, and no TCP API socket to protect. |
| Kubernetes (bundled cluster) | Cosmonic Control | Rather than bundling a local cluster, Desktop shares its Workload spec with Control—your laptop workload is the cluster workload. |
What is different in Cosmonic Desktop?
Cosmonic Desktop assumes you're running code you didn't write line-by-line, so its defaults are set for untrusted code:
- Networking is fail-closed. A container typically starts with open outbound network access; a component workload starts with none. Every host it may call is allow-listed in its spec, per component. You see (and approve) a workload's reach before it runs.
- Verification is built in. Images are digest-pinned when applied and checked against a cosign signature policy on every start—strict signing can be required globally or per registry.
- The sandbox is the unit of isolation. Components run in WebAssembly sandboxes with capability-based access to the outside world—there is no shared kernel surface or privileged daemon socket for a compromised workload to reach for. The security model is the Principle of Least Authority, applied per workload.
What stays familiar
Your registries, OCI tooling, and usage patterns carry over: pull by reference, watch your workload start, read the logs, click through to details. The Quickstart has you running a component in a few minutes, and if anything surprises you along the way, Troubleshooting covers the common cases.