Container Deployment

Use this page for customer-side private deployment projects where FactVerse runs in a customer-controlled container environment. The scope is Kubernetes, OpenShift, Docker Compose validation, offline image delivery, registry setup, ingress, storage, secrets, backup, upgrade, and handover.

Public service runtime and website deployment details are outside this documentation set.

Prerequisites

Confirm the deployment model first. Before scheduling implementation, the customer and project team should agree on the runtime platform, network zone, domain, TLS owner, registry access, storage class, identity provider, backup target, monitoring platform, source systems, and change approval process.

Container topology

Runtime options

Option	Typical use	Notes
Kubernetes	Production deployment on a customer-managed cluster.	Recommended when the customer has a standard container platform, ingress controller, storage class, monitoring, and backup process.
OpenShift	Production deployment in organizations that standardize on OpenShift.	Use the customer's project, route, SCC, registry, and operator policies.
Docker Compose	Lab validation, pilot validation, single-node acceptance, and troubleshooting.	Use it to validate configuration and training flows. Production use requires explicit customer approval and resource planning.
Air-gapped delivery	Restricted networks where the cluster cannot pull from an external registry.	Deliver image archives, checksums, manifests, and upgrade packages through the customer's approved transfer path.

Inputs

Input	Required detail
Runtime platform	Kubernetes version, OpenShift version, Docker Engine version, node architecture, namespace or project, and resource quota.
Registry	Customer registry URL, image import method, pull secret owner, tag policy, scan policy, and offline transfer process.
Network	Domain, DNS owner, ingress or route class, TLS certificate owner, proxy, firewall, and source-system access paths.
Storage	Storage class, persistent volume size, object storage or file storage path, backup schedule, and restore owner.
Data services	Customer database, cache, message queue, search service, or project-specific managed data services when used.
Secrets	Database credentials, service keys, IdP metadata, connector credentials, encryption keys, and rotation owner.
Identity	Password policy, enterprise SSO, group mapping, tenant administrators, service accounts, and callback URL.
Operations	Monitoring owner, log platform, alert route, backup owner, maintenance window, upgrade approver, and support owner.

Project-specific image names, chart names, ports, and environment variables are provided in the delivery package for each release.

Deployment package

The delivery package should include the items required for the customer's runtime and security process:

• container images or registry pull instructions;
• Helm chart, Kustomize overlays, Kubernetes manifests, OpenShift templates, or Docker Compose files;
• values template and environment configuration checklist;
• namespace or project setup instructions;
• secret and certificate checklist;
• initialization and migration job instructions;
• release notes, compatibility notes, checksum files, and SBOM or vulnerability scan evidence when required;
• offline bundle structure and import steps for restricted networks;
• validation checklist and handover runbook.

Implementation steps

1. Confirm the customer runtime platform, namespace or project, resource quota, storage class, ingress class, registry path, and change window.
2. Import or pull the required images into the customer registry.
3. Create the namespace or OpenShift project and apply quota, network policy, and service account settings.
4. Create secrets and config maps for database, storage, identity, connectors, license, and product configuration.
5. Configure persistent volumes, object storage, data service endpoints, and backup targets.
6. Configure ingress, route, DNS, TLS certificate, proxy, and SSO callback URL.
7. Deploy FactVerse services, connector jobs, migration jobs, and initialization tasks from the approved package.
8. Run database migration and tenant initialization jobs.
9. Validate pods, services, ingress, logs, health endpoints, and storage mounts.
10. Create tenant administrators, user groups, roles, service accounts, and initial product modules.
11. Validate client access from approved networks and representative devices.
12. Validate source-system integration with sample records before enabling scheduled synchronization.
13. Record the deployment inventory, configuration baseline, backup process, restore test plan, upgrade process, and support path.

Expected result

The expected output is a customer-controlled FactVerse container environment with approved runtime ownership, image delivery path, ingress and TLS configuration, storage and backup process, identity integration, product modules, source-system validation, monitoring route, and upgrade procedure.

Container operations

Area	Practice
Scaling	Define requests, limits, replica counts, autoscaling policy, and capacity review cadence.
Upgrade	Use versioned image tags, release notes, migration jobs, validation steps, and rollback criteria.
Rollback	Keep the previous image set, configuration baseline, and database restore point according to the customer's change process.
Logs	Send application logs, ingress logs, connector logs, and job logs to the customer log platform.
Metrics	Monitor pod health, restart count, CPU, memory, storage, queue backlog, sync failures, and API error rate.
Certificates	Track TLS expiry, IdP certificate expiry, connector certificate expiry, and rotation windows.
Secrets	Store secrets in the customer-approved mechanism and define the rotation owner.
Backup	Back up persistent data, configuration, documents, object storage, and database state according to the recovery objective.

Validation checklist

• The cluster or runtime version is approved for the release package.
• Image import, image pull, and vulnerability scan requirements are complete.
• Namespace, resource quota, network policy, and storage class are configured.
• Ingress, DNS, TLS, proxy, and SSO callback URL are validated.
• Secrets and config maps are created through the customer's approved process.
• Database migration and initialization jobs have completed.
• Administrators can sign in and reach the expected tenant.
• Product modules are enabled for the target scope.
• Source-system integrations pass sample data validation.
• Backup and restore responsibilities are recorded.
• Monitoring, logs, alert routing, support contacts, and maintenance windows are documented.

Troubleshooting

Symptom	Check
Image pull fails	Registry route, pull secret, image tag, offline import, certificate trust, and scan gate.
Pods restart repeatedly	Resource limits, missing secrets, database route, storage permission, startup dependency, and migration status.
Ingress opens but login fails	SSO metadata, callback URL, tenant assignment, cookie domain, TLS certificate, and clock sync.
Client app connects to the wrong environment	Environment URL, private server code, proxy, cached settings, and release channel.
Integration jobs cannot reach source systems	Firewall rule, DNS, proxy, service credential, source-system allowlist, and sample payload.
Upgrade cannot proceed	Backup point, migration precheck, image compatibility, configuration diff, and rollback owner.

Related pages

• Use Deployment Models to choose the customer-side deployment pattern.
• Use Environment Readiness to prepare the implementation checklist.
• Use Go-Live and Handover to record production acceptance.