Host prerequisites
The customer provides and operates the Linux host, systemd environment, network boundary, gateway, storage, monitoring, and administrative access.
On-premise architecture
Design the agent runtime boundary before choosing the model
A production on-premise AI agent architecture starts with ownership: who controls the host, tenant identities, runtime services, workspaces, secrets, browser state, logs, updates, and recovery. Bewize Hub can be installed on a customer-controlled Linux systemd host and provision separate tenant users and services. The documented production model path still requires outbound access to a hosted model provider.
Reference architecture
What belongs inside and outside the customer-controlled host?
Keep the operational boundary explicit. The customer-controlled host can contain the Hub, its database and protected secrets, separate tenant Linux identities, tenant runtime services, private workspaces, browser state, logs, and optional access-controlled company storage. The gateway permits required outbound connections, including the supported hosted-model path.
Customer-controlled deployment boundary
The host owns agent operations; approved external services remain explicit dependencies.
Linux host with Bewize Hub
- Tenant users and systemd services
- Private workspaces and browser state
- Hub database and protected secrets
- Optional governed company storage
- Gateway to hosted model provider
Tenant separation
Hub provisions distinct Linux identities and private runtime, workspace, and browser state for managed tenants. This is a concrete isolation mechanism, not an absolute security guarantee.
Operations evidence
Operators use systemd logs, health and readiness checks, redacted usage metrics, versioned packages, and reconciliation to inspect and update the deployment.
Recovery boundary
Tenant backup snapshots are available but disabled by default, so backup policy, retention, restore testing, and responsibility must be chosen during deployment.
Continue the architecture review
Use these companion pages to turn the diagram into a deployment decision.
Deployment quality checklist
Verify ownership, isolation, networking, secrets, evidence, updates, backup, recovery, and unsupported assumptions.
Review →Self-hosted vs private cloud
Choose a location and operating model without confusing infrastructure ownership with model hosting.
Review →Compare platforms
Ask competing vendors for evidence across the same operational boundaries.
Review →On-premise architecture questions
Is Bewize documented as air-gapped?
No. The current documented model path uses hosted Codex with an optional OpenRouter fallback, so standard deployment requires outbound model access. Do not treat on-premise runtime placement as an air-gap claim.
Can a customer-hosted model be connected?
A customer-hosted OpenAI-compatible model is a possible integration subject to validation. It is not currently the documented production-supported primary configuration.
Is Roomcord included as a turnkey on-premise package?
No. Roomcord can be discussed for customer-hosted scope, but its current deployment has external service dependencies and no documented turnkey on-premise package.
Review your deployment boundary
Bring your host, network, model-access, storage, identity, backup, and recovery requirements. We will map them against what is shipped today and identify what still needs validation.
Architecture conversation
Tell us what your team needs to control
Share your deployment boundary, number of agents, work surfaces, and governance requirements. We will reply by email to arrange a focused technical discussion.
Email the Bewize teamThis opens your email application. Read our Privacy Policy.