A private deployment should pass a complete business request: signing in, uploading a document, building its index, answering with citations, calling a tool, and restoring the underlying data. A running container proves that its startup path works. Production readiness also requires named owners for data boundaries, capacity, upgrades, and recovery.
Establish six launch conditions
| Condition | Evidence to prepare | Acceptance criterion |
|---|---|---|
| Versions and architecture | Versions for the application, plugins, gateway, sandbox, and databases | Image architecture, dependencies, and configuration match the selected release |
| Data and network boundaries | Flows for documents, vectors, chat history, model requests, and object storage | Every external connection has a purpose, authentication method, and network rule |
| Persistence and recovery | Database, data-volume, and object-storage backup inventory | An isolated restore passes retrieval and file-access checks |
| Models and business requests | Tests for chat, embedding, reranking, and tools | Real accounts and entry points pass successful and failure scenarios |
| Capacity and observability | Peak traffic, import volume, storage growth, and alert thresholds | Latency, errors, queue growth, and resource headroom meet agreed limits |
| Operational ownership | Upgrade window, rollback triggers, owners, and on-call contacts | An upgrade rehearsal demonstrates how to restore service and data access |
Build a configuration baseline
Start with the official deployment files for the target release. Pin image versions and retain the configuration actually deployed. Check compatibility across the application and its supporting services; gateway, plugin, and Agent sandbox changes can have separate upgrade requirements.
For external databases, caches, and object storage, verify connection strings, TLS, permissions, and network access. Container-to-container addresses, host addresses, and browser-accessible addresses serve different paths. Test server-side file processing, browser download, and preview separately after an upload.
The vector database options included in deployment files change across releases. Confirm CPU architecture, database selection, and minimum service versions against the selected files and image manifests. Record these choices with the deployment so a historical compatibility report is interpreted in its original context.
Preserve sandbox isolation
When enabling code execution or Agent sandboxes, check the host kernel, container permissions, and network and file policies. Investigate a seccomp loading error against the documentation for that sandbox version and reproduce the host conditions before choosing a compatible host or upgrade.
Docker seccomp profiles filter system calls. Preserve the isolation conditions required by the selected sandbox and evaluate compatibility changes against its official documentation. A successful sandbox health check should be accompanied by timeout, restricted-file, and restricted-network tests.
Test through the real business entry point
- Sign in as an ordinary member and verify team, knowledge-base, and application permissions.
- Upload representative documents, wait for processing, and inspect chunks, indexes, and error records.
- Ask questions through the intended entry point and check answers, citations, and streaming. Include questions outside the knowledge base.
- Run required tools with successful responses, timeouts, and authentication failures.
- Restore databases and files into an isolated environment, then verify application bindings, retrieval, and downloads.
- Repeat the relevant paths under planned peak load, recording latency percentiles, failure rates, and queue recovery time.
Make a bounded launch decision
Assign an owner, deadline, and repeatable check to each failure. Once critical paths such as recovery, model authentication, and permission isolation pass, choose a traffic level consistent with the remaining business risk. Compare the original capacity estimate with observed usage after launch and adjust resources and alerts using that evidence.
Related guides
- Server Sizing for 100-Person Enterprise RAG Knowledge Bases: 4 Core Decision Dimensions
- FastGPT Model Gateway Architecture and Routing Guide