Trinity Platform Release Notes – Version 4.8.0

Neutrinos Platform Product Release Notes
, ,
1

:rocket: Trinity Platform Release Notes – Version 4.8.0

:rocket: We’re excited to announce Trinity 4.8.0, a major update focused on infrastructure modernization and expanded cloud provider support. This release introduces the following key changes:

  1. Kong Ingress Controller OSS & Istio mTLS Migration – Migration from the community NGINX Ingress Controller to Kong Ingress Controller OSS as our primary edge proxy, combined with full Istio mTLS integration to enforce Zero-Trust networking and encrypt all inter-service communication across the cluster.
  2. AWS (EKS) Vendor Support – Full support for Amazon EKS as a cloud provider, enabling organizations on AWS to use the complete Trinity platform on EKS clusters.
  3. Marketplace Chart Updates (Reels, Alpha & Data Fabric) – Kong Ingress Controller support added to the Reels, Alpha, and Data Fabric Helm charts, available as new marketplace packages.

:counterclockwise_arrows_button: Part 1: Kong Ingress Controller OSS & Istio mTLS Migration

:pushpin: Overview

This release introduces a major architectural upgrade to our cluster ingress and service mesh infrastructure. We have successfully migrated from the community NGINX Ingress Controller to Kong Ingress Controller OSS as our primary edge proxy. In tandem with this migration, we have fully integrated Istio mTLS to enforce Zero-Trust networking and encrypt all inter-service communication across the cluster.

This strategic upgrade enhances our platform’s scalability, hardens our internal network security posture, and provides a more robust foundation for advanced API management, authentication, and traffic control.

:wrench: What Changed

  • All application Ingress resources (n-apps-ui, n-apps-api, trinity, identity-server, etc.) now use ingressClassName: kong.
  • 20+ NGINX-specific annotations refactored to Kong CRD equivalents (including gRPC and WebSocket support).
  • Security headers (X-Frame-Options, etc.) injected via Kong’s response-transformer plugin instead of NGINX configuration snippets.
  • Helm templates refactored to toggle between Kong and NGINX via a unified Values.ingress.ingressClass flag.
  • Kong unlocks future plugin capabilities (Rate Limiting, OIDC, request transformation) without architectural debt.
  • Cleaner layer-7 traffic metrics via Kong’s native Prometheus integration.

:gear: NGINX to Kong Upgrade Migration (Customer / Operator Steps)

You will use the provided repository for this release. Kong is the default ingress in the charts; the only manual value changes required are during rollback (to switch back to NGINX).

:white_check_mark: Prerequisites

  • Helm 3.x installed and configured with access to the target cluster.
  • Console Helm charts from the provided repository (Kong is already configured as default).
  • New section — Istio configuration (keep disabled): New Istio-related keys have been added to the values file for future use. These must remain false for this release:
    • istio.enabled: false (top-level)
    • istiod: and base: sections (Istio control plane and base CRD configuration)
    • global.istioNamespace: monitoring
    • trinity.istio.enabled: false
    • identity-server.istio.enabled: false
    • identity-server-v2.istio.enabled: false


      Istio service mesh integration is not included in this release and will be available in an upcoming release. Do not enable these values.

  • New section — kong-ingress: A new kong-ingress section has been added to the values file. When enabling Kong, populate this section with your image repositories/tags, proxy LoadBalancer IP, and annotations. Refer to values-sandbox.yaml for a fully configured example. Key sub-sections:
    • controller — Kong Ingress Controller image and settings
    • gateway — Kong Gateway image, admin service, and proxy (LoadBalancer) configuration
    • podAnnotations — Required annotations for sidecar compatibility


      For rollback to NGINX, set kong-ingress.enabled: false and ingress-nginx.enabled: true.

  • ingressClassName updated across values file: As part of the Kong migration, ingressClassName (or ingressClass) has been changed from nginx to kong at multiple places: trinity.ingress, cert-manager, identity-server.ingress, identity-server-v2.ingress, and trinityLicenseAgent frontend/backend ingress sections. Ensure these are set to kong when upgrading, or revert to nginx when rolling back.
  • Controller cluster: Use the upgrade command below.
  • Runtime cluster: If using project namespaces with Ingress resources, run the script in Section 3 after Kong is deployed.

:desktop_computer: 1. Controller Cluster: Upgrade to Kong and Rollback

:rocket: 1.1 Upgrade Controller cluster to Kong (install / set Kong)

