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.Runlayer Operator
Kubernetes (EKS or GKE)Self-host on a cluster you manage — operator, dependencies, and
RunlayerInstanceECS + Terraform
Serverless ContainersSimpler AWS deployment with ECS Fargate (no Kubernetes required)
Choosing Your Deployment Method
Runlayer Operator — Kubernetes (EKS or GKE)
Best for:- Self-hosting on a cluster you provision and operate (EKS or GKE)
- One or many isolated tenants via
RunlayerInstance - Runlayer Deploy (
MCPServer) on the same cluster
- Kubernetes 1.29+ (EKS or GKE)
- Helm 3.8+, kubectl with install rights for CRDs
- IRSA (EKS) or Workload Identity (GKE) for cloud API access — Workload identity
- On AWS with Bedrock: IAM permissions + Anthropic Bedrock use-case form (see below)
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.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
Architecture Comparison
ECS + Terraform Architecture
Component Comparison
Security Considerations
Runlayer Operator (EKS / GKE)
- Network policies for pod isolation
- Pod security contexts
- Per-workload ServiceAccounts with IRSA or GKE Workload Identity — see Workload identity
- Encrypted secrets in the platform namespace (operator never creates Secret data)
- Encrypted node volumes for audit-log spool
- TLS at the Ingress / load balancer you operate
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
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
Runlayer Operator (EKS / GKE)
Cost: Your Kubernetes control plane, node pools, Postgres, Redis, load balancers, and optional feature resources (streams, buckets, AgentCore). See External dependencies. Runlayer does not publish a fixed “EKS module” bill — capacity is yours to size.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
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
Kubernetes (recommended self-host)
- Meet Kubernetes prerequisites on EKS or GKE.
- Provision external dependencies (Postgres, Redis, IAM).
- Collect Runlayer-provided inputs.
- Follow the Runlayer Operator install guide.
- Map cloud permissions via Workload identity.
ECS (AWS without Kubernetes)
1
Prepare Prerequisites
Install Terraform / AWS CLI and choose a domain
2
Configure Settings
Set required Terraform inputs — see ECS Terraform inputs
3
Deploy
Follow ECS + Terraform
4
Verify
Smoke-test login, connectors, and policies
Next Steps
Runlayer Operator
Install the operator on EKS or GKE
External dependencies
Postgres, Redis, streams, buckets (AWS + GCP samples)
ECS + Terraform
Deploy serverless containers on AWS ECS
Egress requirements
Outbound hosts self-hosted fleets must reach