Skip to main content
The architecture of a TrueFoundry compute plane is as follows:

This section is coming soon.

EncryptionPolicy to create and manage key for encryption:
Setting up TrueFoundry control plane on your own cloud involves creating the infrastructure to support the platform and then installing the platform itself.

Setting up Infrastructure

Requirements:

The requirements to setup control plane in each of the scenarios is as follows:
  • Billing and STS must be enabled for the AWS account.
  • Please make sure you have enough quotas for GPU/Inferentia instances on the account depending on your usecase. You can check and increase quotas at AWS EC2 service quotas
  • Please make sure you have created a certifcate for your domain in AWS Certificate Manager (ACM) and have the ARN of the certificate ready. This is required to setup TLS for the load balancer.
  • Postgres database with the following requirements:
    • Version: >= 13
    • Instance Types: db.t3.medium or db.t4g.medium
    • Storage: 20GB of type gp3 with autoscale enabled to 30GB
    • Encryption: Enabled
    • For PostgreSQL 17+: Set force_ssl parameter to 0 (off) in parameter group if you need to allow non-SSL connections (default is 1)
    • Security Group: Ensure RDS security group allows inbound traffic from EKS node security groups
  • S3 bucket to store the intermediate code while building the docker image.
  • Egress Access to TrueFoundry:
  • DNS: Domain for control plane and service endpoints. One endpoint to point to the control plane service (e.g., platform.example.com) and the other to point to the compute plane service (e.g., tfy.example.com/service1). The control-plane URL must be reachable from the compute-plane. The developers will need to access the TrueFoundry UI at the provided domain.
  • We will need a certificate ARN (for the domain provided above) to attach to the loadbalancer so as to terminate TLS traffic at the load balancer. This will allow the services we deploy on the cluster to be accessed via HTTPS. We recommend using AWS Certificate Manager to add TLS to the load balancer. You can read the instructions in Step 2 below on how to create the certificate in AWS Certificate Manager.
  • You need to have enough permissions on the AWS account to create the resources needed for the compute plane. Check this for more details. We usually recommend admin permission on the AWS account, but if you need the exact set of fine-grained permissions, you can check the list of permissions below:
Regarding the VPC and EKS cluster, you can decide between the following scenarios:
  1. The new VPC should will have a CIDR range of /20 or larger, at least 2 availability zones and private subnets with CIDR /24 or larger. This is to ensure capacity for ~250 instances and 4096 pods.
  2. If you want to use a smaller network range for your EKS cluster, TrueFoundry supports EKS custom networking as well.
  3. A NAT gateway will be provisioned to provide internet access to the private subnets.
  4. We should have egress access to public.ecr.aws, quay.io, ghcr.io, tfy.jfrog.io, docker.io/natsio, nvcr.io, registry.k8s.io so that we can download the docker images for argocd, nats, gpu operator, argo rollouts, argo workflows, istio, keda, etc.

Setting up control plane

TrueFoundry control plane infrastructure is provisioned using OpenTofu/Terraform. You can download the OpenTofu/Terraform code for your exact account by filling up your account details and downloading a script that can be executed on your local machine. To perform the below steps, you need to register an account on TrueFoundry and login to the platform.
1

Enable Deployment Feature in the Platform (Optional)

To enable the deployment feature which allows you to deploy services through the platform, you need to enable it;
  • In the left hand navigation, go to Settings then Platform Feature Visibility under Preferences
  • Click on Edit button. Then enable the toggle for Enable Deployment
  • Click on Save button.
This will enable the deployment feature in the platform and allow you to create either a control plane and compute plane.
2

Choose to create a new cluster or attach an existing cluster

Go to the platform section in the left panel and click on Clusters. Add the following value at the end of your URL &controlPlaneSetupEnabled=true. This will enable the control plane installation for you. You can click on Create New Cluster or Attach Existing Cluster depending on your use case. Read the requirements and if everything is satisfied, click on Continue.
3

Get Domain and Certificate ARN

