Skip to main content
The operator does not create cloud infrastructure. Provision these out-of-band, then wire hosts, ARNs, and bucket names into Secrets / RunlayerInstance. Samples below are illustrative — adapt to your modules, naming, and security baselines. They are not a required Runlayer Terraform product. Cluster contract: Kubernetes prerequisites. Identity: Workload identity.

Required for every tenant

Map into CR: spec.database.*, spec.redis.*, Secrets runlayer-db / runlayer-redis.

Postgres — AWS sample

Requirements: private subnets, SSL (rds.force_ssl), backups/PITR per your policy, allow node/pod CIDRs to 5432.

Postgres — GCP sample

ExtendDB connection budget

Enabling components.extendDB (see Runlayer Operator) puts a second consumer on the instance’s Postgres host (spec.database.host): the adapter’s init Job creates two dedicated logical databases (catalog + data) and a dedicated role, and every ExtendDB replica opens its own connection pool against both. Budget max_connections as:
  • extenddb_replicas defaults to 2 (components.extendDB.replicas, HA by default — every enable_db MCPServer on the instance depends on this one adapter).
  • pool_per_replica is set by upstream extenddb.toml, not by the operator in v1 — check your pinned image’s default or sample pg_stat_activity for usename = the dedicated ExtendDB role (the operator sets that role; see below) under load before sizing.
  • admin_headroom covers psql/migrations/the reset Job’s bootstrap connection.
Worked example (illustrative numbers — confirm your own app and pool sizes): app holds ~40 connections, 2 ExtendDB replicas × a 10-connection pool × 2 DBs = 40, plus 20 headroom → max_connections ≥ 100. Scaling replicas to 3 raises the ExtendDB term to 60. If you need more headroom than the default allows: on Aurora, raise max_connections via the DB cluster parameter group (or scale ACUs — serverless v2 derives a higher default from larger ACU). On Cloud SQL, raise it via the max_connections database flag. Prefer capping the dedicated ExtendDB role over sizing alone, so a mis-scaled or runaway ExtendDB can’t starve the app:
The role defaults to extenddb_<customerId>_app, but the prefix is sanitized (lowercased, anything outside [a-z0-9_] becomes _, truncated to 55 chars) — don’t assume the literal name; confirm it with \du or the app-db Secret. Set the limit comfortably above extendDB_replicas × pool_per_replica × 2 (60 covers the 40-connection worked example above plus the per-replica catalog-check readiness probe, which also connects as this role) so a healthy adapter is never throttled — the limit is a backstop against a mis-scaled or leaking adapter, not the primary sizing lever.

Redis — AWS sample

Wire spec.redis.tls: true and password Secret when auth is enabled.

Redis — GCP sample


Optional: AI Watch binary packages

Needed so the platform can cache and serve AI Watch installers (RUNLAYER_DOWNLOAD_TOKEN from Runlayer-provided inputs).

AWS sample

After config: restart backend/worker → Check now (or wait for scheduled discovery).

Optional: audit stream + consumers

Backend can publish audit events to a stream. Audit consumer and SIEM export are independent consumers of that stream (each needs its own EFO/subscription, checkpoint store, DLQ, and IAM). Kinesis SIEM export and audit consumer: replicas ≤ 1.

GCP Pub/Sub sample (audit)

Publish permission for {instance}-backend and {instance}-worker on the topic.

AWS Kinesis sample (audit + SIEM on one stream)

Each consumer needs its own EFO consumer, DynamoDB checkpoint table, and DLQ bucket. SIEM also needs a destination bucket (or cross-account write role).
Attach audit_publish to {instance}-backend / -worker. Attach kinesis_consumer["audit"] to {instance}-audit-consumer. Attach kinesis_consumer["siem"] + siem_destination_write to {instance}-siem-export (or use a customer-owned assume-role for the destination bucket). Wire into:

Optional: session materializer

AWS sample (hook-events stream + materializer deps)

Attach session_materializer to {instance}-session-materializer. Attach hook_events_publish (payload read plus Session media write) to {instance}-backend / -worker. On GKE, grant the same object create on the payload GCS bucket, limited to the session-media/ prefix with an IAM condition.

Optional: agents (AgentCore)

On AWS, preferred path is Bedrock AgentCore (customer-provisioned). The operator does not create the runtime.

AWS sample (runtime + invoke policy)

Image URI is typically Customer Distribution ECR, e.g. 088332244652.dkr.ecr.<region>.amazonaws.com/runlayer/agent-sandbox:<version> — confirm the pin with Runlayer.
Attach invoke_agentcore to the IRSA roles for {instance}-backend and {instance}-worker.
sandboxMode: k8s is advanced (separate controller + gVisor/Kata) — see Runlayer Operator.

Other common buckets (AWS / GCS)

Put names in runlayer-app (or CR fields where documented): Mirror with GCS IAM for GKE.

Shared GCP project

When any component uses streamBackend: pubsub:

Next