The jargon, in plain words

An ArgoCD feature that generates many applications from one template, for example one per folder in git.

Onboarding a service is adding a file, not running a command.

An ArgoCD boundary that limits which repos, clusters and namespaces an application may touch.

It is what keeps a lower environment from writing into an upper one.

A Kubernetes controller for canary and blue/green releases.

A new version gets a slice of traffic first, and moves on only when it looks healthy.

The tool that watches a git repo and applies what it describes to a Kubernetes cluster.

In Hangar it is the only thing that writes to a cluster, and each cluster runs its own.

Amazon's service for running a function on demand, with no servers to manage.

Hangar can now onboard a Lambda function and deploy to it, through the same API and pipeline as any app.

Microsoft's managed service for running containers, which can also host Azure Functions.

It is one of Glidepath's cloud deploy targets, and how Hangar deploys Azure Functions.

Spotify's open-source framework for internal developer portals.

Tower is a Backstage plugin, so Hangar lives where developers already look.

An emergency way in that is normally locked: in Tower, a recorded, time-boxed shell in a debug container on one pod of your own app.

You keep the ability to look inside a pod without anyone holding standing exec rights in production.

Docker's image build engine, run here rootless and without a long-lived daemon.

Builds need no privileged container, and one step builds both CPU architectures without emulating the compiler.

Releasing a new version to a small share of traffic before everyone gets it.

Problems show up on a few requests instead of all of them.

A standard format for software-delivery events, such as "build finished" or "service deployed".

Hangar chains pipeline stages with them, and counts DORA metrics from the same stream.

Common Expression Language: a small, safe language for writing rules.

Autopilot and Kyverno both write policy in it, so there is one policy idiom.

A test run from the shared check-rides repository whose signed result is attested on the image.

The qa release gate reads it, and the release record keeps it, so a release can prove it was tested.

The recipe that turns an XR into the actual resources behind it.

Changing a Composition changes every service built from it, which is powerful and needs care.

A small program Crossplane runs while composing, for logic a template cannot express.

Hangar uses them for things like watching a rollout and dispatching an AI diagnosis.

A Kubernetes add-on that lets you define your own APIs and turns requests against them into real resources.

It's Hangar's platform API: people, portals, pipelines and agents all ask for things the same way.

Four measures of delivery performance: how often you deploy, how long a change takes, how often it fails, and how fast you recover.

They say whether the platform is actually saving anyone time.

A temporary container Kubernetes can add to a running pod, usually for debugging.

It arrives as a full container spec, so the cluster can check its image, user and permissions before it runs.

An operator that copies secrets from a store like Infisical into Kubernetes, and keeps them in sync.

Nobody applies a raw Secret by hand, and nothing secret lives in git.

Sigstore's certificate authority: it issues a short-lived signing certificate to a proven identity.

Hangar runs its own so in-cluster build identities can sign.

Running systems from a git repository: the repo says what should be deployed, and an agent makes the cluster match.

Every change is a reviewed commit, and rolling back is a revert.

A tool that signs git commits with Sigstore, using your normal login instead of a key.

Release gates can check that a real, allowed person authorized the code.

A package manager for Kubernetes: a chart is a template, values fill it in.

Every Hangar service deploys through one chart, so good defaults live in one place.

An open-source secrets manager with an API.

It is Hangar's single source for secret values.

A Kubernetes policy engine that can allow, reject or change resources as they are created.

Hangar uses it where plain RBAC cannot express a rule.

The Model Context Protocol: a standard way for AI agents to call tools.

Any agent runtime can use Hangar through it without a custom client.

The one request Autopilot is built to pass, typed to an AI agent: "provision a new python application named parachute. give it a dev and test ground environment. a staging and prod flight environment. and configure it with 1 100% weight canary step, an URL=http://myendpoint.io env var."

It's the end-to-end acceptance test: the platform is ready for agents when that sentence becomes a correct change set that a human reviews and merges.

A Tekton add-on that starts pipelines from git events: pushes, pull requests, comments.

It handles webhook signatures and PR status checks, which are easy to get wrong by hand.

A signed record of how an artifact was built: from which source, by which pipeline, with which steps.

It is the evidence a release gate reads before anything reaches production.

A controller repeatedly comparing what exists with what was asked for, and fixing the difference.

Great for things that should stay a certain way; the wrong tool for things that should happen once.

Sigstore's transparency log: a tamper-evident public record of signatures.

A signature you can't look up later is a claim, not evidence.

Tower's history of one release: a draft from the moment the last release ships, sealed as a YAML file in the app's GitOps repo once it is healthy, with an outcome added after a seven-day bake.

A release's notes, sign-off, evidence and outcome stay in one reviewed file, readable long after the pipeline runs behind them are gone.

A software bill of materials: the list of everything inside an image.

When a new vulnerability lands, you can tell in minutes which services contain it.

An open-source project for signing software with short-lived certificates instead of long-lived keys.

Nothing secret to leak, and every signature can be looked up later.

A service level objective: a target like "99.5% of requests succeed over 30 days".

It turns "is it healthy?" into a number you can alert and decide on.

Supply-chain Levels for Software Artifacts: a framework for proving how a piece of software was built.

A release gate can check what the build really did, not just that it finished.

A CI/CD engine that runs pipelines as Kubernetes resources.

It runs anywhere Kubernetes does, and developers never have to write its YAML.

A Kubernetes-native test orchestrator: it runs tests written in any framework as pods in your cluster and collects their results.

Tests become declared resources, reviewed in git and run by a controller, like everything else in Hangar.

Testkube's custom resource for a test: the image, the steps, any services it needs and which files to keep.

An app team adds a test by committing one file; Glidepath's test stage runs it.

A Kubernetes API that confirms who a pod is from the token the cluster gave it.

Services can trust a caller without Hangar handing out any keys.

Kubernetes' built-in admission rules, written in CEL and enforced inside the API server.

No webhook to go down: a rule is checked even when every add-on is having a bad day.

A composite resource: a small request against a Crossplane API, such as "I want a PostgreSQL database, size small". Crossplane v1 put a separate Claim in front of it; v2, which Hangar uses, makes the XR itself namespaced and removes Claims.

Developers ask for outcomes in a few lines; the platform fills in the rest and keeps it that way.

A CompositeResourceDefinition: the schema for a new Crossplane API, such as "a Node.js application".

It is the contract for what a compliant service is, defined once and checked on every request.