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 | Applied by you on your schedule |
| OAuth Broker | Available (shared Runlayer infrastructure at oauth.runlayer.com) | Not reachable — OAuth falls back to per-vendor setup |
| 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 | Same, including air-gapped networks (no public-internet egress required) |
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 monitoring-only endpoint pilot | Expand MDM scope, then enable Enforcement and broader Sessions coverage after scanner tuning. |
Deployment Options
Runlayer supports multiple deployment methods to fit different infrastructure requirements, from staging to enterprise production environments.EKS + Terraform
Kubernetes on AWSProduction-ready EKS cluster with RDS, Redis, and full infrastructure
ECS + Terraform
Serverless ContainersSimpler AWS deployment with ECS Fargate (no Kubernetes required)
Helm + Kubernetes
Application DeploymentDeploy application on existing Kubernetes clusters with Helm
Runlayer Operator
Multi-tenant EKSUnified 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
- 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
- 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
- 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
- Minimal: 4 required parameters, smart defaults (fastest deployment)
- Enterprise: 160+ customizable options (full control)
- 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
- 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
- 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
- Kubernetes 1.19+
- Helm 3.8+
- kubectl configured
- AWS IAM role with Bedrock permissions (for AWS deployments)
Architecture Comparison
EKS + Terraform Architecture
ECS + Terraform Architecture
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 or ECS 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 | 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 | Per-tenant namespaces (runlayer-<customerId>) plus per-tenant RDS, Redis, and IAM roles | Platform teams running Runlayer for multiple internal orgs on one EKS cluster |
A separate account does not require copying credentials for your data systems into it. Hosted connectors can use cross-account IAM role assumption (
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
Next Steps
EKS + Terraform
Deploy Kubernetes infrastructure on AWS EKS
ECS + Terraform
Deploy serverless containers on AWS ECS
Helm + Kubernetes
Deploy application on Kubernetes with Helm