How it works
Compose and Helm run the services in containers. The appliance runs the application services under systemd. All three include administration inside the web application and a host recovery tool.
The services
| Service | Responsibility |
|---|---|
| Web | Application, instance administration, and API. |
| PostgreSQL | Accounts, projects, tests, runs, settings, and migration journal. |
| Migrations | DbUp PostgreSQL scripts, applied before new application code starts. |
| Artifact server | Traces, screenshots, videos, run bundles, and asset files. |
| Runner | Playwright test execution. |
| Browser host | Browser access for generation and Assistant work. |
Administration uses Settings → Administration at the application's normal address. There is no separate customer Admin service or port.
How they connect
The web application uses PostgreSQL, the artifact server, the runner, and the browser host. Runner and browser processes must reach the application under test. Users' browsers must reach both the application's public URL and its public artifact URL. Internal container or Kubernetes DNS names are not public URLs.
Startup order
PostgreSQL must become healthy before migrations run. The web application waits for the required schema before serving requests. Compose uses service health and successful migration completion; Helm uses a migration Job and a schema-checking init container. Investigate migration failures rather than bypassing those gates.
Data and persistence
Compose uses persistent volumes, Helm uses persistent storage configured for your cluster, and the appliance keeps installation data and secrets on its second disk. Stopping the application does not delete its data; removing volumes or replacing the data disk can.
Keep the runner and browser host at one replica each; their active work is process-local. Use capacity limits and resource sizing rather than adding interchangeable replicas behind a service.
See installation, configuration, and backup and restore.