Important — Update deployment chart names: The following environment variables in your values file must be updated to use the new Kong-compatible chart names:

RUNTIME_INIT_CHART_NAME: "console-runtime-init-kong-support"
SIGNOZ_CHART_NAME: signoz-chart-kong-support 
CLICKHOUSE_CRD_FILE_NAME: clickhouse-crds
API_APP_DEPLOY_CHART_NAME: n-apps-api-kong
UI_APP_DEPLOY_CHART_NAME: n-app-ui-kong
ENABLE_ISTIO_FOR_APPLICATIONS: false
ENABLE_ISTIO_FOR_ENVIRONMENT: false

Ensure these values are set in your values-sandbox.yaml (under the Trinity deployments environment section) before running the upgrade.

Ensure the following values are set to Kong in your values file before running the upgrade:

  • Set Kong on and NGINX off:
    • kong-ingress.enabled: true
    • ingress-nginx.enabled: false
  • Set ingressClassName (or ingressClass where applicable) to kong for all relevant sub-charts:
    • trinity – trinity.ingress.ingressClassName: kong
    • trinityDeployments – trinity.trinityDeployments.deployment.env.INGRESS_CLASS: kong
    • identity-server – set to kong (this chart uses ingressClass):
      • identity-server.ingress.ingressClass: kong
    • identity-server-v2 – set to kong (this chart uses ingressClass):
      • identity-server-v2.ingress.ingressClass: kong
    • cert-manager:
      • cert-manager.ingressClassName: kong
      • trinity.certmanager.ingressClassName: kong (cert-manager settings inside the trinity values scope)
    • kibana:
      • kibana.ingress.className: kong
    • Trinity License Agent (if enabled under trinity values):
      • trinity.trinityLicenseAgent.trinityLicenseAgentFrontend.ingress.ingressClassName: kong
      • trinity.trinityLicenseAgent.trinityLicenseAgentBackend.ingress.ingressClassName: kong

From the console-controller-init chart directory, run:

helm dependency update .

helm upgrade --install console-monitoring . \
  --namespace monitoring --create-namespace \
  --values values-sandbox.yaml

Verify: IngressClass kong exists, and Trinity, Identity Server, and other apps are reachable via Kong.

:locked: 1.2 Verify Istio PeerAuthentication

NOTE: Steps 1.2, 1.3, and 1.4 are only required when Istio is enabled in the values file (istio.enabled: true). If Istio is not enabled, skip to the Rollback section.

After the initial upgrade, verify that the Istio PeerAuthentication resource has been created in the trinity namespace:

kubectl get peerauthentication -n trinity

You should see output similar to:

NAME           MODE         AGE
trinity-mtls   PERMISSIVE   <age>

If the PeerAuthentication resource is not present, run the helm upgrade command again:

helm upgrade --install console-monitoring . \
  --namespace monitoring --create-namespace \
  --values values-sandbox.yaml

This is expected — the first upgrade installs the Istio base CRDs, and a second upgrade is required for resources that depend on those CRDs (such as PeerAuthentication) to be created successfully. After the second run, verify again with kubectl get peerauthentication -n trinity to confirm the resource exists.

:label: 1.3 Verify Istio Injection Label on the Trinity Namespace

Verify that the trinity namespace has the istio-injection=enabled label:

kubectl get namespace trinity --show-labels

You should see output similar to:

NAME      STATUS   AGE     LABELS
trinity   Active   <age>   istio-injection=enabled,kubernetes.io/metadata.name=trinity

If the istio-injection=enabled label is not present, apply it manually:

kubectl label namespace trinity istio-injection=enabled --overwrite

This label is required for Istio to automatically inject the Envoy sidecar proxy into pods created in the trinity namespace, enabling mTLS for inter-service communication.

:counterclockwise_arrows_button: 1.4 Restart Deployments in the Trinity Namespace

Once the istio-injection=enabled label is confirmed on the namespace and the PeerAuthentication resource exists, restart all deployments in the trinity namespace so that the Istio Envoy sidecar is injected into every pod:

kubectl rollout restart deployment -n trinity

Wait for all deployments to become ready, then verify that each pod now has the Envoy sidecar container (istio-proxy) running alongside the application container.

:fast_reverse_button: Rollback (optional) – Controller cluster to NGINX

NOTE: Do this only when something went wrong and you need to revert to NGINX.

NOTE: When rolling back, ensure you also revert to the required images that were used in your earlier NGINX-based deployment (e.g. the NGINX Ingress Controller image and any other component images from the previous release).

