The company-owned environment
The company-server deployment path uses a dedicated Linux host and a company-operated model endpoint. The model can run on the same server or on a separate model host. Choose the model and its hardware together; application memory alone is not a model-sizing recommendation.
Prepare the infrastructure
- Host: a dedicated Linux Docker host, Docker Compose v2, Python 3 and persistent storage.
- Application memory: the company-server guide specifies at least 8 GiB RAM for the application and bounded tool containers. Model memory and GPUs are separate requirements.
- Address: a company HTTPS hostname and an agreed certificate and network configuration.
- Model: an endpoint reachable from the application container, with the model already provisioned.
- Delivery: the versioned application artifacts, compatible RIL runtime and deployment licence agreed for the pilot.
Choose the host layout
The documented Linux path applies to on-premises hardware and company-controlled VMs on AWS EC2, Azure Virtual Machines or Google Compute Engine. Select storage, machine size and GPU capacity separately. A model on a dedicated GPU server needs an approved route from the application host.
For a small pilot, a shared application/model host may simplify the layout if it has sufficient resources. Separate hosts let the infrastructure team size the model independently, but add network, authentication and operational responsibilities.
Define the network boundary
Document who can reach the application and model host. Initial images, models, certificate issuance and optional web tools may require outbound access. An on-premises installation does not by itself establish an air-gapped environment. Agree those network requirements before installation.
Keep configuration and state separate
Keep company configuration, secrets, stored documents and runtime state outside the application source or release directory. Identify the owner of backups, retention, upgrades and recovery. Treat deployment and model credentials as secrets.
Plan recovery as a complete environment
Application data, uploaded material, indexes, workspaces and private configuration belong in the recovery plan. Receipt-signing authority is persistent state too: retaining records without the corresponding trust information can break later evidence checks.
A data backup is not a copy of the application release or the separately operated model. Keep the matching release information and model configuration with your recovery runbook. Name who can access backups and who is authorised to restore them.
Plan capacity by workload
The engineering target is 100,000 concurrent active users, not a measured capacity guarantee. Applications, models, retrieval, tools and durable records have separate resource demands. Read the capacity guide and agree the actual hardware, workload mix and service levels.
Agree the pilot handover
The handover should identify versions, host responsibilities, model configuration, approved users, backup location and support contact. Capacity and recovery requirements belong in the agreed pilot scope; they are not implied by the minimum application specification.