sigMAX can publish application APIs and generated frontends through a Traefik reverse proxy, configure HTTPS certificates, delegate authentication to Authentik and provide WireGuard access. These services surround the execution runtime: a WASM module receives declared inputs and capabilities rather than configuring its own public listener.

The operations below are implemented in the current Studio generators and container topology. Core places Host and Config on the same machine with Docker Compose. Pro uses Kubernetes and the COS2000 executor in KubeVirt VMs. The inspected networking code operates containers through the Docker/Podman Engine API; it does not establish a complete Kubernetes ingress or KubeVirt deployment package.

Traefik is the application reverse proxy.

Routing combines a hostname with PathPrefix. Longer prefixes receive higher priority. A component published under an additional prefix can use stripPrefix; if its own routes already include that prefix, the generator preserves it. Application and module mappings can use replacePath to reach the declared backend route. A frontend mounted below a prefix can strip that mount prefix before forwarding.

For example, a component whose own endpoint is /orders can be published below /api: the public request /api/orders reaches /orders in the component. When the component already owns /api/orders, the generator can preserve that path instead.

The ingress runtime watches generated configuration and atomically replaces its dynamic Traefik file. Changes to routers and middleware can therefore reload while Traefik is running. Certificate resolvers and entry points belong to its startup configuration and require a restart when changed.

HTTPS configuration requires an ACME email address. DNS credentials are stored through the project’s private-object mechanism and injected into the ingress container for the selected providers. DNS records, reachable challenge endpoints and valid provider credentials still determine whether certificate issuance succeeds.

The inspected generator has no selectable self-signed HTTPS mode or custom certificate upload workflow. Authentik’s blueprint does reference its self-signed certificate for OIDC token signing; that is separate from the browser-facing TLS certificate managed by Traefik.

In the current topology, a component started while the project’s Traefik container is running has no direct host port binding. Requests reach it over the runtime network through the proxy. Without Traefik, component startup publishes its runtime port on the host. This choice happens when the component starts; starting Traefik later does not rewrite an already running component’s port bindings.

The generated frontend remains on the private runtime network. PostgreSQL, MinIO, the storage adapter, the file adapter and the application Redis cache also use that network rather than public application routes.

These are exposure choices, not a separate VM boundary. Core still runs WASM inside the containerized runtime without the dedicated execution isolation provided by Pro’s COS2000 VM architecture.

The Authentik integration generates provider configuration and starts an Authentik server and worker with PostgreSQL storage. Traefik calls the Authentik outpost through ForwardAuth before forwarding protected application requests. When this integration is enabled, generated routes are protected except for Authentik itself and the outpost callback routes.

The runtime maps Authentik groups to roles and entitlements to permissions when trusted identity headers are enabled. It exposes only allowed claims and prevents raw authorization, cookie and identity headers from becoming ordinary declared request-header inputs for WASM.

This integration relies on the trusted proxy path. The current Rust runtime requires identity context when configured by Studio; it does not independently validate an Authentik JWT simply because the generated manifest includes an issuer and JWKS URL. Backend reachability and header trust must match that deployment model.

The generated blueprint does not contain user passwords, administrator tokens or the resulting service-token keys. Starting the containers creates the provider services and a persistent secret key, but does not prove that initial administrator setup, user credential enrollment or application role policies are complete. Those steps belong to the Authentik configuration used for the deployment.

The WireGuard extension manages a wg-easy runtime and client profiles. Studio can configure the public endpoint, UDP port, server address, DNS servers, allowed IP ranges and keepalive, then add, inspect and remove clients. Client configuration files and QR codes are available for enrollment.

The topology publishes the configured VPN UDP port and binds the administration port to loopback. The runtime uses a persistent configuration volume, /dev/net/tun and the networking capabilities needed by WireGuard. Its ability to start depends on the host’s tunnel support and permissions.

WireGuard supplies a network access path. Application routes, authentication and authorization still determine which operations a connected client can use.

There are three distinct web services in the inspected implementation:

Nginx is therefore a real reverse proxy for Studio. It is not the WASM executor, and the application publishing path inspected here uses Traefik.

This page follows studio/apps/worker/src/stages.ts, studio/apps/ingress-runtime/src/index.ts, studio/apps/api/src/services/ingresses.ts, studio/apps/api/src/services/authentik.ts, studio/apps/api/src/services/wireguard.ts, studio/apps/topology/src/docker.ts, studio/apps/topology/src/runtime-port.ts, studio/nginx/studio.conf and runtime/src/main.rs in sigMAX_runtime.

See also file storage, database storage and observability.