Core Deployment And Topology
Core Deployment And Topology
Section titled “Core Deployment And Topology”sigMAX Core deploys Host and Config on the same machine with Docker Compose. WASM business code executes inside the containerized runtime, without a dedicated VM execution boundary.
sigMAX Pro uses Kubernetes with the COS2000 executor inside a VM managed by KubeVirt. Both editions are proprietary; compare Core and Pro.
Product Packaging And Application Topology
Section titled “Product Packaging And Application Topology”Keep platform packaging, application topology and execution placement distinct.
| Concern | Meaning |
|---|---|
| Core packaging | Docker Compose runs Host and Config on the same host. |
| Generated application topology | Starts the components and technical services required by an application’s contracts. |
| Pro execution | Kubernetes deployment with COS2000 execution inside a KubeVirt VM. |
A Compose package for Core does not mean every generated application is driven by a generated Compose file.
Current Implementation
Section titled “Current Implementation”The inspected sigMAX_runtime repository uses Studio’s API, Redis-backed workers and a topology server. The topology server controls generated containers through the Docker Engine API; it also supports compatible Podman engines.
The violet double-border nodes are running control services. The green artifact and deployment nodes represent different outputs: having generated files does not establish that the containers are running.
The repository’s former Make-based generator and application Compose generation have been removed. There is no current tools/sigmaxgen/generate_compose.py or Compose skeleton to use as an installation reference.
Generated Services
Section titled “Generated Services”The topology starts component runtimes from generated images and supplies route metadata, host policy and internal service endpoints. Dapr sidecars provide internal calls where configured.
Technical services are selected through the application’s configured extensions. The implementation includes PostgreSQL, MinIO file storage, Traefik ingress, Redis cache, Authentik identity, WireGuard, monitoring and the FrontMark frontend. The capability catalog describes their dependencies. Their presence follows the declared application needs rather than a fixed stack shared by every project.
Generated files and their history persist in project-scoped MinIO storage. SIGMAX_GENERATED_ROOT provides a local materialization cache used by generation and image builds.
Exposure And Configuration
Section titled “Exposure And Configuration”Application ingress, internal sidecars, storage services and administration have different roles. The current topology omits a component’s host port binding when that component starts with the project’s Traefik container already running. Starting Traefik later does not alter an existing container’s bindings; see network exposure.
Route capabilities and host-owned configuration determine external access. Changing a container network does not authorize a WASM import, and adding a service does not automatically grant a handler access to it.
Evidence Before Execution
Section titled “Evidence Before Execution”The pipeline records contracts, generated sources, compiled modules and validation results in agreements. The topology then builds and starts the corresponding artifacts. Deployment success and contract validation are separate observations; both are needed when assessing a generated application.
The implementation references are sigMAX_runtime/README.md, studio/README.md and studio/apps/topology/src/docker.ts.