Revert all the values mentioned above in Section 1.1 back to NGINX — set ingress-nginx.enabled: true, kong-ingress.enabled: false, and change all ingressClassName / ingressClass values from kong to nginx. Then run:

helm upgrade --install console-monitoring . \
  --namespace monitoring --create-namespace \
  --values values-sandbox.yaml

Verify: IngressClass nginx is in use and applications are reachable via NGINX.

:desktop_computer: 2. Runtime Cluster: Upgrade to Kong and Rollback

:rocket: 2.1 Upgrade Runtime cluster to Kong

Ensure the following values are set to Kong in your runtime values file (values.yaml):

  • Set Kong on and NGINX off:
    • kong-ingress.enabled: true
    • ingress-nginx.enabled: false
  • Set ingressClassName to kong for all relevant sub-charts:
    • Trinity License Agent Frontend – trinityLicenseAgent.trinityLicenseAgentFrontend.ingress.ingressClassName: kong
    • Trinity License Agent Backend – trinityLicenseAgent.trinityLicenseAgentBackend.ingress.ingressClassName: kong
    • identity-server (if enabled on runtime) – identity-server.ingress.ingressClassName: kong

From the console-runtime-init chart directory, run:

helm dependency update .

helm upgrade --install console-monitoring . \
  --namespace monitoring --create-namespace \
  --values values.yaml

Then run the project-namespace Ingress update script (Section 3) so that all project namespaces (from the database) have their Ingress resources updated to use Kong.

:fast_reverse_button: Rollback (optional) – Runtime cluster to NGINX

NOTE: Do this only when something went wrong and you need to revert to NGINX.

NOTE: When rolling back, ensure you also revert to the required images that were used in your earlier NGINX-based deployment (e.g. the NGINX Ingress Controller image and any other component images from the previous release).

Revert the values in your runtime values file back to NGINX — set ingress-nginx.enabled: true, kong-ingress.enabled: false, and change all ingressClassName / ingressClass values from kong to nginx. Then run:

helm upgrade --install console-monitoring . \
  --namespace monitoring --create-namespace \
  --values values.yaml

:scroll: 3. Runtime Cluster: Update Ingress & Istio in Project Namespaces (Existing Applications Only)

:scroll: 3a. Update Ingress in Project Namespaces (application-ingress-controller-migation.sh)

NOTE: This step is only required for customers who have existing deployed applications on the Runtime cluster. If this is a fresh installation with no previously deployed applications, skip this section.

This step performs two actions on all existing project namespaces:

  1. Kong Ingress annotations — Updates all Ingress resources in project namespaces to use the Kong ingress class with the appropriate annotations (replacing NGINX-specific configuration).
  2. Istio injection labels — Applies the istio-injection=enabled label to project namespaces so that the Envoy sidecar proxy is automatically injected into application pods, enabling mTLS.

We provide a script that fetches all projects from the database (these projects are used as namespaces in the cluster) and updates all Ingress resources in those namespaces to the correct ingress class with the appropriate annotations, and enables Istio sidecar injection for each namespace.

Script name and location: The script is named application-ingress-controller-migation.sh and is supplied in the console-runtime-init (runtime-init) charts folder under scripts.

What the script does:

  • – Prompts the user for database credentials.
  • – Connects to the database and retrieves the list of projects that correspond to namespaces in the cluster.
  • – Prompts the user for the target ingressClassName (for example: kong or nginx).
  • – For each such namespace, finds the Ingress resources and updates them to the target ingress class and required annotations.
  • – Generates a detailed report file in the same folder where the script is executed, summarizing success and failure for each namespace and ingress.

Customer steps:

  1. – Ensure your kubectl current context is set to the Runtime cluster.
  2. – Ensure you have permission to list and update Ingress resources in the project namespaces.
  3. – Navigate to the folder where the script is provided (e.g. the console-runtime-init / scripts folder).
  4. – Run the script, for example: ./application-ingress-controller-migation.sh
  5. – When prompted, enter your database credentials.
  6. – When prompted, enter the target ingress class name (kong during migration, nginx if you are rolling back).
  7. – Wait for the script to complete updating Ingress in the discovered namespaces.
  8. – Verify in the cluster that Ingress resources in project namespaces have the expected ingressClassName and that traffic is flowing correctly.
  9. – Review the generated report file in the current folder for a summary of processed namespaces, ingress objects, and their status.
  10. – When all ingress updates are complete and validated, run the ./application-database-ingress-update.sh script once. Also give required permission. This script updates the relevant application records in the database to reflect the new ingress configuration.

