Commit 6305ea1e authored Apr 21, 2026 by Adebayo Adesanya Committed by Mikhail Mazurskiy Apr 22, 2026

Adopt "GitLab Relay (KAS)" naming

parent 5a44c2e1

content/handbook/engineering/architecture/design-documents/multi_platform_gateway/_index.md

+1 −1

Original line number	Diff line number	Diff line
		@@ -607,7 +607,7 @@ However, using the GitLab Helm Chart provides the opportunity to standardise the

		Google Cloud Platform (GCP) offers a [Google Kubernetes Engine (GKE) Gateway](https://docs.cloud.google.com/kubernetes-engine/docs/how-to/migrate-ingress-gateway) that uses Envoy under the hood. An alternative to offering our own gateway using the [open-source Envoy Gateway](https://gateway.envoyproxy.io/) in the GitLab Helm Chart would be to use this out of the box; however that would not provide the replicability and dogfooding that we are intended to achieve to ensure the deployment is suitable across all platforms, and not only GitLab.com.

		The GCP Implementation does not support TCP nor gRPC routes. TcpRoutes are requirement to expose GitLab's SSH daemon, and gRPC will provide flexibility for future functionality, such as KAS (Kubernetes Agent Server) features.
		The GCP Implementation does not support TCP nor gRPC routes. TcpRoutes are requirement to expose GitLab's SSH daemon, and gRPC will provide flexibility for future functionality, such as GitLab Relay (KAS) features.

		### Alternative Proxy Options

content/handbook/engineering/architecture/design-documents/workspaces/_index.md

+1 −1

Original line number	Diff line number	Diff line
		@@ -33,7 +33,7 @@ This IDE runs a server and an optional client which is used to connect remotely.
		1. GitLab Workflow extension: An extension which adds GitLab features to VS Code.
		1. GitLab Agent for Kubernetes(agentk): A component for solving any GitLab<->Kubernetes integration tasks.
		1. GitLab Agent for Workspaces(agentw): A component for solving any GitLab<->Workspace integration tasks.
		1. GitLab Agent Server(KAS): A server running alongside GitLab Rails application to facilitate connections between different GitLab Agents(agentk, agentw) and GitLab and vice versa.
		1. GitLab Relay (KAS): A server running alongside GitLab Rails application to facilitate connections between different GitLab Agents(agentk, agentw) and GitLab and vice versa.

		## Overview

content/handbook/engineering/architecture/design-documents/workspaces/architecture_kubernetes_setup.md

+2 −2

Original line number	Diff line number	Diff line
		@@ -54,7 +54,7 @@ rectangle "Kubernetes" {
		rectangle "GitLab" {
		rectangle "Rails"
		rectangle "Postgres"
		rectangle "GitLab Agent Server(KAS)" as KAS
		rectangle "GitLab Relay (KAS)" as KAS
		}

		AgentK --> KAS : "1: Initiate reconciliation loop"
		@@ -128,7 +128,7 @@ NOTE: The below diagram only reflects the HTTP traffic flow. SSH traffic flow ne
		rectangle "GitLab" {
		rectangle "Nginx/HAProxy" as ReverseProxy
		rectangle "Rails"
		rectangle "GitLab\nAgent\nServer\n(KAS)" as KAS
		rectangle "GitLab\nRelay\n(KAS)" as KAS
		}

		actor "User"

content/handbook/engineering/architecture/design-documents/workspaces/decisions/018_remove_gitlab_workspaces_setup.md

+2 −2

Original line number	Diff line number	Diff line
		@@ -18,7 +18,7 @@ We need a way to simplify the setup without burdening the user with buying/manga

		We will eliminate the need for GitLab Workspaces Proxy in the user's Kubernetes cluster by moving
		the logic of proxying traffic into the appropriate workspace to a server hosted and managed by GitLab
		as part of GitLab Agent Server(KAS).
		as part of GitLab Relay (KAS).
		GitLab Agent for Workspaces(agentw) would be injected inside each workspace which will initiate a bi-directional gRPC connection
		with the above server. When user traffic arrives at the server, it will be authenticated, authorized
		and proxied into the appropriate workspace using the bi-directional gRPC connection established earlier.
		@@ -43,4 +43,4 @@ Workspaces traffic would be a long persistent connection and thus it would becom

		We considered [routing the user traffic for a workspace through a new service - GitLab Workspaces Server](https://gitlab.com/gitlab-org/gitlab/-/issues/519307#note_2365114887)
		to keep all the domain logic in a service owned by the team but decided against it because we did not see any value over
		keeping the logic in GitLab Agent Server/GitLab Agent especially because that project is a modularized monolith for such architectures outside of our Rails monolith.
		keeping the logic in GitLab Relay (KAS) or GitLab Agent especially because that project is a modularized monolith for such architectures outside of our Rails monolith.