Managed cloud tenant
A dedicated instance at its own hostname, hosted and operated by Cymph. You configure the application; Cymph runs everything underneath it.
Self-hosted
You install and operate Cymph on your own infrastructure, with Docker Compose. Nothing leaves your network unless you configure it to.
Responsibility split
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 and Instance settings are documented once for both, while installation, TLS, backup and upgrades live under Self-hosted.
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.Where your data lives
Data protection covers this in full, including encryption and key custody.
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.