1. Ownership
Name the owner of the host, operating system, systemd services, gateway, DNS, certificates, capacity, patching, monitoring, and incident response.
Deployment quality checklist
Verify the controls, dependencies, and recovery path before the pilot
Use this checklist to convert an on-premise claim into testable deployment evidence. It is an operational review aid, not a certification or security guarantee. Record the owner, configuration, evidence, test result, and unresolved exception for every item.
Quality gate
Nine boundaries to verify
A deployment is ready for real work only when its responsibilities and failure paths are explicit. The diagram provides the review sequence; the checks below turn it into evidence.
Deployment acceptance path
Do not approve a pilot on architecture labels alone.
Evidence-backed deployment decision
- Ownership and supported topology
- Identity, isolation, and access
- Network and external dependencies
- Secrets, storage, and browser state
- Logs, updates, backup, and recovery
2. Supported topology
Record what is shipped, what requires validation, and what is out of scope. Do not label the deployment air-gapped or fully customer-hosted without evidence.
3. Tenant isolation
Verify separate Linux identities, private runtime services, workspaces, browser state, permissions, and the operator path for blocking or removing access.
4. Network boundary
List every required inbound and outbound connection, destination, protocol, gateway rule, failure behavior, and monitoring control. Include hosted-model access.
5. Secrets and identity
Confirm how protected secrets are stored, who may change them, how values stay out of logs, and how credentials are rotated or revoked.
6. Data and storage
Map the Hub database, tenant workspace, browser state, logs, optional company storage, retention, access controls, encryption decisions, and deletion procedure.
7. Operational evidence
Test systemd logs, health and readiness checks, redacted usage metrics, alert ownership, troubleshooting access, and evidence retention.
8. Updates and change control
Verify versioned packages, reconciliation, maintenance ownership, rollback decisions, compatibility checks, and how tenant impact is communicated.
9. Backup and recovery
Choose whether tenant snapshots are enabled, then test backup scope, retention, restore time, restore authority, failed-host recovery, and evidence of a successful restore.
Cross-reference every checklist decision
Use the related pages to understand the architecture and compare alternatives consistently.
Checklist boundaries
Does completing this checklist prove compliance?
No. It creates an evidence trail for architecture and operational review. Compliance depends on the applicable requirements, implementation, contracts, controls, and independent review.
Are backups enabled automatically?
No. Tenant backup snapshots are available but disabled by default. The deployment owner must choose, configure, secure, monitor, and test the backup and restore process.
What should block pilot approval?
Unowned infrastructure, unknown network dependencies, unverified tenant isolation, unclear secret handling, missing logs, or an untested recovery path should remain explicit blockers rather than assumptions.
Turn the checklist into a pilot acceptance plan
Bring your required controls and operating constraints. We will identify the evidence available today, the tests required for your environment, and any unsupported assumptions.
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.