Next Steps

This page explains what your team needs to prepare before Ramain can run as a private, on-premises, or private-cloud deployment in your environment.

Ramain supports private deployments across major cloud providers. The examples below use AWS because the IAM role model is the most explicit, but the same operating model applies on Azure and Google Cloud through provider-equivalent identities, permissions, networking, and audit logs.

Choose a setup path

What the customer prepares

Before kickoff, Ramain needs the following inputs from your infrastructure and security teams:

• Cloud environment — AWS account, Azure subscription, or Google Cloud project where Ramain will run.
• Region and data residency — preferred deployment region and any data residency constraints.
• Deployment identity — an IAM role or provider-equivalent identity that Ramain or your approved CI/CD system can assume.
• Terraform state location — customer-owned state storage and locking, such as an encrypted S3 bucket with locking enabled.
• Network plan — VPC/VNet details, CIDR ranges, public/private subnet requirements, private connectivity needs, firewall rules, VPN, Direct Connect, ExpressRoute, or Cloud Interconnect requirements.
• DNS ownership — frontend and API domains, such as platform.<customer>.com and api.<customer>.com, or the internal DNS pattern your team wants Ramain to use.
• TLS certificates — ACM certificate access, approval for Ramain to request certificates, or the certificate process your team requires.
• KMS key — customer-managed encryption key ARN, or approval for Terraform to create a customer-owned key.
• Secret management — where application secrets are stored and how approved values are populated into the deployment.
• AgentCore Browser access — approval and IAM access for browser automation to run in the customer AWS account.
• Identity provider — SSO metadata and admin contacts for Entra ID, Okta, SAML, OIDC, or the provider your organization uses.
• Approval process — who reviews infrastructure changes, security controls, access grants, and production readiness.
• Operational contacts — escalation contacts for networking, identity, cloud platform, security, and application operations.
• Compliance requirements — logging, retention, encryption, key management, audit export, and backup requirements.

Standard path: via Ryvn

For the standard deployment path, Ramain uses Ryvn to generate a provider-native onboarding template.

Manual path: Terraform

The manual path is for customers whose infrastructure team must review and apply the infrastructure code directly.

In this path, Ramain provides Terraform and environment inputs for your team to review. Your team creates or approves the deployment identity, Terraform state location, network shape, encryption key, and DNS/certificate approach. Terraform then provisions the private Ramain environment in your cloud account.

In the current AWS Terraform setup, the backend runs as two ECS/Fargate services:

• API — receives HTTP and WebSocket traffic through the load balancer, handles authentication, serves application requests, and enqueues workflow jobs.
• Worker — runs privately with no load balancer route, consumes workflow jobs from ElastiCache, and writes workflow status, events, and results back to the database.

Both services use the same backend container image from customer ECR. The difference is the task command: the API starts the web server, while the worker starts the queue processor.

Users and frontend
        |
        v
Application Load Balancer
        |
        v
API service
        |
        +--> Aurora/PostgreSQL
        +--> ElastiCache Redis/Valkey queue
                  |
                  v
             Worker service
                  |
                  +--> Aurora/PostgreSQL
                  +--> AgentCore Browser / Bedrock

ElastiCache stays private inside the customer VPC. Only the API and worker ECS task security groups should be allowed to connect to Redis/Valkey.

AWS manual role reference

This section applies only to manual Terraform deployments on AWS.

For standard deployments via Ryvn, the cross-account IAM role is created automatically when the customer runs the CloudFormation template Ramain provides during onboarding. No manual IAM configuration is needed.

For manual Terraform, Ryvn runs in Ramain's AWS account and assumes a role in the customer's AWS account using AWS STS. Credentials are short-lived, issued per session, never stored, and logged in the customer's CloudTrail.

Ramain AWS account                    Customer AWS account
Ryvn Agent  ── sts:AssumeRole ──────► RamainDeployRole
OIDC identity                         Created by customer via Terraform

Trust policy