Report format (example):

================= INGRESS UPDATE REPORT =================
Execution Time : <timestamp>
Cluster        : <cluster-name>
Total Namespaces Processed : <count>

---------------------------------------------------------
Namespace : namespace-1
---------------------------------------------------------
Summary
  Total Ingress Processed : 2
  Success                 : 2
  Failed                  : 0

Ingress Update Details
  - ingress-name-1 : SUCCESS
  - ingress-name-2 : SUCCESS


---------------------------------------------------------
Namespace : namespace-2
---------------------------------------------------------
Summary
  Total Ingress Processed : 2
  Success                 : 2
  Failed                  : 0

Ingress Update Details
  - ingress-name-1 : SUCCESS
  - ingress-name-2 : SUCCESS


=========================================================
OVERALL SUMMARY
=========================================================
Namespaces Processed : 2
Total Ingress        : 4
Total Success        : 4
Total Failed         : 0
=========================================================
STATUS : SUCCESS
=========================================================

Rollback: If you roll back to NGINX (Section 2), run the same script again and choose nginx as the target ingressClassName so that Ingress resources in project namespaces are switched back to the NGINX ingress class and annotations.

NOTE: Only do this if you have executed step 3a.

:locked: 3b. Runtime Cluster: Enable Istio Injection in Project Namespaces (istio-injection-migration.sh)

NOTE: This step is only required when ENABLE_ISTIO_FOR_ENVIRONMENT is set to true in your runtime environment configuration. If Istio is not enabled for your runtime environment, skip this step.

After the Ingress migration (Step 3a) is complete, run the Istio injection migration script to enable Istio sidecar injection for all existing project namespaces and perform a rolling restart of their deployments. This ensures that the Envoy sidecar proxy is injected into every application pod, enabling mTLS for inter-service communication across project namespaces.

Script name and location: The script is named istio-injection-migration.sh and is supplied in the scripts folder of the repository.

What the script does:

  • – Prompts the user for database credentials (host, port, database name, schema, user, password).
  • – Connects to the database and retrieves all non-deleted project namespaces.
  • – For each matching namespace:
    • Labels the namespace with istio-injection=enabled.
    • Performs a kubectl rollout restart on each deployment so the Istio Envoy sidecar is injected.
  • – Processes namespaces in parallel (up to 5 at a time) for faster execution.
  • – Generates a detailed report file (ISTIO_MIGRATION_REPORT.md) in the current directory summarizing the label status, deployment restart results, and any failures for each namespace.

Customer steps:

  1. – Ensure your kubectl current context is set to the Runtime cluster.
  2. – Ensure you have permission to label namespaces, list/patch/restart deployments in project namespaces, and access the database.
  3. – Navigate to the scripts folder.
  4. – Run the script: ./istio-injection-migration.sh
  5. – When prompted, enter your database credentials (host, port, database name, schema, user, password).
  6. – Wait for the script to process all namespaces. Progress is logged to the console as each namespace is processed.
  7. – Review the generated report file (ISTIO_MIGRATION_REPORT.md) in the current folder for a summary of each namespace’s label status, deployment restart results, and overall status.
  8. – Verify in the cluster that project namespace pods now have the istio-proxy sidecar container running alongside the application container.

Report format (example):

============= ISTIO INJECTION MIGRATION REPORT ==============
Execution Time : <timestamp>
Cluster        : <cluster-name>
Total Namespaces Processed : <count>
==============================================================

---------------------------------------------------------
Namespace : namespace-1
---------------------------------------------------------
Summary
  Istio Label             : SUCCESS
  Total Deployments       : 2
  Success                 : 2
  Failed                  : 0

Deployment Update Details
    - deployment-1 : SUCCESS
    - deployment-2 : SUCCESS

---------------------------------------------------------
Namespace : namespace-2
---------------------------------------------------------
Summary
  Istio Label             : SUCCESS
  Total Deployments       : 1
  Success                 : 1
  Failed                  : 0

Deployment Update Details
    - deployment-1 : SUCCESS


==============================================================
OVERALL SUMMARY
==============================================================
Namespaces Processed : 2
Namespace Label Failed : 0
Total Deployments    : 3
Total Success        : 3
Total Failed         : 0
==============================================================
STATUS : SUCCESS
==============================================================

NOTE: Only run this step after the Ingress migration script (Step 3a) has been completed and validated.

:clipboard: Summary

