sigMAX Studio is the graphical interface for managing sigMAX applications and their projects. It is not a third edition. The two proprietary editions are Core and Pro.

This page retains its historical address so existing links continue to work.

The inspected runtime repository contains a Studio UI, API and workers for generation, compilation and topology operations. These tools make contracts, generated artifacts and execution status inspectable.

The repository currently implements container topology operations through the Docker Engine API. A Kubernetes option in the interface is not evidence that the Pro deployment integration has been delivered.

Studio organizes application, component, binary and extension stages as a dependency graph. Independent branches can run concurrently; resource locks serialize operations that share a workspace. Jobs expose status, attempts, logs and links to their artifacts. Failed runs can be resumed, and individual tasks can be relaunched when their dependencies permit it.

Agreements record contract and artifact digests, compilation results and validation evidence. Component API tests execute real scenarios; their evidence is tied to the tested script. Unresolved natural-language criteria remain pending instead of being reported as passed. See generation and agreements.

Each project has a versioned MinIO artifact store. Selecting a project hydrates its working cache; completed generation stages persist changed artifacts. Studio provides file inspection, versions and project snapshots, including restoration with a pre-restore snapshot and audit information.

Application data has separate tools: PostgreSQL database and schema inspection, migrations, row previews, named MinIO buckets and file operations. A project artifact snapshot is not a backup of the application’s PostgreSQL database.

With a configured LLM, Studio can propose a relational schema and initialization SQL, draft sample rows, or prepare a component from selected table fields and reusable database operations. Schema and seed proposals have a separate apply action; component proposals enter the application-contract workflow.

Database storage · Files and project snapshots

Projects select infrastructure extents from the capability catalog. Studio exposes their configuration and lifecycle: database and file services, Traefik, Redis, Authentik, WireGuard, monitoring and the frontend.

The topology views provide application container state and logs. The monitoring interface displays collected resource data; the ingress and identity views configure domains, routes, certificates, users and service access. These operations depend on the selected extensions and their running services.

The frontend workspace manages the site’s identity, language, selected ingress URL, logo and hero image, configuration and pages. Markdown pages can be created, edited and deleted, with menu metadata maintained by the authoring service.

Reusable Svelte components can be inspected, edited, compiled and synchronized with the configured source. Frontend operations include source synchronization, build, cleanup, tests and runtime start/stop. The frontend is published behind its declared Traefik route.

This connects FrontMark content to an application’s interface while keeping frontend build work separate from WASM business execution.

Studio presents and operates project information. The edition determines where execution takes place: in the containerized runtime on Core’s shared host, or in a COS2000 VM under KubeVirt for Pro.

Studio is also distinct from an application’s generated frontend and from FrontMark, the Markdown documentation format used by this site.

Core deployment Pro deployment Explore all platform capabilities