We will need two domains and certificate ARNs to point to the load balancer that we will be creating in the next step. Let’s say you have a domain like *.services.example.com - we will be creating a DNS record with this later in Step 6. We recommend using AWS Certificate Manager (ACM) to create the certificate since it’s easier to manage and renew the certificates automatically. To generate a certificate ARN, please follow the steps below. If you are not using AWS Certificate Manager, you can skip this step and continue to the next step.
  1. Navigate to AWS Certificate Manager in the AWS console
  2. Request a public certificate
  3. Specify your domain (e.g., *.services.example.com)
  4. Choose DNS validation (recommended)
  5. Add the CNAME records provided by ACM to your DNS provider. Follow the official AWS guide for DNS validation. For detailed steps on adding CNAME records, see AWS documentation on DNS validation
  6. Wait for the certificate to change to “Active” status (this may take 30 minutes or longer)
  7. Copy the certificate ARN for the next step (format will be like: arn:aws:acm:region:account:certificate/certificate-id)
4

Fill up the form to generate the opentofu/terraform code

A form will be presented with the details for the new cluster to be created. Fill in with your cluster details. Click Submit when done
The key fields to fill up here are:
  • Cluster Name - A name for your cluster.
  • Region - The region where you want to create the cluster.
  • Network Configuration - Choose between New VPC or Existing VPC depending on your use case.
  • Authentication - This is how you are authenticated to AWS on your local machine. It’s used to configure OpenTofu/Terraform to authenticate with AWS.
  • S3 Bucket for OpenTofu/Terraform State - OpenTofu/Terraform state will be stored in this bucket. It can be a preexisting bucket or a new bucket name. The new bucket will automatically be created by our script.
  • Control Plane Configuration - Control plane URL and the database details. You can chose between PostgreSQL on kubernetes or Managed PostgreSQL (RDS) or Existing PostgreSQL configuration depending on your use case.
  • Load Balancer Configuration - This is to configure the load balancer for your cluster. You can choose between Public or Private Load Balancer, it defaults to Public. You can also add certificate ARNs and domain names for the load balancer but these are optional.
Enter the domain and the certificate ARN that we got in previous step in the form as shown below.
5

Copy the curl command and execute it on your local machine

You will be presented with a curl command to download and execute the script. The script will take care of installing the pre-requisites, downloading OpenTofu/Terraform code and running it on your local machine to create the cluster. This will take around 40-50 minutes to complete.
6

Create DNS Record

Once the script is executed, create the DNS record for the control plane url. To get the load balancer IP address, you can check the kubernetes service of type LoadBalancer in the istio-system namespace. You can run the following command to get the IP address.
This will give you the login screen to the control plane through which you can login via the same credentials used to register the tenant. Create a DNS record in your route 53 or your DNS provider with the following details
7

Attach the compute plane to the control plane

We will need to attach the same cluster as compute plane so that we can manage it form the platform. For this, you need to go to the platform section in the left panel and click on Clusters. Click on Attach Existing Cluster and fill in the details of the control plane cluster. The key fields to fill up here are:
  • Cluster Name - The name of the cluster.
  • Cluster Addons - Unselect all the addons as we have installed them while bringing up the control plane.
  • Network Configuration - Networking configuration of the control plane cluster.
  • Authentication - This is how you are authenticated to AWS on your local machine. It’s used to configure OpenTofu/Terraform to authenticate with AWS.
  • S3 Bucket for OpenTofu/Terraform State - OpenTofu/Terraform state will be stored in this bucket. It can be a preexisting bucket or a new bucket name. You can use the same bucket that we used for the control plane and change the bucket key to be used for OpenTofu/Terraform state file.
  • Platform Features - This is to decide which features like BlobStorage, ClusterIntegration, ParameterStore, DockerRegistry and SecretsManager will be enabled for your cluster. To read more on how these integrations are used in the platform, please refer to the platform features page.
8

Copy the curl command and execute it on your local machine

You will be presented with a curl command to download and execute the script. The script will take care of installing the pre-requisites, downloading OpenTofu/Terraform code and running it on your local machine to create the cluster. This will take around 40-50 minutes to complete.
9

Verify the cluster is showing as connected in the platform

Once the script is executed, the cluster will be shown as connected in the platform.
10

Enable the deployment of workloads on the cluster from the platform

To enable the deployment feature which allows you to deploy services through the platform, you need to enable it;
  • In the left hand navigation, go to Settings then Platform Feature Visibility under Preferences
  • Click on Edit button. Then enable the toggle for Enable Deployment
  • Click on Save button.
