One-click deploy

Deploy apps and agents to your Kubernetes in one click

The person who built the app or the agent presses Deploy. Behind that button, every deploy is a Git commit that your Argo CD syncs to your Kubernetes, the way your platform team wants it done.

Who clicks, and what happens next

1.A project member clicks Deploy
Any member of the project except viewers can deploy one app, an agent or a whole domain to the environment they pick. They can also ask the assistant in the console, which shows a confirmation card before anything runs.
2.Flightroom commits to Git
The environment's manifests and the app's Helm values go into your repositories as a commit. If the commit fails, nothing is deployed.
3.Argo CD syncs the cluster
Your Argo CD applies the commit. The app answers on its own URL in that environment, with a TLS certificate.

Deploy ships code that is already on its branch. When the base branch is protected, an AI-written change reaches it through a pull request and your engineers' review first. See how apps and agents are built.

What an app or an agent gets on deploy

An agent is an app: a service that reasons with a model and calls your systems. It deploys exactly like any other service, and each one gets the same four things in every environment.

A namespace per environment

Dev, UAT, production and any custom environment each run in their own Kubernetes namespace, so a test never touches what customers use.

Config and secrets per environment

ConfigMaps and Secrets are managed in the console and reach the app as environment variables. An agent gets its model API key this way, with a different key per environment if you want one.

Its own URL, with TLS

An HTTPRoute puts the app on its path under the environment's host. cert-manager issues the certificate, HTTP redirects to HTTPS, and HTTPS answers carry HSTS.

Health checks from the template

Liveness and readiness probes point at the health paths the template already exposes, so Kubernetes knows when the app is up from the first deploy.

How a deploy flows

Console
Someone deploys an app, an agent or a whole domain to an environment.
Git
The configuration repo and the applications repo get a commit with the manifests and Helm values.
Argo CD
ApplicationSets turn each environment and each app into an Application, synced automatically.
Namespaces
Each environment runs in its own Kubernetes namespace.
Gateway API
A Gateway per environment host, an HTTPRoute per app, TLS from cert-manager.

Configuration repository

One folder per environment, holding its Namespace, ConfigMaps, Secrets and Gateway.