The trust policy allows only Ryvn's AWS account and deployment identity to assume the role. The ExternalId is unique per customer and helps prevent confused-deputy attacks.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowRyvnAgent",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<ryvn-account-id>:role/RyvnAgentRole"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "<customer-external-id>"
        }
      }
    }
  ]
}

<ryvn-account-id> and <customer-external-id> are supplied by Ramain when the Terraform module is handed over. They are unique per customer.

Permission boundary

The deployment role should include a permission boundary before any deployment policies are attached. This caps what the role can ever do, regardless of future policy changes.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyPrivilegeEscalation",
      "Effect": "Deny",
      "Action": [
        "iam:CreateUser",
        "iam:CreateAccessKey",
        "iam:AttachUserPolicy",
        "iam:PutUserPolicy",
        "iam:AddUserToGroup",
        "organizations:*",
        "account:*"
      ],
      "Resource": "*"
    }
  ]
}

The role can create and manage IAM roles scoped to the Ramain deployment. It cannot create IAM users, create static access keys, modify billing, or touch AWS Organizations.

Required AWS permission areas

The exact permissions are generated with the Terraform module and reviewed with the customer during onboarding. At a high level, the role needs access to provision and operate:

• VPC and networking — VPCs, subnets, security groups, route tables, NAT gateways, and VPC endpoints.
• Load balancing — application load balancers, target groups, listeners, TLS policies, and health checks.
• ECS and Fargate — clusters, API and worker services, task definitions, task roles, service updates, and execute-command settings where approved.
• ECR — container repositories, image pushes, image reads, lifecycle policies, and scan settings.
• RDS/Aurora PostgreSQL — database clusters or instances, subnet groups, parameter groups, snapshots, backups, and tags.
• ElastiCache Redis/Valkey — private cache subnet groups, replication groups, security groups, encryption settings, and access from approved ECS services.
• S3 and CloudFront — frontend static hosting, object encryption, bucket policies, CloudFront distributions, cache invalidations, and access controls.
• Route 53 and ACM — hosted zones, DNS records, certificate requests, validation, and tags.
• Secrets Manager and SSM — application secrets, parameters, runtime configuration, and approved operator sessions.
• KMS — customer-managed key usage for encryption, decryption, data keys, and key metadata.
• CloudWatch — logs, metrics, alarms, retention policies, and deployment observability.
• IAM — deployment-scoped roles, policies, and iam:PassRole for Ramain-managed ECS tasks and services.
• AgentCore Browser and Bedrock — browser automation and model access in the customer's AWS account, if enabled for the deployment.

KMS and encryption

The KMS key is customer-owned. Ramain-created infrastructure is granted permission to use the key for approved encryption operations.

The key is used for data at rest, including RDS/Aurora storage, Secrets Manager values, S3 objects, CloudWatch logs where configured, and Terraform state if state is stored in the customer account. AWS services decrypt data automatically only when the calling role and the KMS key policy allow it.

For example, when an ECS task starts, Secrets Manager can use the customer KMS key to decrypt an application secret and pass it to the task. If the customer removes that permission, the task can no longer read that encrypted secret.

AgentCore Browser

Ramain browser automation should run through AgentCore Browser in the customer's AWS account when that deployment mode is selected. The customer must enable or approve AgentCore Browser in the target region and grant the ECS task role the permissions needed to create and use browser sessions.

This replaces external browser-provider credentials such as Kernel API keys for customer private deployments. The target configuration is provider-based access through AWS IAM rather than a shared third-party API key.

How application updates are shipped

After infrastructure exists, application updates are shipped through the approved deployment pipeline:

Backend change -> build Docker image -> push to customer ECR -> update API and worker ECS task definitions -> update API and worker ECS services

Frontend change -> build static assets -> upload to customer S3 -> invalidate customer CloudFront

Terraform is only required when the infrastructure changes, such as networking, IAM, ECS service shape, database settings, domains, certificates, or encryption configuration.

Read next

• AWS Reference Architecture — deployment topology for the AWS private-cloud reference implementation.
• Operating Model — responsibility split between Ramain, Ryvn, and the customer.
• Security Posture — encryption, network isolation, IAM, and auditability.