Armory CD-as-a-Service Architecture

Learn how Armory Continuous Deployment-as-a-Service works and how its key components orchestrate continuous deployment to your Kubernetes clusters.

How CD-as-a-Service works

CD-as-a-Service is a centralized control plane that utilizes flexible promotion constraints to safely deploy software and/or config changes across multiple clusters, environments, and/or regions.

CD-as-a-Service uses secure, logicless Remote Network Agents to access privately networked resources and Kubernetes clusters via ServiceAccounts. You do not need to upgrade agents for new features since business logic is encapsulated in the CD-as-as-Service control plane.

Remote Network Agents connect to CD-as-a-Service to establish gRPC via HTTP/2 connections secured with TLS and OIDC client credentials. You don’t need to open any ports to grant CD-as-a-Service access to your Kubernetes clusters or privately networked resources.

How CD-as-a-Service Works
  1. You render your Kubernets manifests using the tools you want. You build and publish your containers where and how you want, from DockerHub to a private registry on your network.
  2. You create a CD-as-a-Service deployment config file in which you define your deployment: canary and/or blue/green strategy; traffic shaping; deployment constraints such as manual judgments; external automation using webhooks; and retrospective analysis. You include the path to your Kubernetes manifests in the deployment config file. CD-as-a-Service can deploy any Kubernetes object that you define in your Kubernetes manifest.
  3. You start your deployment by sending the deployment config file to CD-as-a-Service using the Armory CLI, which you can run locally or in a Docker container. You can trigger deployments automatically from any CI system. If you’re using GitHub, Armory provides a GitHub Action for triggering deployments from your GitHub workflow.

The CD-as-a-Service control plane executes the deployments with constraints defined in your deployment config file, converting Kubernetes deployment objects into CD-as-a-Service managed ReplicaSets, handling traffic management and scaling. Remote Network Agents integrate with internal tools by securely relaying network calls and using their configurable ServiceAccount credentials to communicate with your clusters API.

Then monitor your deployment’s progress through the UI or CLI.

Key components

CD-as-a-Service control plane

The control plane is the set of services comprising the CD-as-a-Service platform. This control plane utilizes Remote Network Agents to talk to your networked resources such as Kubernetes APIs, Jenkins, and Prometheus, as well as external services like New Relic and Datadog.

Remote Network Agent (RNA)

The RNA is a logicless network relay that enables CD-as-a-Service to integrate with privately networked resources such as Jenkins, Prometheus, and Kubernetes clusters. For Kubernetes, the CD-as-a-Service control plane uses an RNA’s ServiceAccount credentials to automatically register the cluster the RNA is installed in as a deployment target. Once you install the RNA in your cluster, you don’t need to update it beyond security updates since deployment logic is encapsulated in CD-as-a-Service’s centralized control plane.

See the Remote Network Agent overview for details.

Agent Hub

Agent Hub routes deployment commands to RNAs and caches data received from them. Agent Hub does not require direct network access to the RNAs since they connect to Agent Hub through an encrypted, long-lived gRPC HTTP2 connection. Agent Hub uses this connection to send deployment commands to the RNA for execution.

Command Line Interface (CLI)

The CLI is the primary means of interacting with CD-as-a-Service. You can use the CLI directly or with machine-to-machine credentials to automate deployments in your CI system.

Armory distributes the CLI as native binaries (amd64 and arm64) for Linux, Mac, and Windows as well as a Docker image.

See CLI for details.

Cloud Console (UI)

Cloud Console is the browser-based UI for CD-as-a-Service. You can visually monitor and interact with your deployments on the Deployments screen. If you’re an Admin, you can use the Configure screens to perform tasks such as:

  • Configuring integrations with external services such as Prometheus, New Relic, and Datadog
  • Creating machine-to-machine credentials
  • Creating secrets
  • Configuring RBAC
  • Inviting users
  • Monitoring your Remote Network Agents


The following network endpoints are used for communication into Armory CD-as-a-Service:

DNS Port Protocol Description 443 TLS enabled gRPC over HTTP/2
TLS version 1.2
Remote Network Agent Hub connection; Agent Hub relays network traffic to privately networked resources such as Kubernetes APIs, Jenkins, or Prometheus, through Remote Network Agent (RNA) connections. Agent Hub does not require direct network access to the RNAs since they connect to Agent Hub through an encrypted, long-lived gRPC HTTP/2 connection. 443 HTTP over TLS (HTTPS)
TLS version 1.2
Armory REST API; Clients connect to these APIs to interact with Armory CD-as-a-Service. 443 HTTP over TLS (HTTPS)
TLS version 1.2
OIDC Service; The Open ID Connect (OIDC) service is used to authorize and authenticate machines and users. The Remote Network Agents, Armory Continuous Deployment (Spinnaker) plugin, and other services all authenticate against this endpoint. The service provides an identity token that can be passed to the Armory API and Agent Hub. 443 HTTP over TLS (HTTPS)
TLS version 1.2
Cloud Console; The browser-based UI for Armory CD-as-a-Service
* 443 HTTP over TLS (HTTPS)
TLS version 1.2
Preview Service; Creates a temporary public preview link to deployed services for testing; routes traffic to exposed services through Agent Hub plus Remote Network Agents.

All network traffic is encrypted while in transit.

Encryption in transit is over HTTPS using TLS encryption. When using Armory-provided software for both the client and server, these connections are secured by TLS 1.2. Certain APIs support older TLS versions for clients that do not support 1.2.

Encryption at rest uses AES256 encryption.

Last modified July 13, 2023: (5e051be)