Deployment and runtime

The concern: what exactly is deployed? Is the deployable unit a project, a workflow, a container, a server, a REST service? And can the customer build and run it themselves, with no dependency on the platform afterwards?

The short answer

The deployable unit is a container image per application service, built from a container definition and a source tree that belong to the project and are exported verbatim. A project is delivered as ordinary source: one directory per application service, a compose file, optional Kubernetes and Azure Container Apps definitions, a generated CI pipeline, a runbook and the tests. The customer builds the images in their own CI, runs them in their own network, and nothing in a delivered application authenticates against the platform, phones home or checks a licence. In place

Workflows, agents and pipelines are not deployable units. They are data executed by the engine runtime, and that runtime ships only when the delivery distributes a feature that needs it. By default a customer receives exactly the application.

The chain

Project→Generated source (application services)→Git repository→CI→Container images→Kubernetes, Container Apps or Compose in the customer's network→HTTP APIs and databases→The customer's systems

Stage	What it is	Standing
Project	Configuration rows in the project's database (sources, rules, requirements, declarations) plus the engine fork (endpoints, services, application services). While the platform hosts the project, every application service also runs on the platform's cluster at its own hostname.	In place
Generated source	The export writes every application service in its own directory with its container definition and source tree byte for byte, a service description (port, health path, route, dependencies, environment keys) and an example environment file. Secrets are blank in every committed file.	In place
Git repository	Every export is a commit. When git hosting is configured for the installation, every project gets a private repository at creation and every export is pushed to it; the same export can be pushed to a repository the customer designates.	In place
CI	The delivery options generate either a GitHub Actions workflow (a matrix over every container definition, images tagged with the commit, deploy jobs gated on repository variables) or an Azure Pipelines definition (a build-and-push matrix through a registry service connection, deploy stages gated on a service connection). The customer's existing CI can build the same container definitions with no change.	In place
Images	One image per application service, from its own container definition. No platform layer, no agent, no injected code.	In place
Deployment targets	Docker Compose (always), Kubernetes manifests (deployment with probes, persistent volume, cluster service, ingress for public HTTP services, an example secret, a kustomization), Azure Container Apps (templates with an external or internal ingress per service, secure parameters, probes, a deploy script).	In place
Integration with the customer's systems	Through the application's own HTTP surface and its own connection strings: an ordinary service in the network.	In place

The usual questions

What is in the container?

Exactly what the application service's container definition builds. Two shapes exist today:

A fleet-built browser application. A compiled browser bundle served by a small server that does three things: serves the bundle, proxies the application's data calls to the platform API for sign-in and data, and answers a health path. The server is a few dozen lines of ordinary code that ships in the tree and is versioned with it.
Any other runtime. The first production application service is a .NET identity service on an off-the-shelf OpenID Connect server, with a SQL Server development stand-in and a sample relying party. Java, Go and static-site services take the same contract: a port, a health path (or a plain TCP check), optional environment values.

The service manager does not know or care what is inside the image. It writes the tree to disk, runs the image build and starts the container with the project's environment only. Platform configuration and platform secrets are never mounted. In place

One container per project, service or workflow?

One container per application service. A project typically has one to three: the application, sometimes its own database as a development stand-in, sometimes a second service such as an identity provider. A workflow is never a container: it is rows in the project's relational database executed by the engine runtime. In place

The engine runtime itself is a set of containers that ships only when a distributed companion needs it: the endpoints runtime, the engine catalogue store, the cache, the versioned configuration store, a relational store with a seed step, and any function services the project owns. The operations pages and the agent chat are separate containers, again only when their companion is distributed.

What runtime libraries are included?

Whatever the application service's own dependency file names. The platform adds nothing to the image. The one optional touchpoint is the platform's application SDK, a single script tag an application includes if its owner wants the platform's side menu inside it; without the tag the application has no reference to the platform. In place

How do workflows invoke tools?

A workflow step is assigned to exactly one owner: a role, a person, an agent actor, or an endpoint step. An endpoint step calls a fork endpoint directly when the run reaches it. An agent actor step files a task; a worker claims it, runs the named agent with the step context, and the agent's tools are the endpoints its manifest names. The engine stamps the identity in whose name a step completes server-side; a browser never chooses it. Off the platform, workflows run when the Workflows companion is distributed, and agent actor steps additionally need the agent runtime and a model credential the customer supplies. In place on the platform; Partial in a delivery, because agent actors need a model credential.