Step Cluster Action
1 Controller Upgrade: From console-controller-init directory run helm upgrade --install with values-sandbox.yaml (see Section 1.1). Verify PeerAuthentication (Section 1.2), Istio injection label (Section 1.3), and restart deployments (Section 1.4). Rollback: Update values to NGINX (ingress-nginx.enabled: true, kong-ingress.enabled: false, ingressClassName: nginx everywhere), then run the same helm command.
2 Runtime Upgrade: From console-runtime-init directory run helm upgrade --install with your values file (repo defaults to Kong). Rollback: Update values to NGINX, then run helm upgrade without Kong overrides; revert project-namespace Ingresses if the script was used.
3a Runtime (Existing applications only) Run ./application-ingress-controller-migation.sh (provided in the console-runtime-init / scripts folder). Updates Ingress resources in project namespaces to the Kong ingress class and annotations.
3b Runtime (Existing applications only) Run ./istio-injection-migration.sh (provided in the scripts folder). Labels project namespaces with istio-injection=enabled and performs a rolling restart of all deployments to inject the Istio Envoy sidecar.

For exact value paths and script names, refer to the value files in this repository and the script documentation shipped with the release.

:cloud: Part 2: AWS (EKS) Vendor Support

:pushpin: Overview

This release adds Amazon EKS (Elastic Kubernetes Service) as a supported cloud provider alongside AKS, GKE, and OKE. All existing Trinity workflows—environments, namespaces, asset build & deployment, application lifecycle (scale, restart, logs), domains, vaults, secret sync (AWS Secrets Manager), storage, and alerts—work on EKS the same way as other providers.

AWS authentication uses IRSA or Pod Identity (no service account key file upload required).

:white_check_mark: Prerequisites

  • EKS cluster with IRSA or Pod Identity configured for the Trinity Service Account.
  • Kubeconfig with access to the target EKS cluster.
  • For secret sync: secretsmanager:GetSecretValue permission on the Trinity IAM role.
  • Controller cluster: Associate OIDC provider (IRSA) or install eks-pod-identity-agent addon (Pod Identity); create IAM role with trust policy for the Trinity Service Account; annotate SA with eks.amazonaws.com/role-arn (IRSA only).
  • Runtime cluster: Create an EKS Access Entry for the Trinity IAM role and associate the required access policy.

:memo: New Configuration Sections in Values File

The following new sections have been introduced in the values file (values-sandbox.yaml). Please update your values file accordingly:

  1. Istio sections (keep disabled): New Istio-related keys added for future use. These must remain false for this release:
    • istio.enabled: false (top-level)
    • istiod: and base: sections (Istio control plane and base CRD configuration)
    • global.istioNamespace: monitoring
    • trinity.istio.enabled: false
    • identity-server.istio.enabled: false
    • identity-server-v2.istio.enabled: false

      Istio service mesh integration will be available in an upcoming release. Do not enable these values.

  2. kong-ingress section: Configures the Kong Ingress Controller and Gateway deployment. Populate with your image repositories/tags, proxy LoadBalancer IP, and annotations. Key sub-sections: controller, gateway, podAnnotations. Refer to values-sandbox.yaml for a fully configured example. For rollback to NGINX, set kong-ingress.enabled: false and ingress-nginx.enabled: true.

  3. ingressClassName updated: Changed from nginx to kong at multiple places: trinity.ingress, cert-manager, identity-server.ingress, identity-server-v2.ingress, and trinityLicenseAgent frontend/backend ingress sections. Revert to nginx when rolling back.

:key: IRSA vs Pod Identity (quick reference)

IRSA EKS Pod Identity
How it works OIDC proves which SA is calling AWS EKS links SA to IAM role via association
Service Account Annotate with eks.amazonaws.com/role-arn No annotation; use create-pod-identity-association
Cluster requirement OIDC provider in IAM eks-pod-identity-agent addon

For detailed step-by-step commands, refer to the AWS EKS IRSA Setup and AWS EKS Pod Identity Setup command reference documents shipped with this release.

:new_button: What’s New for Users

  • Environment initialization: Choose AWS as the cloud provider when creating a new environment. Upload your Kubernetes config file; the service account file step is skipped for AWS.
  • Asset deployment: Run build and deployment for assets against AWS/EKS environments—same steps as other clouds, with the correct cluster and namespace resolution.
  • Applications & pods: Scale deployments, restart workloads, stream pod logs, and inspect running resources on EKS from the familiar application screens.
  • Namespaces & projects: Create and manage namespaces tied to AWS environments; use CRS and domain flows where your projects require them.
  • Vault configuration: Configure and list vaults for EKS clusters from the vault configuration screen.
  • Secret sync: Sync secrets from AWS Secrets Manager into EKS project namespaces using the existing sync-secret flow.
  • Storage: Use storage classes, PVCs, and storage operations in EKS environments as you would for AKS or GKE.
  • Alerts & monitoring hooks: Continue using alert and namespace-related features with AWS selected as the environment provider.

