# Deployment options
URL: /deploy
Foxborne runs as a single tenant in your cloud account, your data center or an air-gapped enclave. The modes differ in where it runs and how updates get in, and none of them sends anything to Foxborne.
Foxborne is software you run inside your own environment. Flight logs, journals and reports stay on infrastructure you control, and the deployment belongs to your program alone. Pick the mode by where your evidence already lives and by how your network lets software in.
## The three modes [#the-three-modes]
**Your cloud account.** Foxborne deploys into your AWS, AWS GovCloud or Azure Government account. Originals stay in your buckets, encrypted with your keys. The example deployment in the console runs this way, in AWS GovCloud (US-West).
**Your data center.** Foxborne runs on your own Kubernetes or a pair of Linux hosts, next to the log servers you already have. Originals go to object storage you run, such as MinIO or Ceph.
**Air-gapped.** The network has no path out at all. Updates arrive as signed bundles that your administrator carries in, and Foxborne verifies each one before it installs.
## What changes between them [#what-changes-between-them]
The console, the rules and the reports behave the same in every mode. What changes is where it runs, how updates arrive, where storage and keys live and what may leave the network.
| | Your cloud account | Your data center | Air-gapped |
| -------------------------- | ---------------------------------------------------------- | ---------------------------------------------------------- | --------------------------------------------------------- |
| Where it runs | Your AWS, AWS GovCloud or Azure Government account | Your Kubernetes or a pair of Linux hosts | A network with no path out |
| Original files | Your buckets, such as Amazon S3 or Azure Blob Storage | Your S3-compatible storage, such as MinIO or Ceph | Object storage inside the enclave |
| Keys | Your key service, such as AWS KMS or Azure Key Vault | Your key management system | Key management inside the enclave |
| Database | PostgreSQL 16 in your account | PostgreSQL 16 in your network | PostgreSQL 16 inside the enclave |
| How updates arrive | A signed bundle your administrator brings in | A signed bundle your administrator brings in | A signed bundle carried in on media your process approves |
| What leaves the network | Only what you configure, such as audit events to your SIEM | Only what you configure, such as audit events to your SIEM | Nothing. Audit events go to a SIEM inside the enclave. |
| Vehicles and range control | Collectors connect out to the deployment over mutual TLS | Collectors connect out to the deployment over mutual TLS | Collectors and receivers work inside the enclave |
Updates arrive the same way in every mode. The update dialog on **Hosting** says it plainly: **Updates are signed bundles. Nothing is downloaded; your administrator brings the file in.**
## What never changes [#what-never-changes]
* **One tenant.** The deployment belongs to you, and no other organization shares it.
* **Nothing sent to Foxborne.** There is no telemetry, no crash reporting and no license call home. The license is checked offline.
* **No remote access.** Foxborne staff have no path into your deployment. When you want help, you share an export or a screen, under your own process.
* **Write-once originals.** Files are hashed with SHA-256 on arrival, stored write-once and encrypted with your key.
* **Read-only connections.** Foxborne reads from the storage you already run and never writes to it.
* **Outbound-only collectors.** Collectors connect over mutual TLS with a certificate per vehicle. No port opens on a vehicle.
* **Your identity provider and your SIEM.** Sign-in runs through your identity provider over SAML 2.0 or OIDC, and the hash-chained audit log streams to your SIEM over syslog with TLS.
* **Local maps.** Maps are drawn from elevation data you load. Nothing calls a tile service.
* **Signed releases.** Each release is a signed bundle with a software bill of materials. The signature is checked before anything installs.
Foxborne is software you run inside your own environment, within your own authorization boundary. It holds no FedRAMP authorization and no CMMC certification of its own.
## How to choose [#how-to-choose]
Start from where the evidence lands today. Foxborne reads it where it already is, read-only, and those reads stay inside your network.
* **Flight logs land in a cloud bucket.** Deploy into that account. Foxborne reads Amazon S3 through a read-only IAM role and Azure Blob Storage through a managed identity, in GovCloud and Azure Government too.
* **Logs sit on servers you run.** Deploy in your data center, beside them. Foxborne polls SFTP directories on ground stations and log servers, and reads SMB or NFS shares mounted read-only on the worker.
* **The evidence network has no path out.** Choose air-gapped. The map renders the same way because it never calls a tile service, and the license needs no call home.
Then settle how updates may enter. An administrator always brings the signed bundle in, and in an enclave that means media your process approves.
## Next [#next]
The example deployment's layout, what to prepare and how to check it on Hosting.
The same properties, mapped to Azure Government services.
Your Kubernetes or a pair of Linux hosts, next to your log servers.
No path out: signed bundles carried in, an offline license and local maps.
## Related [#related]
* [Architecture and network paths](/deploy/architecture) lists every component, data store and connection.
* [Install an update](/deploy/upgrades) walks through the signature, bill of materials and migration checks.
* [Backups and recovery](/deploy/backup-and-restore) and [Monitor a deployment](/deploy/operations) cover day-to-day running.
* [Security model](/security) describes identity, audit, markings and the supply chain.