> ## 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. # Deployment Overview > Choose the right deployment method for your infrastructure needs ## Hosted vs. Self-Hosted Runlayer runs either as a **Runlayer-hosted** deployment or **self-hosted** in your own infrastructure. What runs where: | | Runlayer-hosted | Self-hosted | | ----------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | | **Gateway, platform app, database, audit logs** | Single-tenant deployment in an AWS account Runlayer operates for you | Your AWS account or Kubernetes cluster, deployed via the Terraform/Helm options below | | **Updates** | Applied by Runlayer — see [Updates](/operations/updates) | Applied by you on your schedule | | **[OAuth Broker](/oauth-broker)** | Available (shared Runlayer infrastructure at `oauth.runlayer.com`) | Not reachable — OAuth falls back to [per-vendor setup](/oauth-broker#self-hosted-deployments) | | **AI Watch (Shadow AI device agent)** | Runs on employee devices in both models; talks only to your tenant host over HTTPS — see [Deploy AI Watch](/shadow-ai/deploy) | Same, including air-gapped networks (no public-internet egress required) | In both models your organization gets an isolated deployment — you are not sharing a database with other Runlayer customers. See [Account Strategy & Isolation](#account-strategy--isolation) below for the available topologies, including a Runlayer-operated dedicated account. ## POC to Production A proof of concept can use the same product surfaces as production — connectors, policies, Sessions, AI Watch, audit logs, and analytics — but whether it can roll forward without redeployment depends on the deployment boundary you choose: | POC shape | Production path | | ----------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | **Runlayer-hosted single tenant** | Usually expands by adding users, connectors, policies, and MDM scope in the same tenant. | | **Customer-owned AWS/EKS/ECS** | Can roll forward if the POC was deployed with the production account, VPC, domain, secrets, backup, and upgrade posture you want to keep. | | **Temporary sandbox or throwaway VPC** | Usually redeploy production infrastructure, then migrate configuration intentionally. | | **Detect-only or Monitor endpoint pilot** | Expand MDM scope, then select Protect or Enforce and broaden Sessions coverage after scanner tuning. | Public docs do not publish standard POC timelines or success criteria. Use [Sessions](/platform-sessions#recommended-rollout), [Analytics](/platform-analytics), [Incidents](/platform-incidents), and [Audit Logs](/platform-audit-logs) as the evidence sources during a pilot. ## Deployment Options Runlayer supports multiple deployment methods to fit different infrastructure requirements, from staging to enterprise production environments. **Kubernetes on AWS** Production-ready EKS cluster with RDS, Redis, and full infrastructure **Serverless Containers** Simpler AWS deployment with ECS Fargate (no Kubernetes required) **Application Deployment** Deploy application on existing Kubernetes clusters with Helm **Multi-tenant EKS** Unified operator for RunlayerInstance + MCPServer on shared clusters ## Choosing Your Deployment Method ### EKS + Terraform - Kubernetes on AWS **Best for:** * Production Kubernetes workloads * Organizations wanting AWS-managed Kubernetes * Teams needing advanced orchestration * Multi-application shared clusters **Three Deployment Modes:** * **Full Stack**: Create new VPC + new EKS cluster + application infrastructure * **Existing VPC**: Use existing VPC + create new EKS cluster * **Existing EKS**: Use existing cluster + add application infrastructure only **Features:** * Managed EKS cluster (Kubernetes 1.33) * Auto-scaling node groups * Managed Aurora PostgreSQL with backups * ElastiCache Redis for performance * IAM Roles for Service Accounts (IRSA) * AWS Load Balancer Controller * CloudWatch observability * KMS encryption **Requirements:** * AWS account with appropriate permissions * Terraform 1.7+ * kubectl for cluster access * Helm 3.8+ for application deployment ### ECS + Terraform - Serverless Containers **Best for:** * Simpler production deployments * Organizations wanting serverless containers * Teams without Kubernetes expertise * AWS-native deployments **Two Configuration Options:** * **Minimal**: 4 required parameters, smart defaults (fastest deployment) * **Enterprise**: 160+ customizable options (full control) **Features:** * Auto-scaling ECS Fargate services * Managed Aurora PostgreSQL with backups * ElastiCache Redis for performance * Application Load Balancer with SSL * CloudWatch monitoring and logging * VPC with security groups * Simpler than Kubernetes **Requirements:** * AWS account with appropriate permissions * Domain name you control (required for SSL auto-creation) * Terraform 1.5+ * AWS CLI configured ### Helm + Kubernetes - Application Deployment **Best for:** * Organizations using Kubernetes * Teams wanting container orchestration * AWS EKS or other managed Kubernetes services * Production environments requiring high availability **Features:** * Kubernetes-native deployment with Helm charts * AWS IAM role integration for Bedrock access * Support for embedded or external databases * Certificate management (ACM or Let's Encrypt) * Horizontal pod autoscaling * Network policies and security contexts **Requirements:** * Kubernetes 1.19+ * Helm 3.8+ * kubectl configured * AWS IAM role with Bedrock permissions (for AWS deployments) ## Architecture Comparison ### EKS + Terraform Architecture ```mermaid theme={null} graph TB Internet[Internet] --> ALB[Application Load Balancer] ALB --> Ingress[Ingress Controller] subgraph "VPC - 10.0.0.0/16" subgraph "Public Subnets" ALB NAT[NAT Gateways] end subgraph "Private Subnets" Ingress EKS[EKS Cluster 1.33] Backend[Backend Pods] Frontend[Frontend Pods] end subgraph "Database Subnets" RDS[(Aurora PostgreSQL)] Redis[(ElastiCache Redis)] end end Ingress --> Backend Ingress --> Frontend Backend --> RDS Backend --> Redis EKS --> Backend EKS --> Frontend ``` ### ECS + Terraform Architecture ```mermaid theme={null} graph TB Internet[Internet] --> ALB[Application Load Balancer] ALB --> ECS[ECS Fargate Cluster] subgraph "ECS Services" Backend[Backend Service
2 instances] Frontend[Frontend Service
2 instances] end ECS --> Backend ECS --> Frontend Backend --> Aurora[(Aurora PostgreSQL
2-16 ACUs)] Backend --> Redis[(ElastiCache Redis)] Backend --> S3[S3 Buckets] subgraph "VPC 10.0.0.0/16" subgraph "Public Subnets" ALB end subgraph "Private Subnets" ECS end subgraph "Database Subnets" Aurora Redis end end ``` ### Component Comparison | Component | EKS + Terraform | ECS + Terraform | Helm + Kubernetes | | ----------------- | ------------------------ | ----------------- | ------------------- | | **Compute** | EKS Pods | ECS Fargate | Kubernetes Pods | | **Database** | Aurora PostgreSQL | Aurora PostgreSQL | PostgreSQL/External | | **Cache** | ElastiCache Redis | ElastiCache Redis | Redis/External | | **Load Balancer** | ALB + Ingress | Application LB | Ingress Controller | | **Monitoring** | CloudWatch | CloudWatch | Basic health checks | | **Scaling** | HPA + Cluster Autoscaler | Auto-scaling | HPA | | **Backups** | Automated | Automated | Manual | | **Complexity** | High | Medium | Medium | | **Cost** | \$200-800/mo | \$130-225/mo | Varies | ## Security Considerations ### EKS + Terraform Security * VPC with private subnets * Security groups with least privilege * KMS encryption for Kubernetes secrets * IAM Roles for Service Accounts (IRSA) * Network policies for pod isolation * Pod security contexts * Encrypted databases and storage * SSL/TLS with ACM certificates * CloudTrail for audit logging ### ECS + Terraform Security * VPC with private subnets * Security groups with least privilege * Encrypted databases and storage * SSL/TLS termination at load balancer * Secrets management with AWS Secrets Manager * CloudTrail for audit logging * Task role IAM policies ### Kubernetes Security (Helm) * Network policies for pod isolation * Pod security contexts * Service account with IAM role integration * Encrypted secrets with Kubernetes secrets * RBAC for fine-grained access control ## Account Strategy & Isolation A common question is whether Runlayer should live in a **separate AWS account** from your applications and data systems. Runlayer supports several account topologies: | Strategy | Who owns the account | Isolation boundary | Best for | | ----------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------- | | **Dedicated account (Runlayer-operated)** | Runlayer runs a single-tenant deployment in an account it operates for you | AWS account boundary | Teams that want single-tenant isolation without operating the infrastructure | | **Dedicated account (customer-owned)** | You create a separate "platform" account and deploy Runlayer there with [EKS](/deployment/eks-terraform) or [ECS](/deployment/terraform) Terraform | AWS account boundary | Enterprises with strict isolation or account-per-workload policies | | **Shared account/VPC** | You deploy into an existing account using the [Existing VPC or Existing EKS modes](/deployment/eks-terraform) | VPC/subnet and security groups | Teams consolidating infrastructure to reduce cost and network complexity | | **Multi-tenant shared cluster** | One account, multiple isolated tenants via the [Runlayer Operator](/deployment/runlayer-operator) | Per-tenant namespaces (`runlayer-`) plus per-tenant RDS, Redis, and IAM roles | Platform teams running Runlayer for multiple internal orgs on one EKS cluster | Running Runlayer in a dedicated account gives the strongest blast-radius isolation (separate IAM, CloudTrail, and billing), at the cost of managing an extra account and any cross-account networking. Sharing an account or VPC is simpler operationally but relies on VPC, security group, and IAM boundaries instead of the account boundary. A separate account does not require copying credentials for your data systems into it. Hosted connectors can use [cross-account IAM role assumption](/platform-deploy#aws-cross-account-roles-hosted-only) (`infrastructure.aws.assume_roles`) to call AWS APIs in your production accounts without storing long-lived access keys. ## Cost Considerations ### EKS + Terraform **Estimated Monthly Cost (us-east-1):** * **Full Stack**: \$723-1,088/month * EKS control plane: \$73 * EC2 nodes (4x m6i.2xlarge): \$400-500 * Aurora PostgreSQL (2-16 ACUs): \$60-240 * ElastiCache Redis: \$40-50 * NAT Gateways (3 AZs): \$100-120 * ALB + Data Transfer: \$40-80 * **Existing VPC**: Save \$100-120/month (no NAT Gateway costs) * **Existing EKS**: \$150-395/month (RDS + Redis + data transfer only) ### ECS + Terraform **Estimated Monthly Cost (us-west-2):** * **Minimal Configuration**: \$130-225/month * Aurora PostgreSQL (2-16 ACUs) * ECS Fargate (2 backend + 2 frontend) * ElastiCache Redis * Application Load Balancer * **Enterprise Configuration**: \$360-950/month * Higher capacity database and compute * Enhanced monitoring and backups * Custom scaling and security ### Helm + Kubernetes **Cost**: Depends on your Kubernetes infrastructure * **AWS EKS**: Use EKS + Terraform above * **Self-managed**: Your infrastructure costs * **Other cloud providers**: Varies by provider and configuration These are infrastructure cost estimates, not Runlayer commercial pricing. Public docs do not publish seat minimums, SKU packaging, or whether endpoint visibility, custom MCP hosting, managed connectors, and analytics are billed separately. Ask your Runlayer account team for commercial terms. ## Performance Characteristics | Deployment | Response Time | Throughput | Availability | | --------------------- | ------------- | ----------- | ------------ | | **EKS + Terraform** | \< 100ms | 1000+ req/s | 99.9%+ | | **ECS + Terraform** | \< 100ms | 1000+ req/s | 99.9%+ | | **Helm + Kubernetes** | \< 150ms | 500+ req/s | 99.5%+ | ## Getting Started Select the deployment method that best fits your needs and requirements Install required tools and set up accounts/credentials Set up domain names, certificates, and configuration values Follow the specific deployment guide for your chosen method Test the deployment and configure initial users and policies ## Next Steps Deploy Kubernetes infrastructure on AWS EKS Deploy serverless containers on AWS ECS Deploy application on Kubernetes with Helm