How are agents represented?

As a manifest: an endpoint on the fork whose payload names the agent's display name, persona, model, tools (each a typed input contract plus the fork endpoint it calls) and safeguards. There is no agent code. At run time the assistant starts one headless agent process per turn or task in a fresh temporary directory with two files: the persona and an MCP configuration naming one server, the platform's internal agent endpoint, with an opaque handle that resolves server-side to the fork and the manifest. The process has no shell, file or web access. The model is named from the platform catalogue and translated by the environment's transport (a cloud provider's model service, an API-compatible gateway or a vendor API), so a manifest never names a vendor. In an export the manifest is source like every other endpoint. In place

How are APIs exposed?

Surface	Exposure
An application service's own HTTP API	Its own port, published at its own hostname behind the cluster's ingress on the platform, or however the customer publishes services in their network.
Project endpoints	Reached through one data call on the platform API that names the endpoint and an input, with the caller's verified identity merged in. In a delivery this call is served by the bundle's own operations API when the operations layer ships; an application with its own API does not use it.
The platform's own API and MCP	A REST API with an interactive reference per installation, and MCP endpoints per project behind OAuth 2.1. These are platform surfaces and are not part of a delivered application.

In place

Is the platform required after deployment?

No. With no companion distributed, the customer archive is the application services, the compose file, the environment files, the runbook, the tests service and the project's documentation pages. Nothing in it calls the platform. With a companion distributed, the archive carries the bundle's own copy of what that companion needs, still with no dependency on the platform. In place

Which components run independently?

Component	Runs on its own	Needs
An application service	Yes	Its own database or the systems its connection strings name
The tests service	Yes	The targets its specs name; a test whose fixture is absent is skipped with the reason, not failed
Workflows	With the engine runtime containers	The project's relational database, which holds definitions and runs
Agents in chat or on workflow steps	With the agent chat container	A model credential the customer holds
The operations pages (pipeline, governance, models, docs)	With the engine runtime and the portal containers	The versioned configuration store and the relational store in the bundle

How does the customer build and deploy the generated code?

From the repository, with the generated pipeline or their own: build every container definition, push to their registry, then start with Compose, apply the Kubernetes kustomization, or run the Container Apps deploy script. The runbook is generated from the same service definitions the platform ran (ports, health paths, environment keys per service with descriptions, start order, rollback steps), so it matches the version delivered. In place

What an export contains

Path	Contents
One directory per application service	The container definition, the source tree verbatim, the service description, the example environment file with descriptions and blank secrets
The compose file	One entry per application service, host ports bound to loopback only, an acyclic start order (mutual HTTP references are runtime facts, not start-order edges)
The Kubernetes directory (optional)	One manifest per service with deployment, cluster service, ingress and volume; an example environment secret per service; a kustomization; a README
The Container Apps directory (optional)	The templates, an example parameter file, a deploy script
The CI definition (optional)	GitHub Actions or Azure Pipelines
The tests directory	The requirement-linked tests and the dependency-free runner
The runbook and README	Generated: components, setup, deployment, health, support, rollback; every directory mapped to an action; no secret committed

Two hosting modes, one artefact

Mode	Where it runs	Who operates
Platform-hosted	The platform's Kubernetes cluster. Each application service is a deployment plus a cluster service plus an ingress in a shared load-balancer group, built in-cluster, published at its own hostname under the environment's applications domain or at a customer's own hostname with the customer's certificate.	The platform operator, while the project is being built and changed
Customer-hosted	The customer's network, from the export.	The customer, from the runbook

The images are the same. Moving from the first mode to the second is an export, not a rewrite.

Still to do

Item	Standing	Next step
Pushing the export to a repository the customer owns	In place The exporter pushes to any git remote with a credential; the remote is configured per project by the operator.	The customer names the repository and a deploy credential; every export lands there.
Building the delivered images inside the platform's own deployment namespace	To do Application services run on the platform through the service manager; the separate "deploy to the cluster" path rebuilds endpoints and screens but not application services.	Not needed where the customer builds; listed for completeness.
Events as an integration channel	Partial Workflows have listeners (mail, upload form, schedule, data condition); a message-queue listener is not built.	Add a queue listener kind when a requirement asks for it; the listener model is data, so it is one engine addition.