Skip to main content

FAQ

Cosmonic Control is built on the open source foundations of wasmCloud, an Incubating project at the Cloud Native Computing Foundation (CNCF).

  • If you're new to wasmCloud, start with our questions on the wasmCloud ecosystem.
  • Explore common questions that platform operators and existing wasmCloud users may have about Cosmonic Control.

The wasmCloud Ecosystem​

What is wasmCloud and how is it different from other cloud platforms?​

wasmCloud is an open source project from the Cloud Native Computing Foundation (CNCF) that enables teams to build polyglot applications composed of reusable Wasm components and run them—resiliently and efficiently—across any cloud, Kubernetes, datacenter, or edge.

How does wasmCloud generate performance benefits?​

wasmCloud delivers superior performance through WebAssembly's near-native execution speed, instant cold starts, and efficient resource utilization. Components start in microseconds rather than seconds.

What are wasmCloud components used for?​

wasmCloud components are reusable, portable units of business logic that can run anywhere—from edge devices to cloud infrastructure—enabling truly distributed applications.

Is wasmCloud audited and secure?​

Yes, wasmCloud follows security best practices with capability-based security, sandboxed execution, and regular security audits. WebAssembly provides inherent isolation and security.

Which assets can I deploy into wasmCloud?​

You can deploy WebAssembly components written in any language that compiles to Wasm, including Rust, Go, JavaScript, Python, and more.

Cosmonic Control​

Can I use my wasmCloud components with Cosmonic Control?​

Yes, via the Component CRD.

Can I use wasmCloud capability providers with Cosmonic Control?​

Yes, via the Provider CRD.

Can I share a single external provider (i.e., not a built-in) with multiple tenants/applications in Cosmonic Control?​

Yes, Cosmonic Control supports shared providers and components. You can configure them with the Component CRD under imports and exports, and permissions are controlled by Kubernetes RBAC.

Does Cosmonic Control require wash? How do I interact with wasmCloud hosts?​

No. Cosmonic Control separates development and operation concerns and does not use wash for host interactions.

Users interact with Cosmonic Control in two ways: kubectl (Kubernetes API) and the Cosmonic Control Console (Web UI).

For example:

  • wash app list = kubectl get component
  • wash app deploy = kubectl apply
  • wash get inventory = kubectl get host
  • wash config = kubectl get config

This means wash continues to be part of the development lifecycle but no longer participates in operations.

How can I push local components/providers for use in my Cosmonic Control installation?​

Components and providers are pushed to registries like any other Kubernetes workload. Push the artifact to an OCI registry with wash, wkg, or oras, then deploy the desired manifest.

How do Kubernetes Ingress Controllers work with Cosmonic Control?​

Point the Ingress/HTTPRoute to the HostGroup hosting the HTTP Server provider.

The HTTP Server provider can be dedicated or shared across multiple tenants.

We recommend using the wasmCloud HTTP Server Provider in host mode.

Here’s an example:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: wasmpay
spec:
  parentRefs:
    - group: gateway.networking.k8s.io
      kind: Gateway
      namespace: north-america
      name: gateway
      sectionName: https
  hostnames:
    - "wasmpay.na.demo.cosmonic.space" # match this hostname to your component
                                       # hostname configuration
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - group: ""
          kind: Service
          name: hostgroup-default     # match this with the provider hostgroup
          port: 9191                  # The port defined in the Provider
          weight: 1

How is Cosmonic Control backup different from wasmCloud OSS?​

You back up Cosmonic Control state along with your Kubernetes API Server backups (usually managed by the cloud provider). NATS is stateless.

When using wasmCloud OSS with the wasmCloud Operator, you have to backup both Kubernetes API Server and NATS state.

What is the complete process for backing up a Cosmonic Control deployment?​

You can back up Cosmonic Control state by copying the CRD state with kubectl get or with tools like Velero or kube-dump.

Can I deploy wasmCloud OSS manifests (wadm) to Cosmonic Control?​

No. wasmCloud OSS manifests bundle all application concerns under a single manifest (application) and Cosmonic Control has individual manifests for each deployable item (Component, Provider, Config, Link). A plugin for adapting wadm manifests to Cosmonic Control CRDs is forthcoming.

Are there any features present in wasmCloud OSS that are not present in Cosmonic Control?​

Yes. Cosmonic Control does not include:

  • Host Config Service:

    • Used to configure host labels & OCI credentials

    • Cosmonic Control aligns with Kubernetes and OCI credentials are configured on a per artifact basis ( imagePullSecrets ) and allows a global override for both pullSecrets and registry for air-gapped environments.

      global:
  image:
    registry: ghcr.io
    pullSecrets: []

  • Secrets Backend:

    • Used to configure wasmcloud:secrets
    • Cosmonic Control aligns with Kubernetes and can reference Secret objects. Users can pair Cosmonic Control with External Secrets for accessing over 40 different Secrets Providers.

  • Policy Service:

    • Used to allow/deny component invocations
    • Cosmonic Control relies on Kubernetes RBAC for controlling which Components/Providers can interact with each other.

Does Cosmonic Control store any state in NATS like wasmCloud OSS?​

No. Cosmonic Control state is stored in the Kubernetes API Server and uses NATS as a message bus only.

Does Cosmonic Control have the concept of “lattice” like wasmcloud OSS?​

No. In wasmCloud OSS all hosts belong to a given lattice and can only service that single lattice.

Cosmonic Control uses host labels for workload placement, allowing users to define their own bin-packing and tenant isolation boundaries.

Can I perform ad hoc invocations (e.g. wash call) against a Cosmonic Control installation?​

No. wash is a development tool and has no direct access to artifacts deployed to Cosmonic Control.

What if I'm not on Kubernetes?​

No problem. Cosmonic Control can be deployed standalone with a bundled and dedicated Kubernetes API server, so you can deploy your cluster wherever it is needed.

Does Cosmonic Control work on ARM machines?​

Yes.