> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cymph.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Deployment models

> The two ways to run Cymph, and who is responsible for what in each.

Cymph is delivered in two variants. Both run the same product with the same architecture, the same features and the same administrative model. What differs is **who operates the infrastructure**.

<Columns cols={2}>
  <Card title="Managed cloud tenant" icon="cloud" href="/deployment/managed-cloud-tenant">
    A dedicated instance at its own hostname, hosted and operated by Cymph. You configure the application; Cymph runs everything underneath it.
  </Card>

  <Card title="Self-hosted" icon="hard-drive" href="/deployment/self-hosted/architecture">
    You install and operate Cymph on your own infrastructure, with Docker Compose. Nothing leaves your network unless you configure it to.
  </Card>
</Columns>

Neither is a shared multi-tenant service — in both cases your deployment is a separate instance with its own data store.

## Responsibility split

|                                            | Managed cloud tenant     | Self-hosted                                                           |
| ------------------------------------------ | ------------------------ | --------------------------------------------------------------------- |
| Installation                               | Cymph                    | You                                                                   |
| Hostname and DNS                           | Cymph                    | You                                                                   |
| TLS certificates and renewal               | Cymph                    | [You](/deployment/self-hosted/tls-certificates)                       |
| Database and filesystem                    | Cymph (managed services) | [You](/deployment/self-hosted/architecture) (containers on your host) |
| Backups and restore                        | Cymph                    | [You](/deployment/self-hosted/backup-restore)                         |
| Version upgrades                           | Cymph                    | [You](/deployment/self-hosted/upgrades)                               |
| Encryption key custody                     | Cymph                    | You                                                                   |
| **Outbound e-mail (SMTP)**                 | **You**                  | **You**                                                               |
| **AI provider**                            | **You**                  | **You**                                                               |
| **Single sign-on**                         | **You**                  | **You**                                                               |
| **Playbook Hub and Explore**               | **You**                  | **You**                                                               |
| **Organisations, members, roles, teams**   | **You**                  | **You**                                                               |
| **Integrations**                           | **You**                  | **You**                                                               |
| **Firewall allowlisting for integrations** | **You**                  | **You**                                                               |

The pattern is worth stating plainly: **infrastructure differs, application configuration does not.** Every setting inside the product is yours in both models, configured from the same screens by the same administrator account. That is why [Networking](/deployment/networking) and [Instance settings](/deployment/settings/smtp) are documented once for both, while installation, TLS, backup and upgrades live under [Self-hosted](/deployment/self-hosted/architecture).

## Choosing between them

Choose **self-hosted** when data residency, network isolation or key custody has to sit inside your own boundary — for example when policy prohibits customer data leaving your infrastructure, or when your integration endpoints are only reachable from your own network. You take on installation, certificates, backups and upgrades in exchange.

Choose a **managed cloud tenant** when you would rather not operate the infrastructure. You still own every application-level setting and every integration, and your data stays in the EU — but Cymph carries the installation, patching, backup and upgrade burden.

If integration endpoints inside your network are reachable only from that network, note that a managed tenant connects to them from AWS. That is workable with an allowlist, but self-hosted avoids the question entirely. See [Networking](/deployment/networking).

## Where your data lives

|                          | Managed cloud tenant               | Self-hosted                     |
| ------------------------ | ---------------------------------- | ------------------------------- |
| Application and database | AWS `eu-west-1` (Europe / Ireland) | Your infrastructure             |
| Search embeddings        | Generated inside the deployment    | Generated inside the deployment |
| AI processing            | Your chosen provider               | Your chosen provider            |

[Data protection](/security/data-protection) covers this in full, including encryption and key custody.

<Note>
  `app.cymph.io` is a demo instance used for evaluation and is not a commercial deployment option. Production use is via a managed cloud tenant or a self-hosted deployment.
</Note>