11

Start deploying workloads to your cluster

You can start by going here

FAQ

Set the tags variable in the generated OpenTofu/Terraform code to a map of your tags:
This works for both new and existing control plane clusters — applying only adds or updates tags in place; no resources are recreated. For an existing cluster, run tofu plan (or terraform plan) first and confirm the diff is tag-only before applying.Tags flow through two layers so every AWS resource TrueFoundry provisions gets consistent labels:To suppress the built-in truefoundry-* audit tags without affecting your own tags, set:
Yes, you can use cert-manager to add TLS to the load balancer and not use AWS Certificate Manager. You can follow the instructions here to install cert-manager and add TLS to the load balancer.
Yes, please consult this guide to add your own certificate and key files to the load balancer.
The TrueFoundry control plane supports SSL connections to PostgreSQL. You can configure SSL by setting the DB_SSL_MODE environment variable in your truefoundry-values.yaml.Supported DB_SSL_MODE values:SSL certificate environment variables:Scenario 1: Encrypted connection without certificate validation (no-verify)This is the simplest option for AWS RDS. It encrypts the connection but skips server certificate validation.
truefoundry-values.yaml
Scenario 2: Encrypted connection with certificate validation (require)This mode encrypts the connection and validates the server certificate. You must provide the AWS RDS CA bundle so the application can verify the RDS server certificate.Download the RDS CA bundle and create a Kubernetes Secret:
You can download the RDS CA bundle from the AWS documentation.
Then configure truefoundry-values.yaml to mount the CA bundle and set DB_SSL_CA_PATH:
truefoundry-values.yaml
Upgrade the Helm release to apply the changes:
TrueFoundry ships with a built-in monitoring stack that includes Grafana dashboards for the control plane. To enable it, add the following to your truefoundry-values.yaml:
truefoundry-values.yaml
Then upgrade the Helm release to apply the changes:
Once enabled, platform admins can access the Grafana dashboard at:
  • Replace <your-truefoundry-control-plane-url> with your actual control plane domain (e.g., app.example.com) and <tenant-name> with your TrueFoundry tenant name provided during onboarding.
  • Only users with the admin role can access this endpoint.
  • Make sure to include the trailing / at the end of the URL.
  • If you already have Prometheus or VictoriaLogs in your cluster, you can point the monitoring stack to them using externalServices instead of installing new instances.
For the full configuration reference, see the Control Plane Monitoring guide.
Remove infrastructure managed by Terraform, and Kubernetes-created resources (for example load balancers and Karpenter nodes).
1

Connect to the EKS cluster

2

Delete LoadBalancer services

3

Delete Karpenter NodePools

Make sure the nodes are gone (if they are stuck, please delete them manually from the EC2 instances. This is only for the karpenter nodes):
4

From the folder with your generated OpenTofu/Terraform code

Overview

This section provides ready-to-use Terraform snippets for waf.tf that remediate the following findings on an AWS WAFv2 Web ACL:Each section below is a standalone snippet — copy the block you need directly into your waf.tf. Snippets that add a rule { ... } block are meant to be inserted inside the existing aws_wafv2_web_acl.this resource, alongside the other rules; snippets that define a full resource block can be dropped anywhere in the file.
The data_protection_config block requires AWS provider >= 5.98.0. Pin this in your versions.tf:
These snippets reference 5 variables that must exist in your variables.tf: waf_app_name, waf_app_environment, waf_team, waf_it_owner_email, waf_geo_allowed_country_codes. See Required variables at the bottom of this page.

Optional trusted IP set

Defines a reusable IP set of trusted addresses. It’s only created when var.waf_ip_allowlist is non-empty, and is referenced later by the allowlist rule. Skip this snippet if you don’t need an IP allowlist.

Web ACL skeleton and default action (WAF-016)

This is the top-level aws_wafv2_web_acl resource. All rule { ... } snippets below are inserted inside this resource’s body. The default action is kept as allow — non-matching traffic passes through, and the rules that follow block bad traffic explicitly.
GIS flagged this as informational and suggested a deny-by-default (default_action { block {} }) alternative. Switching to deny-by-default requires an explicit allow rule that covers all trusted traffic first (otherwise you break the app), so it’s intentionally left as allow here. If you want to move to deny-by-default later, add a catch-all allow rule at priority 0 before flipping this.