:up_arrow: Upgrade & Migration

  • New deployments: Deploy Trinity using the updated charts and select AWS when initializing environments.
  • Existing deployments: No changes are required for existing AKS, GKE, or OKE environments. EKS support is additive.
  • Database: No mandatory database migrations for enabling EKS. Use any release-specific SQL scripts as documented for your version.

:package: Part 3: Marketplace Chart Updates (Reels, Alpha & Data Fabric)

:pushpin: Overview

As part of the Kong Ingress Controller migration, the Reels, Alpha, and Data Fabric Helm charts have been updated to use Kong as the default ingress. These updated charts are available as new packages in the Neutrinos Marketplace.

Reels

The Reels platform has been migrated from NGINX Ingress Controller to Kong Ingress Controller OSS. Kong is now the default ingress in the Reels charts, with all NGINX-specific annotations refactored to Kong CRD equivalents across services (reels-fe, reels-manager, mdm-service, integration-service, cms-service, audit-service, process-executor, mdm-cron-service).

Marketplace package name: Reels (v1.0.2)

Alpha

The Alpha platform Helm chart has been updated to integrate Kong Ingress Controller OSS as the supported edge ingress. External traffic is routed through Kong using global.ingress.ingressClassName: kong and Kong-specific configuration. The chart renders KongPlugin resources for rate limiting, CORS, and security headers via Kong’s response-transformer plugin.

Marketplace package name: alpha-helm-deployment (v1.0.13)

Data Fabric

The Data Fabric platform Helm chart has also been updated to integrate Kong Ingress Controller OSS as the supported edge ingress. External traffic is routed through Kong using Kong-specific ingress class configuration.

Marketplace package name: data-fabric (v1.2.9)

:ship: Deployment

Deploy the updated Reels, Alpha, and Data Fabric charts from the Neutrinos Marketplace using the package names above. Kong Ingress Controller must be installed and configured in the target cluster before deploying these packages.

:spouting_whale: Docker Images

The following images are updated in this release and are used across the Kong migration, AWS EKS support, and marketplace chart updates:

Release Branch: release/4.8.0
Registry: neutrinos.azurecr.io

# Repository Name Docker Image Tag
1 trinity-frontend (UI) neutrinos.azurecr.io/trinity/trinity-frontend/ui 26.03.4.8.0
2 trinity-frontend (API) neutrinos.azurecr.io/trinity/trinity-frontend/api 26.03.4.8.0
3 trinity-orchestrator neutrinos.azurecr.io/trinity/trinity-orchestrator 26.03.4.8.0
4 trinity-db-operations neutrinos.azurecr.io/trinity/trinity-db-operations 26.03.4.8.0
5 trinity-assets-orchestrator neutrinos.azurecr.io/trinity/trinity-assets-orchestrator 26.03.4.8.0
6 trinity-deployments neutrinos.azurecr.io/trinity/trinity-deployments 26.03.4.8.0
7 trinity-promscale-connector neutrinos.azurecr.io/trinity/trinity-promscale-connector 26.03.4.8.0
8 trinity-alerts-base-app neutrinos.azurecr.io/trinity-utils/alerts-base-app 26.03.4.8.0
9 trinity-alerts-email-service neutrinos.azurecr.io/trinity/trinity-alerts-email-service 26.03.4.8.0
10 trinity-app-logs neutrinos.azurecr.io/trinity/trinity-app-logs 26.03.4.8.0

:clipboard: Release Summary

This release adds Kong Ingress Controller OSS as the default edge proxy (replacing NGINX), Amazon EKS as a first-class cloud provider in Trinity Stack, and updated Reels (reels-cms-kong) and Alpha (alpha-helm-deployment) marketplace packages with Kong support—covering the full operational surface: asset build and deployment, application lifecycle (deploy, scale, logs, restarts), environments and namespaces, domains, CRS, vaults, AWS Secrets Manager sync, storage, and alerts. Authentication for EKS stays simple with IRSA or Pod Identity and no uploaded service account key files.

1 Like