Deployments

​

What is a deployment?

A deployment in Niro is a managed workload — a set of Kubernetes manifests associated with a cluster, a namespace, and optionally a Git repository folder. Niro deployments are distinct from Kubernetes Deployment objects: a Niro deployment can contain any number of Kubernetes resources (Namespace, ConfigMap, Secret, Service, Deployment, StatefulSet, HPA, Ingress, PVC, etc.) that together make up one logical application.

​

Creating a deployment

There are two ways to create a deployment:

​

Visual Builder

The Visual Builder is a form-driven manifest generator. You fill in a form describing your workload — image, ports, environment variables, resource limits, storage, scaling — and Niro generates the Kubernetes YAML. You can then:

• Apply immediately — send the manifests to the cluster right now
• Commit to Git — open a PR in your linked repo; the manifests are applied on merge
• Both — commit for history and apply now

The builder stores the form data so you can reopen and edit the deployment later without touching YAML.

​

Import from Git

If you already have Kubernetes manifests in a GitHub repo, use Import to scan the repo and convert existing YAML into Niro-managed deployments. Imported deployments are read-only initially; you can convert them to builder-managed deployments to enable visual editing.

​

Apply lifecycle

When you apply a deployment, the following sequence happens:

1. Validate — Niro runs policy checks on the manifests (see Policies)
2. Enqueue — Niro sends an apply command to the cluster’s agent
3. Agent applies — the agent receives the command and calls the Kubernetes API (kubectl apply semantics: create-or-patch)
4. Result — the agent reports per-object results (created, configured, unchanged, failed)
5. Status update — the dashboard shows the apply result and stores it as the latest history entry

The apply command contains the full manifest YAML, so the agent doesn’t need Git access. Niro tracks which objects were applied so it can delete them precisely if the deployment is removed (it never deletes the namespace itself).

​

Apply statuses

​

Rollback

Niro stores every successful apply as a history entry. To roll back:

1. Open the deployment detail page
2. Click Rollback — Niro reopens a PR in your linked repo with the previous version of the manifests
3. Merge the PR — Niro applies the previous manifests to the cluster

If the deployment isn’t linked to a Git repo, rollback applies the previous manifests directly.

​

Drift detection

If your deployment is linked to a Git repo, Niro can detect drift — when the live cluster state diverges from what’s in the repo. Drift triggers a drift_detected incident and shows a diff in the deployment detail view. Auto-sync (enabled per deployment) re-applies the repo state automatically when drift is detected.

​

Deleting a deployment

Deleting a deployment from Niro instructs the agent to remove only the specific objects that Niro previously applied — it never touches objects it didn’t create, and it never deletes the namespace.

​

GitOps deployments

When a deployment is linked to a GitHub repo folder via GitOps, the lifecycle integrates with Git:

• PR opened → Niro runs policy checks and AI review, posts a comment + check run
• PR merged → Niro applies (or deletes) the changed manifests to the cluster
• Merge result → Niro updates the GitHub Deployment status on the commit

See Set Up GitOps for the full walkthrough.

​

Related

• Visual Builder — generate manifests without writing YAML
• Set Up GitOps — link a repo and enable PR-based deploys
• Policies — advisory standards checks run on every apply
• Deploy an App — step-by-step guide to deploying your first app