Skip to main content
Use the Infrastructure Skill with your local AI agent to prepare ECS or EKS deployment files and upgrade plans from current public docs.

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

​
Deployment Options

Choose the platform you will operate: See each platform’s prerequisites for provider constraints, cluster features, quotas, and version compatibility.

​
Getting Started

Preparation shared by both platforms:
  1. Choose your account/project, region, application hostname, and deployment model.
  2. Collect Runlayer-provided inputs: release pins, artifact access, authentication, and the catalog key.
  3. Prepare network and egress access for core services and selected features.
  4. If using Sentry Relay, prepare its credentials.
  5. Follow your platform’s ordered guide below.

ECS + Terraform

AWS identity and state → network and configuration → deploy → verify

Kubernetes

Cluster → external dependencies → workload identity → Operator deployment → verify

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

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

​
Capacity and Cost

Estimate infrastructure cost using your region, workload, availability target, database/cache capacity, NAT and data transfer, logging, and optional GPU services. For AWS, use the AWS Pricing Calculator. A successful proof of concept does not establish production throughput or availability; validate your expected workload and recovery procedures. Infrastructure cost is separate from Runlayer commercial pricing. Ask your Runlayer account team for commercial terms.

​
Operations

After verification, establish backup and restore, maintenance, and update/rollback procedures. See Shared Responsibility for ownership boundaries.