Deployment Models
FactVerse private deployments should match the customer's security policy, infrastructure standard, integration needs, operations team, and production support expectations. In this documentation set, deployment models refer to customer-controlled environments for private delivery.
Prerequisites
Before selecting a model, confirm the business scope, products in scope, source systems, target users, identity provider, data classification, customer infrastructure standard, network boundary, backup requirement, and change approval process.
Deployment options
| Model | Typical use | Customer responsibilities | DataMesh or implementation team responsibilities |
|---|---|---|---|
| Customer Kubernetes or OpenShift | Production deployment on the customer's standard container platform. | Provide cluster, namespace or project, registry, ingress, storage class, DNS, TLS, monitoring, backup, and access approvals. | Provide delivery package, configuration guidance, deployment validation, product setup, and upgrade guidance. |
| Customer VM with Docker Compose | Lab validation, training environment, single-node acceptance, or troubleshooting before cluster rollout. | Provide host resources, Docker runtime, network route, storage path, DNS or local endpoint, backup expectation, and access controls. | Provide Compose package, configuration template, validation steps, and migration path to the production runtime. |
| Air-gapped or restricted network | Customer environment cannot pull images or packages from external sources. | Provide approved transfer path, internal registry, checksum review, scan process, offline storage, and change window. | Provide image archive, manifests, checksums, release notes, offline import steps, and upgrade bundle structure. |
| Hybrid customer integration | FactVerse runs in a customer-controlled environment while source systems, clients, identity services, or devices sit in other customer network zones. | Approve routes, firewall rules, proxy policy, credentials process, source-system samples, and data-transfer rules. | Configure connectors, service identities, scoped endpoints, validation workflow, and integration handover evidence. |
Selection flow
Inputs
| Input | Why it matters |
|---|---|
| Products and modules | Determines compute, storage, connectors, service count, and validation scope. |
| Container platform | Determines manifest format, ingress pattern, storage class, security policy, and upgrade method. |
| User groups and sites | Affects identity mapping, network access, language, device rollout, and support windows. |
| Data sources | Determines connector placement, network routes, credentials, synchronization cadence, and validation samples. |
| Security policy | Drives registry handling, image scanning, secret storage, encryption, access review, audit, and retention. |
| Availability target | Shapes replica planning, monitoring, backup, restore testing, and maintenance windows. |
| Change process | Determines release approvals, validation environment, rollback expectations, and evidence retention. |
Decision checklist
- Customer security owner has approved the customer-side deployment model.
- Runtime platform owner and operations owner are assigned.
- Identity provider and sign-in method are known.
- Data-source owners and integration boundaries are assigned.
- Registry, network routes, allowlists, proxy requirements, and domain requirements are documented.
- Backup, recovery, monitoring, and release responsibilities are assigned.
- A validation path is defined before production changes.
Expected result
The selected model should identify the customer runtime, environment owner, access endpoint, identity method, image delivery path, source-system connection path, backup process, release approval path, and incident escalation owner.
Troubleshooting model gaps
| Symptom | Check |
|---|---|
| Deployment decision stalls | Missing security owner, runtime owner, data classification, registry policy, or network approval. |
| Cluster deployment cannot start | Namespace or project, storage class, ingress class, image registry, pull secret, or resource quota is missing. |
| Offline delivery cannot proceed | Transfer path, checksum process, internal registry owner, scan policy, or upgrade window is missing. |
| SSO planning is blocked | Identity provider owner, metadata exchange, callback URL, certificate trust, or user mapping is missing. |
| Support ownership is unclear | Production owner, customer IT owner, implementation contact, and escalation windows are not assigned. |
Related pages
- Use Container Deployment to implement the selected model.
- Use Environment Readiness after confirming the implementation path.
- Use Identity and Access for sign-in and SSO planning.
- Use Service Accounts and API Keys for integration identity.