There are steps in this guide where TrueFoundry team will have to be involved. Please reach out to support@truefoundry.com to get the credentials
Key Components
To install the control plane on your generic Kubernetes infrastructure, you need to install the following components:- TrueFoundry Control Plane (Shipped as a helm chart called
truefoundry) - PostgreSQL Database (Managed or Self-Hosted with PostgreSQL >= 13)
- Blob Storage (S3, Minio, or any other S3 compatible storage)
PostgreSQL SSL Configuration: For PostgreSQL 17+, SSL must be disabled in the database configuration. This can typically be done by setting SSL-related parameters to false or 0 in your database configuration.
Compute Requirements
TrueFoundry ships as a helm chart that has configurable options to deploy the control plane according to your needs. The compute requirements change based on the scale of the number of users and requests. Here are a few scenarios that you can choose from based on your needs.- Small (Dev)
- Medium (Prod)
- Large (Prod)
The small tier is recommended for development purposes. Here all the components are deployed on Kubernetes and in non HA mode (single replica). This is suitable if you are just testing out the different features of TrueFoundry.
This setup brings up 1 replica of the services and is not highly-available. It
can enable you to test the features but we do not recommend this for
production mode.
| Component | CPU | Memory | Storage | Min Nodes | Remarks |
|---|---|---|---|---|---|
| Helm-Chart (Control Plane components) | 4 vCPU | 8GB | 60GB Persistent Volumes (Block Storage) On Kubernetes | 2 Pods should be spread over min 2 nodes | |
| Postgres (Deployed on Kubernetes) | 0.5 vCPU | 0.5GB | 5GB Persistent Volumes (Block Storage) On Kubernetes | PostgreSQL version >= 13 IOPS: Default (suitable for dev/testing) | |
| Blob Storage (S3 Compatible) | 20GB |
Prerequisites for Installation
- Kubernetes Cluster: K8s cluster 1.27+ with minimum 4vCPU and 8GB RAM.
-
Support for dynamic provisioning of storage for PVC (such as local storage provisioners, Longhorn, OpenEBS, or other on-premises storage solutions) and support for exposing the control plane dashboard via:
- Ingress controller (e.g., Nginx Ingress Controller), or
- Istio service mesh
-
Domain to map the ingress of the Control Plane dashboard along with certificate for the domain.
This Domain will be referred as Control Plane URL in our documentation.
-
Egress access to TrueFoundry Central Auth Server:
https://auth.truefoundry.comhttps://login.truefoundry.com
- Tenant Name, Licence key, and image pull secret from TrueFoundry team. If you have not registered yet, please visit TrueFoundry to register.
-
PostgreSQL database (version >= 13). We recommend managed PostgreSQL database for production environments. For instance requirements, refer to the Compute Requirements section.
In case you do not have a managed database for testing purposes, set
devModeto true in the values file to spin up a local PostgreSQL database. - Blob Storage to store artifacts and logs (S3, Minio, or any other S3 compatible storage).
Installation Instructions
1
Setup Blob Storage
You need to configure S3-compatible blob storage (such as Minio, AWS S3, or any other S3-compatible storage) to store artifacts, logs, and AI Gateway request logs.
Using Minio (Self-Hosted S3-Compatible Storage)
Using Minio (Self-Hosted S3-Compatible Storage)
If you’re using Minio or another S3-compatible storage solution, you’ll need to provide the following configuration:
- Bucket Name: Name of the S3-compatible bucket
- Region: Region identifier (can be any string for Minio)
- Access Key ID: Access key for authentication
- Secret Access Key: Secret key for authentication
- Endpoint URL: Full URL to your S3-compatible storage endpoint
Make sure your blob storage is accessible from your Kubernetes cluster and note down all credentials and endpoints for the next steps.
2
Setup PostgreSQL Database
Ensure you have a PostgreSQL database (version >= 13) set up and accessible from your Kubernetes cluster.
Using Managed PostgreSQL
Using Managed PostgreSQL
For production environments, we strongly recommend using a managed PostgreSQL service:
- Create a PostgreSQL instance with the specifications from the Compute Requirements section
- Create a database named
truefoundry(or your preferred name) - Create a user with full permissions on this database
- Note down the following details:
- DB_HOST: Database hostname or IP address
- DB_PORT: Database port (usually 5432)
- DB_NAME: Database name
- DB_USERNAME: Database username
- DB_PASSWORD: Database password
Using PostgreSQL on Kubernetes (Dev/Testing Only)
Using PostgreSQL on Kubernetes (Dev/Testing Only)
For development or testing purposes only, you can deploy PostgreSQL on Kubernetes:
- Set
devMode.enabled: truein the values file (shown in a later step) - The PostgreSQL will be automatically deployed with the control plane
PostgreSQL SSL Configuration: For PostgreSQL 17+, SSL must be disabled in the database configuration. This can typically be done by setting SSL-related parameters to false or 0 in your database configuration.
3
Add Helm Repository
Add the ArgoCD helm repository:
4
Install ArgoCD
Install ArgoCD if not already installed:
5
Create Kubernetes Secrets
We will create two secrets in this step:
- Store the License Key and DB Credentials
- Store the Image Pull Secret
Create Kubernetes Secret for License Key and DB Credentials
Create Kubernetes Secret for License Key and DB Credentials
We need to create a Kubernetes secret containing the licence key and database credentials that you configured in the previous step.Apply the secret to the Kubernetes cluster (Assuming you are installing the control plane in the
Use the PostgreSQL database credentials from the “Setup PostgreSQL Database” step above.
truefoundry-creds.yaml
truefoundry namespace)Create Kubernetes Secret for Image Pull Secret
Create Kubernetes Secret for Image Pull Secret
We need to create a Image Pull Secret to enable pulling the truefoundry images from the private registry.Apply the secret to the Kubernetes cluster (Assuming you are installing the control plane in the
truefoundry-image-pull-secret.yaml
truefoundry namespace)6
Create HelmChart Values File
Create a values file as given below and replace the following values:
- Control Plane URL: URL that you will map to the control plane dashboard (e.g.,
https://truefoundry.example.com) - Tenant Name: Tenant name provided by TrueFoundry team
- Blob Storage Configuration: Use the bucket name, region, access keys, and endpoint URL from the “Setup Blob Storage” step above
truefoundry-values.yaml
7
Install TrueFoundry Control Plane
Install the TrueFoundry control plane using the OCI helm chart:
8
Configure Load Balancer and DNS
- Get the IP address of the load balancer:
- Point your control plane domain to this IP address in your DNS provider.
- Configure TLS certificates for the load balancer to terminate TLS traffic.
9
Verify Installation
- Wait for all pods to be running:
- Access the control plane at your configured URL and login with the same credentials used to register the tenant.
Setting Up Compute Plane
After installing the control plane, you need to set up a compute plane where your applications will run.Compute Plane InstallationFor complete instructions on setting up the compute plane on your generic cluster, please refer to the Generic Compute Plane Setup guide.
Important: Setting Up Control Plane as a Compute PlaneWhen installing the control plane, you need to set up the control plane cluster as a compute plane managed by TrueFoundry itself. This allows you to manage control plane upgrades and configuration through the TrueFoundry UI.To enable this, you MUST disable all add-ons to avoid conflicts with existing cluster components. The add-ons that should be disabled include:
- ArgoCD - Already installed separately in Step 2
- Argo Workflows - Conflicts with control plane installation
- Argo Rollouts - Conflicts with control plane installation
- Istio - Conflicts if already present
- Cert Manager - Conflicts if already present
- Prometheus - Conflicts if already present
- KEDA - Conflicts if already present
Configuring Node Pools for TrueFoundry
To enable node pools in your cluster with TrueFoundry, follow these steps:Node Pool Label Configuration
Ensure all nodes in your cluster have a node pool label. This label should follow the format<nodepool-label-key>: <nodepool-name>.
Example: If your node pool label key is truefoundry.com/nodepool, each node should have a label like truefoundry.com/nodepool: <nodepool-name>.
To configure the label key in TrueFoundry:
- Click on edit in the Cluster and then toggle on the Advanced Fields section.
- Under Node Label Keys, fill in the Nodepool Selector Label with your chosen label key.
GPU Node Pool Configuration
To deploy workloads on GPU nodes, assign labels to GPU node pools indicating the GPU type. Label Key:truefoundry.com/gpu_type
Possible Values:
- A10G, A10_12GB, A10_24GB, A10_4GB, A10_8GB
- A100_40GB, A100_80GB
- H100_80GB, H100_94GB, H200
- L4, L40S
- P100, P4, T4, V100
truefoundry.com/gpu_type: A10_24GB.
Adding Domain for Workloads
- Add a separate domain for hosting workloads (can be a wildcard domain).
- Point the domain to the load balancer IP address.
- Configure TLS certificate for the domain.
- Add the domain in the TrueFoundry platform UI.