Deployment options
Deploy DT on your own hardware or in your own cloud account, including air-gapped environments. Place the application, inference, data, and tools where the work requires them, with clear operating ownership.
Your hardware or your cloud account
Air-gapped deployment available
No connection back to DT
01 / Hosting arrangements
DT always runs on infrastructure you control and makes no calls back to us. Choose the environment that fits your operating model; either can serve enterprise or government teams.
Run the application, durable state, workers, and configured execution services in your own data center or facility, including fully disconnected environments. The documented Docker Compose stack provides a starting point. Production sizing, hardening, networking, and operational support are scoped for your environment.
Run the same stack in a cloud account your organization owns, including government regions. Your account holds the infrastructure, storage, keys, and network policy; DT engineers can help deploy and operate it under a scoped support arrangement.
Need DT to operate the platform in an account we manage? We consider that case by case; talk to us about the requirement.
Scroll the table horizontally to compare arrangements.
| Part of the system | Where it runs | Who manages it |
|---|---|---|
| Application and state | Your hardware or your cloud account. | Your team operates it, with DT implementation or support as agreed. |
| Model inference | A model endpoint inside your boundary, or a provider you configure. | You manage credentials and network approval. Inference may run separately from the application. |
| Files and working data | Your configured storage. | You own storage access, retention, backup, and recovery operations, and define information policy and permitted use. |
| Tool execution | Your workers, browser services, and optional sandboxes in the approved topology. | Your platform operators. Connected apps and private systems retain their own boundaries. |
| Audit capture | Inside the application deployment. | Operators apply required migrations, upgrade and drain covered writers, and activate applicable prospective capture. Organization policy and reviewer permissions bound evidence access. |
| Collector and bridge storage | Your selected collector or bridge, with persistent storage. | You operate trusted endpoints, storage, quotas, monitoring, and recovery. Application and provider queues have separate limits. Hosting the application alone does not establish provider delivery. |
| Provider ingestion and query | The SIEM owner provisions the receiver, schemas, ingestion credentials, and separate query permissions. Collector receipt, provider submission, and searchable indexed-field confirmation are different checks. | |
| Connected systems | Customer authorizes accounts, scopes, and destinations. External systems and model providers process requests under their own terms and configuration. | |
02 / Models and network paths
Platform operators configure providers, model endpoints, routing, and applicable fallback behavior. The model used for an agent can differ from the services used for browsing, document interpretation, or generated media.
We assess the selected endpoint against the intended workflow, tool use, capacity, and network requirements. An accessible endpoint is not evidence that every platform feature works with it.
Document the information sent to models, integrations, email, browser services, and telemetry. Keeping the application on customer infrastructure does not by itself keep all traffic within that boundary.
03 / Capture and security delivery
Application hosting does not decide where audit records are captured, forwarded, stored, or queried. Map the selected event families and each network hop alongside inference, tools, and egress.
Confirm feature gates, migrations, loaded writers, capture activation, permissions, and retention for the supported release. Capture begins prospectively; it cannot recreate earlier missing content. Review metadata and protected evidence policies separately.
Review audit coverageChoose eligible Organization-managed delivery, legacy installation OTLP, or a standalone operator bridge. Establish trusted receiver endpoints, credentials, durable storage where required, quotas, retry limits, and queue ownership. Managed activation changes future routing; old legacy deliveries drain to their original collector and managed failure does not fall back.
Compare forwarding routesMatch provider schemas and ingestion permissions, then verify indexed source fields through the provider’s query path. Detection and a playbook calling scoped response need separate identities, gates, target mapping, and recovery checks. Destination activation does not enable response.
Review delivery and responseAgree who applies migrations and drains writers, owns application and collector/bridge backup and recovery, monitors queue age and gaps, rotates credentials, and investigates missing provider fields. Test failure and recovery in the intended topology before claiming an operational result.
04 / Air-gapped AI deployment
DT supports air-gapped deployment. The supported configuration places the platform, model inference, and the tools needed for the workflow inside the isolated environment. Select the available capabilities around those internal services.
Configure model access, API and MCP connections, identity, storage, execution, and logging within the boundary. External SaaS connections are replaced with internal alternatives or left disabled in the air-gapped configuration.
Explore internal integrationsEstablish installation artifacts, software and model updates, malware definitions, backup and recovery, and maintenance access. Document the dependencies and test representative work in the target configuration.
Use platform documentation with your own team, or add DT engineers for deployment and integration.
Air-gapped deploymentDisconnected security operations. Capture, collectors, provider ingestion, and query must also stay inside the isolated topology or be disabled. A public-cloud Microsoft Sentinel route requires external connectivity and cannot operate disconnected. Endpoint-connectivity tests alone do not qualify an end-to-end offline workflow.
Explore the components and boundaries in our air-gapped AI reference architecture, then use the model update lifecycle guide to plan controlled changes. These educational guides provide evaluation questions to apply to your DT configuration.
05 / Getting to production
A working installation is the beginning of an operating service. Establish the roles, evidence, and support needed to sustain it.
Set information-handling rules, authorize connections, provide infrastructure and identity access where required, and designate administrators and reviewers.
Define acceptance tests, monitoring, incident escalation, upgrades, recovery, and training. Software, hosting, engineering help, and support are scoped as distinct commercial components.
Deployment and supportReview Security & Governance with the people responsible for your deployment. Vendors and solution providers can also scope a deployment for an embedded offering.
Next steps
Explore the platform around your systems and workflows. Your team can lead implementation, with DT engineering and support available when you need it.