Runtime plane — advanced setup¶

Advanced Config is the same wizard as Basic setup with two extra steps inserted before the deploy step. Everything on those two steps is optional, so Advanced is not a harder path — it is the same path with more of it visible. This page is self-contained: the steps it shares with the Basic path are reproduced here, so there is no need to switch between them.

If you are not sure this is the path you want, see Choosing Basic or Advanced on the overview page. Work through Before you begin first — a cluster that meets the requirements, kubectl and helm access to it, and the Account Admin role in the portal.

Step 1 — Open the wizard and fill in Infrastructure Setup¶

1. Log in to the Trust3 AI portal.
2. In the left sidebar, click Settings.
3. In the Settings menu, click Runtime.

You are now on Runtime Environments. Any runtime planes you already have are listed here as cards, each showing its name, its type, a status badge such as Running, and when it last reported in. A fresh account normally shows one entry, Trust3 AI Cloud, which is the Trust3-hosted SaaS environment.

1. Click + Create New.

The Create Runtime Plane page opens on Infrastructure Setup. Set Configuration Mode to Advanced Config — the step indicator at the top grows from two steps to four, and the button at the bottom right changes from Generate to Next.

Fill in the left-hand column:

About the runtime name¶

This name becomes the Kubernetes namespace, so it has rules:

• 6 to 44 characters
• lowercase letters, numbers, and hyphens only
• must start and end with a letter or number

The ↻ icon next to the field generates a fresh suggestion. If you type a custom region, it must be at least 7 characters and use the same character set, so that the generated name stays a valid namespace.

Confirm the prerequisites¶

On the right-hand side is a checklist for the cloud provider you selected. Work through it and tick each item once it is true of your cluster.

Two helpers sit alongside the list:

• Download Script — downloads a script that carries out the preparation steps for you.
• View full details — opens step-by-step manual instructions for that one item.

When every box is ticked, the panel shows All prerequisites confirmed and the button at the bottom of the page becomes available.

Click Next.

Step 2 — Storage & Connectivity¶

Every field on this page is optional. A banner at the top says so, and it is accurate — you can click Next without filling in anything.

Secrets Provider¶

This decides where the credentials you type into collector configurations are stored. Every collector you configure later — database passwords, API tokens, agent endpoint passwords — uses whatever you choose here.

The cloud option shown depends on the cloud provider you selected on step 1. Each option has a Details link explaining it in place.

If you pick Kubernetes Secrets or a cloud secret manager, you also enter the name of the secret that holds the values.

Storage Settings¶

The bucket or container Trust3 uses for its own data — and, if you enable custom agent monitoring, the place agent traces are written to and read back from.

⚠ Required for custom agent monitoring — the AWS S3 Bucket Name is where agent traces are written and read back.

Persistent Storage¶

Where Trust3's own components keep data that must survive a pod restart.

⚠ Required for custom agent monitoring — the EFS Storage ID, with StorageClass Provisioning left on.

What Trust3 provisions when the toggle is on depends on the cloud:

DNS Management¶

This is what gives Trust3 services in your cluster real hostnames.

⚠ Required for custom agent monitoring — both the Domain Name / R53 Hosted Zone Name and the AWS R53 Hosted Zone ID; the trace endpoint's hostname is built from the domain.

A DNS setup guide link sits next to the section heading.

Ingress Settings¶

⚠ Required for custom agent monitoring — the AWS ACM ARN and the ALB Subnet IDs; without them the trace endpoint is never created. How traffic reaches Trust3 services from outside the cluster. On AWS this section is shown, and it needs the AWS Load Balancer Controller installed in the cluster — the link next to the heading says so.

Custom Docker Image Repository (optional)¶

For a full walkthrough of the private-registry case, see Custom ACR with Runtime.

Click Next.

Step 3 — Cloud Permissions¶

This step gives the runtime plane a cloud identity so it can reach the storage, DNS, and secret services you configured on step 2.

⚠ Required for custom agent monitoring — the IAM Role ARN, and its policy must include s3:* on your trace bucket.

The requirements are derived from your step 2 answers. If you left step 2 empty, there is nothing to do here. If you filled anything in, a banner at the top of the page tells you the identity is now required — for example, on AWS: IAM Role ARN is required because AWS service access is configured.

Everything you need is generated for you on the page: a suggested identity name, the exact commands to create it, and the exact permissions to attach. Both CLI and Console tabs are available for each block, and a Quick Reference panel on the right shows the values the commands were built from — identity name, runtime name, region, and hosted zone ID.

Click Generate.

Step 4 — Deploy¶

The Deploy step shows two commands.

The download command. Use the CURL tab, or the WGET tab if you prefer wget. It downloads a values.yaml for your runtime plane:

1
2
3

curl -fsSX GET https://<your-trust3-host>/runtime/runtime-plane/<id>/values/download \
  -H "x-pcloud-key: <your-api-key>" \
  -o values.yaml

The Helm command. It installs the runtime agent into your cluster, creating the namespace:

1
2
3
4
5
6
7

helm upgrade --install <runtime-name> https://<your-trust3-host>/runtime/helm/runtime-agent-1.0.0.tgz \
  --username trust3ai \
  --password <your-api-key> \
  --pass-credentials \
  --namespace <runtime-name> \
  --create-namespace \
  ...

Each block has two icons in its top-right corner:

• 📋 copy — copies the command, including the real credential values.
• 👁 eye — reveals the masked values on screen.

There is also a What this command does link next to each, if you want to know exactly what you are about to run.

Run the commands on your cluster¶

Open a terminal that is connected to your Kubernetes cluster — the one where kubectl is configured and working — and run the two commands in order, exactly as shown:

1. the curl (or wget) command, which writes values.yaml into your current directory
2. the helm upgrade --install command, which deploys the runtime agent

Check that kubectl is pointed at the right cluster before you start:

1

kubectl config current-context

Wait for the runtime agent to connect¶

Back in the portal, below the commands, you will see Waiting for Runtime Agent to connect…

You do not have to sit on this page. As the message says, you can close the window and finish later; the connection is established automatically once the commands have run.

Once the runtime agent pod is up and has called home, the status changes to connected.

To watch it from your side:

1

kubectl get pods -n <runtime-name>

You are looking for a runtime-agent-… pod in Running state.

Finish¶

1. Click Done.
2. A dialog appears — Don't lose access to your runtime — reminding you that these commands are how you reach the runtime plane via the instance CLI, and that without them you will have to regenerate access.
3. If you have saved the commands, tick I have saved the installation commands securely.
4. Click Leave Anyway.

Choose Stay on Page instead if you still need to copy something.

Verify¶

Go back to Settings → Runtime. Your new runtime plane should be listed with a Running status badge and a recent timestamp.

From the cluster side:

1

kubectl get pods -n <runtime-name>

What custom agent monitoring needs¶

If your reason for using Advanced Config is to monitor agents you built yourself, this is the checklist. Every item below is a prerequisite — the collector configuration will accept the toggle without them, but you will get no endpoint and no error.

The IAM statement the Cloud Permissions step generates for the bucket is exactly what is needed:

1
2
3
4
5
6
7
8

{
    "Effect": "Allow",
    "Action": "s3:*",
    "Resource": [
        "arn:aws:s3:::<your-bucket>",
        "arn:aws:s3:::<your-bucket>/*"
    ]
}

Then continue with Monitoring custom agents.