Deployment Overview

​

Hosted vs. Self-Hosted

Runlayer runs either as a Runlayer-hosted deployment or self-hosted in your own infrastructure. What runs where: In both models your organization gets an isolated deployment — you are not sharing a database with other Runlayer customers. See 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: Public docs do not publish standard POC timelines or success criteria. Use Sessions, Analytics, Incidents, and 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.

​

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.34)
• 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

​

ECS + Terraform Architecture

​

Component Comparison

​

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: 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.

​

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

​

Performance Characteristics

​

Getting Started

​

Next Steps