dev/
  namespace.yaml
  configMaps/*.yaml
  secrets/*.yaml
  gateway.yaml

Applications repository

One branch per environment, with a Helm values file per app and a bundled chart.

branch dev
  orders-api.yaml
  support-agent.yaml
  microservice-chart/

Wire Argo CD once

You already run Argo CD. Initialize Argo CD, in the project settings, hands it your repositories through its API. It creates:

An AppProject

Scoped to the project's two repositories and to the namespaces of its environments.

Read-only repository credentials

GitLab deploy tokens are created and rotated for you. GitHub and Azure DevOps take a read-only token. Tokens are encrypted at rest when SECRETS_ENCRYPTION_KEY is set.

An environments ApplicationSet

One Application per environment, with automated sync, prune and self-heal.

One ApplicationSet per app

Each backend service and each web interface that runs as a container gets one Application per environment.

Namespaces are never pruned or deleted, so an emptied repository cannot take running apps down with it.
Before writing anything, every name is checked. If one is taken, initialization stops with nothing changed.
Only a project owner or an organization admin can initialize. Other members see the status.
The console talks to the Argo CD API only. It never holds credentials for your cluster.

Apps and agents start from templates

A new backend service, or an agent, starts from a template repository with CI already in place. Every template builds a Docker image that listens on port 8080, with health checks and an OpenAPI path preset.

Node.js & Fastify

Port: 8080
Health: /health/live
OpenAPI: /openapi.json

Python & FastAPI

Port: 8080
Health: /health/live
OpenAPI: /openapi.json

Spring Boot

Port: 8080
Health: /actuator/health/liveness
OpenAPI: /v3/api-docs

Quarkus

Port: 8080
Health: /q/health/live
OpenAPI: /q/openapi.json

Each template ships an AGENTS.md and a CLAUDE.md, so coding agents follow its conventions from the first change.
CI registers every image version. Deploy through GitOps and Argo CD, or from your own pipeline reporting back with an API key.
A web interface can run as a container too, and deploys the same way as a service.
Functional domains group an app's interfaces and services, so a whole domain can go to an environment in one deploy.

Environments are namespaces

Each environment of a project maps to a Kubernetes namespace. Its ConfigMaps and Secrets are managed in the console and committed to the configuration repository on every deploy.

Secrets are committed as Kubernetes Secret manifests, so keep that repository private and limit who can read it.

Database connections

Register PostgreSQL, MySQL, MariaDB, SQL Server and Oracle connections and test them from the console, so an app can work with data your company already has.

Flightroom does not provision databases. You bring the ones you already run.

Exposure with the Gateway API

Set a domain on the project and a subdomain on each environment. Give an app an exposure path. Every deploy commits the Gateway and the routes, and Argo CD applies them with the rest of the environment.

Environment	Route
dev	https://dev.example.com/api/orders
uat	https://uat.example.com/api/orders
production	https://example.com/api/orders

One Gateway per environment on its own host. Production takes the bare domain.
One HTTPRoute per app on its exposure path. The prefix is stripped, so the app answers at its root.
TLS certificates from cert-manager, an HTTP to HTTPS redirect, and HSTS on HTTPS answers.
Two apps on the same path, or two environments on the same host, refuse the deploy.

Exposure uses Traefik v3 as the Gateway API provider. Moving off one Kong per environment? The exposure guide in the repository moves apps over one at a time.

Git is the source of truth

Every deploy is a commit

With GitOps on, each Deploy commits to the repositories first. The history of an environment is the history of its repositories: who changed what, and when, is already recorded.

Roll back by deploying again

Select the previous image version of the service and deploy. That commits the earlier values like any deploy, and Argo CD brings the cluster back in line. A revert made straight in Git is overwritten by the next deploy.

No commit, no deploy

Flightroom commits before it records the deployment. If the commit fails, nothing is deployed.

What you need

Kubernetes: Environments deploy to the cluster Argo CD runs in.
Argo CD 2.8 or later: Reachable over HTTPS from Flightroom, with an API token for its account.
ApplicationSet policy: The ApplicationSet controller allows a policy per ApplicationSet: set applicationsetcontroller.enable.policy.override to "true" in argocd-cmd-params-cm. Without it, Argo CD ignores the create-update policy that keeps applications from being deleted.
Traefik v3: With its Gateway API provider on, plus the Gateway API CRDs. Only needed for exposure.
cert-manager: With a ClusterIssuer, for TLS. Without one, environments answer over plain HTTP.
A Git provider: GitHub, GitLab or Azure DevOps, for the configuration and applications repositories.

Flightroom does not create clusters, scale workloads or show pod logs. Those stay with Kubernetes, Argo CD and the tools you already use.

Run Flightroom itself on Kubernetes

The repository includes a Helm chart for the console. Point it at your own MongoDB and Redis: the chart does not bundle them. Autoscaling of the console is optional, through an HPA.

git clone https://github.com/flightroom/flightroom.git
cd flightroom
helm install flightroom ./helm/mfe-orchestrator \
  --namespace flightroom --create-namespace \
  --set env.NOSQL_DATABASE_URL="mongodb://user:pass@mongodb:27017" \
  --set env.REDIS_URL="redis://redis:6379" \
  --set envSecrets.JWT_SECRET="$(openssl rand -hex 32)"

Prefer something else? Flightroom also runs with Docker Compose, as a single all-in-one container, or from Terraform and OpenTofu. See the documentation or the source on GitHub.

Also in Flightroom

Build with AI

Describe an app or an agent in plain words. The AI writes it in your repositories.

Learn more

Enterprise

Your single sign-on, your roles, your AI models, your cloud.