Skip to main content

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

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)

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

​
Runlayer Operator - 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 RunlayerInstance resources
  • AWS IAM role integration for Bedrock access
  • External PostgreSQL and Redis
  • 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)
  • Anthropic first-time-use form submitted for the AWS account (for AWS deployments)
Anthropic model access. Anthropic requires a use case details form before its models can be invoked in an AWS account, plus an accepted model agreement. You need this when the deployment invokes Anthropic models on Bedrock — typically BEDROCK_ENABLED=true (Runlayer Assistant platform inference and optional Bedrock agent models). With BEDROCK_ENABLED=false, Runlayer Assistant binds an org AI provider instead; skip this step unless you also enable Bedrock inference elsewhere (for example BEDROCK_ANTHROPIC_MODELS_ENABLED for custom agents).The backend does both for you at startup and on login, in the account the Bedrock calls come from, using the model-access IAM permissions your deployment grants. Four settings describe the deployment on the form — BEDROCK_MODEL_ACCESS_COMPANY_NAME (defaults to Runlayer, the operator of the software making the calls), BEDROCK_MODEL_ACCESS_COMPANY_WEBSITE, BEDROCK_MODEL_ACCESS_INDUSTRY and BEDROCK_MODEL_ACCESS_INTENDED_USERS. Override them if you run this install yourself. They are never derived from your data: the form is submit-once, so a guessed answer would be permanent.Set BEDROCK_AUTO_MODEL_ACCESS=false to turn this off and do it by hand instead: Bedrock console → Model catalog → any Anthropic model → Submit use case details. Do the same if your deployment role predates the model-access permissions — the backend logs exactly which actions it is missing. AWS accepts the form once per account, or once at your AWS Organization’s management account, which member accounts inherit.Deploying outside the US? Also set RUNLAYER_ASSISTANT_BEDROCK_MODEL to your geography’s inference profile, for example au.anthropic.claude-opus-4-6-v1 in ap-southeast-2. The risk-categorization explainer follows BEDROCK_REGION on its own and uses Claude Haiku 4.5 outside the US, so the Anthropic form above covers it; only set RISK_CATEGORIZATION_MODEL if you want a different model, and pick one served in your Region. If Bedrock rejects the primary model it falls back to Amazon Nova Lite, which needs no access request.Access takes up to 15 minutes to propagate. Until it does — or if this is skipped entirely — Bedrock-backed agents fail with Model use case details have not been submitted for this account; see troubleshooting for the CLI checks and Region caveats.

​
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 (Operator)

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

​
Runlayer Operator

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

​
Getting Started

1

Choose Your Method

Select the deployment method that best fits your needs and requirements
2

Prepare Prerequisites

Install required tools and set up accounts/credentials
3

Configure Settings

Set up domain names, certificates, and configuration values
4

Deploy

Follow the specific deployment guide for your chosen method
5

Verify

Test the deployment and configure initial users and policies

​
Next Steps

EKS + Terraform

Deploy Kubernetes infrastructure on AWS EKS

ECS + Terraform

Deploy serverless containers on AWS ECS

Runlayer Operator

Deploy the application on Kubernetes