Architecture & boundaries
A browser surface, a customer-hosted workspace and an agent runtime close to the repository. Understand the responsibilities at each boundary.
On this page
The browser is the working surface
The browser presents projects, session history and the surfaces used to inspect or guide agent work. It is not the execution environment, and this marketing website is not the workspace application.
A connection problem in the browser should not be interpreted as proof that a host-side task has stopped. Recovery needs to establish the actual session state.
The intended components
Workspace service
The customer-hosted application coordinates project context and access to the working environment.
Execution host
The machine with the repository, runtime, dependencies and permissions needed by a task.
Agent runtime
Codex is first in scope. Its authentication, tool behavior and provider connection remain distinct from the workspace.
Supporting services
The planned cloud layer may handle account, entitlement, relay and push metadata for relevant product features.
The data boundary
The architecture direction keeps code, compute and session content on customer infrastructure by default. That does not mean no data ever leaves a host: the configured agent provider and optional integrations have their own data flows.
A released deployment must document these flows precisely. Qodarium does not make a blanket zero-knowledge, compliance or universal privacy guarantee on the basis of being self-hosted.
Remote access is a separate concern
SSH connects remote project environments in the product scope. A planned relay can make a workspace reachable from a browser without changing who should be authorized to use it.
Reachability, identity and command permissions must be handled deliberately. A relay does not replace host security, backups or runtime approval settings.
Related guides
Check host readiness and what self-hosting means before choosing an operating model.