> ## Documentation Index
> Fetch the complete documentation index at: https://docs.runlayer.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Shared Responsibility Model
> Who operates and supports what across Runlayer-hosted and self-hosted deployments
Runlayer runs either as a **Runlayer-hosted** deployment (single-tenant infrastructure Runlayer operates for you) or **self-hosted** in your own AWS account or Kubernetes cluster. The two models split operational ownership differently. This page makes that split explicit so on-prem and self-hosted teams know exactly what they own versus what Runlayer owns.
For the deployment topologies themselves (hosted, dedicated account, shared VPC, multi-tenant operator), see [Deployment Overview](/deployment/overview). This page is about **ongoing operations and support**, not initial architecture.
## The model at a glance
| Responsibility | Runlayer-hosted | Self-hosted |
| ------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- |
| **Infrastructure provisioning** (VPC, cluster, RDS, Redis, load balancer) | Runlayer | You — via [ECS](/deployment/terraform), [EKS](/deployment/eks-terraform), or [Helm](/deployment/helm) |
| **Version updates & patching** | Runlayer, on its schedule | You, on your schedule — see [Updates](/operations/updates) |
| **Infrastructure monitoring & alerting** | Runlayer | You — CloudWatch/Grafana per [Monitoring](/infrastructure/monitoring) |
| **Database backups & restore** | Runlayer (automated) | You — automated on ECS/EKS Terraform, manual on Helm/external DB; see [Backup & Restore](/operations/backup-restore) |
| **Capacity & scaling** | Runlayer | You (autoscaling ships in the Terraform/Helm modules; you tune limits) |
| **Network & host security** (security groups, IAM, KMS, TLS certs) | Runlayer | You — see [Security](/infrastructure/security) and [SSL Certificate Management](/ssl-certificate-management) |
| **Application configuration** (connectors, policies, roles, MDM scope) | You | You |
| **Identity integration** (SSO/SCIM, WorkOS) | You (Runlayer assists) | You (Runlayer assists) |
| **[OAuth Broker](/oauth-broker)** | Shared Runlayer infra (`oauth.runlayer.com`) | Not reachable — you configure [per-vendor OAuth apps](/oauth-broker#self-hosted-deployments) |
| **AI Watch (device agent)** | Runs on your employee devices in **both** models; talks only to your tenant host over HTTPS — see [Deploy AI Watch](/shadow-ai/deploy) | Same |
| **Incident response for the Runlayer app** | Runlayer | Shared — you triage infra, Runlayer supports the application layer (see [Support](#support-boundaries)) |
| **Security scanning / threat detection logic** | Runlayer (ships in the product) | Runlayer (ships in the product) |
| **Data ownership** | Your org — single-tenant, not shared with other customers | Your org — data never leaves your infrastructure |
In **both** models your organization gets an isolated, single-tenant deployment — you are never sharing a database with other Runlayer customers. The difference is *who runs the infrastructure*, not *whose data it is*.
## What stays the same in both models
Some things are part of the product and Runlayer owns them regardless of where you deploy:
* **Detection and governance logic** — prompt-injection and data-exfiltration scanners, policy enforcement, and audit-log generation ship in the container images. You get the same controls self-hosted as hosted.
* **Product updates** — every version is published in the [changelog](/changelog). Hosted deployments receive them automatically; self-hosted deployments pull the new image tag when you choose (see [Updates](/operations/updates)).
* **AI Watch endpoint agent** — runs on employee devices and reports only to your own tenant host, including on air-gapped networks with no public-internet egress.
## Self-hosted: what you own operationally
If you run Runlayer in your own AWS account or cluster, you take on the infrastructure lifecycle:
1. **Provision** with the [ECS + Terraform](/deployment/terraform), [EKS + Terraform](/deployment/eks-terraform), or [Helm](/deployment/helm) modules. These ship autoscaling, managed Postgres/Redis, load balancing, and (on the Terraform paths) automated backups.
2. **Update** by bumping the image tag and running `terraform apply` — updates are manual and fully under your control. See [Updates](/operations/updates).
3. **Monitor** through CloudWatch (Terraform paths ship alarms) or your own Grafana/observability stack. See [Monitoring](/infrastructure/monitoring).
4. **Back up and restore** the database on your schedule. Automated backups are provisioned on the Terraform paths; with an external/BYO database on Helm, backups are your responsibility. See [Backup & Restore](/operations/backup-restore).
5. **Secure** the network and hosts — security groups, IAM/IRSA, KMS encryption, and TLS certificates. See [Security](/infrastructure/security).
Runlayer offers **managed maintenance services** (proactive monitoring, security patching, capacity planning) for self-hosted deployments as a support add-on. If you want Runlayer to co-own day-2 operations rather than owning them entirely yourself, see [Maintenance](/operations/maintenance) and talk to your account team.
## Support boundaries
| Layer | Who diagnoses first | How to get help |
| ----------------------------------------------------------------------- | ------------------- | -------------------------------------------------------------------------------------------------- |
| **Runlayer application** (gateway, policies, connectors, scanners, UI) | Runlayer | Your dedicated Slack channel or [support@runlayer.com](mailto:support@runlayer.com) |
| **Your infrastructure** (AWS account, cluster health, DNS, VPC routing) | You | [Troubleshooting](/operations/troubleshooting), then escalate to Runlayer if the app is implicated |
| **Deployment / upgrade changes** | Shared | Runlayer reviews the [golden-path](/deployment/overview) config; you apply it in your account |
Commercial support tiers, response-time SLAs, and dedicated Field Engineering hours are set in your order form, not in these public docs. Ask your Runlayer account team for the specifics that apply to your contract.
## Related
Hosted vs. self-hosted topologies and account isolation
How self-hosted version updates work
Data protection procedures
Observability and alerting