Managed rule: Known Bad Inputs

Blocks requests matching AWS’s curated list of known malicious request patterns (e.g. exploitation of Log4j, credential stuffing patterns). Set at priority 0.

Managed rule: SQL Injection Rule Set

Applies AWS’s managed SQL injection detection ruleset across the request. Set at priority 1.

Managed rule: Amazon IP Reputation List

Blocks traffic from IP addresses that AWS’s threat intelligence has flagged as sources of botnets, scanners, or other malicious activity. Set at priority 2.

Managed rule: Common Rule Set (OWASP baseline)

Applies AWS’s Core Rule Set (broad OWASP-style protections). Two rule-level overrides are included: SizeRestrictions_BODY is set to allow (so large but legitimate request bodies aren’t blocked), and NoUserAgent_HEADER is set to count (monitor requests without a User-Agent header, rather than blocking them). Set at priority 3.

Rate limiting on /api/ traffic (Custom-Rule-85)

Remediates the Critical finding by changing the previous count {} action to block {}, and scoping the rate limit to requests whose path starts with /api/ — so UI, health check, and static asset traffic isn’t rate-limited alongside API calls. Set at priority 4.

Trusted IP allowlist rule

Allows traffic from the IP set defined earlier to bypass the rules that follow it. Only rendered when the allowlist IP set was created. Set at priority 5.
This rule sits at priority 5after the managed rule groups (priorities 0–3) and the rate-limit rule (priority 4). Allowlisted IPs are still subject to those earlier rules. If allowlisted IPs should bypass everything, move this rule to priority 0 and renumber the rest accordingly.

Managed rule: Anonymous IP List (WAF-009)

Blocks requests originating from VPNs, Tor exit nodes, proxies, and hosting providers — sources commonly used to mask the true origin of malicious traffic. Set at priority 6.
override_action is set to none {} so the rule group’s own block action applies immediately. If you’d rather observe traffic before enforcing, change this to count {} first.

Standalone SQL injection block rule (Custom-Rule-85)

A dedicated SQLi detection rule scoped to the request body, independent of the managed SQLi rule set above. Deployed in count {} (monitor-only) mode at priority 7 — check CloudWatch metrics and sampled requests for false positives before switching the action to block {}.

Standalone XSS block rule (Custom-Rule-85)

A dedicated cross-site scripting detection rule scoped to all query string arguments. Also deployed in count {} (monitor-only) mode at priority 8 — switch to block {} once validated against real traffic.

Geo-location restriction (Custom-Rule-84)

Blocks any request whose source country is not in the approved list, using a not_statement wrapped around a geo_match_statement. Configure the approved countries via var.waf_geo_allowed_country_codes. Set at priority 9.

Data protection / field redaction (WAF-021)

Substitutes the values of sensitive request headers — authorization, cookie, x-api-key, x-auth-token — before they’re written to any WAF logging destination (CloudWatch Logs, sampled requests, etc.). This block goes directly inside aws_wafv2_web_acl.this, alongside the default_action and rules.
The request body is intentionally not redacted here, to preserve forensic detail in logs. If full-body redaction is required later, add:

Logging (WAF-013, unchanged)

Creates the CloudWatch log group and logging configuration for the Web ACL. This was already compliant and is included here unchanged for completeness — the log group name must be prefixed with aws-waf-logs-, which AWS enforces.

Associating the Web ACL with an ALB

Associates the Web ACL with an Application Load Balancer. Only needed if the ALB was created outside of the AWS Load Balancer Controller — pass its ARN via var.waf_associate_alb_arn; otherwise leave that variable empty and skip this snippet.

Required variables

Add these to variables.tf if they don’t already exist (used for Custom-Rule-37 mandatory ownership/application tagging, and the geo-block rule):
  • waf_app_name
  • waf_app_environment
  • waf_team
  • waf_it_owner_email
  • waf_geo_allowed_country_codes
These are merged, along with any caller-supplied tags, into the local.waf_required_tags local referenced throughout the snippets above, and applied to every WAF resource.