KubeRocketCI is an open-source, Kubernetes-native CI/CD platform built on Tekton and Argo CD. It runs entirely on your own cluster and works with GitHub, GitLab, Bitbucket, or Gerrit as the code host. GitLab CI is the CI/CD service inside the GitLab DevSecOps platform. The core difference: Tekton-based CI you own and can isolate, versus CI bound to the GitLab application.
Ingress NGINX was retired in March 2026. The Kubernetes Steering and Security Response Committees were blunt about what that means: "There will be no more releases for bug fixes, security patches, or any updates of any kind after the project is retired", and "choosing to remain with Ingress NGINX after its retirement leaves you and your users vulnerable to attack" (statement, January 2026). If your cluster still has Ingress objects, you have a migration you did not ask for.
The Gateway API is the destination, and converting a single workload to it is easy: its chart renders an HTTPRoute instead of an Ingress, and you are done. The migration is not the conversion. It is everything that happens between the first converted host and the last one - because the entry point in front of the cluster points at exactly one thing, and switching it happens for every host at the same moment.
This post compares the ways through that middle, then goes deep on the one that turned out to need no per-host infrastructure work at all: an HTTPRoute with no hostnames, which the Gateway API defines as the lowest-precedence match, handing everything unclaimed straight back to the ingress-nginx controller. On the cluster behind this post - roughly a hundred hosts across platform add-ons, developer environments, and teams the platform group does not own - it meant the switch was safe on day one and every remaining host migrated when its owner was ready. Every route table and log excerpt below is read from that cluster, with hostnames and namespaces replaced by generic ones.
Every platform team hits the same wall: the qa environment needs a different CRD version than dev, a teammate's experiment needs cluster-admin, or a preview environment needs to be disposable without a change-advisory meeting. Kubernetes namespaces don't isolate any of that - CRDs, admission webhooks, and cluster-scoped RBAC are shared by every namespace on the cluster. The textbook answer is a second cluster, but a second cluster means a second control plane to pay for, patch, and secure.
vcluster sits exactly in that gap: a certified Kubernetes distribution that runs inside a namespace of your existing cluster, with its own API server, its own CRDs, and its own RBAC - while the pods it schedules land on the host nodes you already own. That makes it a perfect deployment target for a CI/CD platform: real cluster isolation, zero new hardware.
This post walks through the complete flow on KubeRocketCI: create a vcluster, register it through the Portal, wire Argo CD, and promote an application into it. Everything below - every command, screenshot, and error message - is from a real run on the local try-kuberocketci testbed.
Push a commit to a merge request and your review pipeline starts. Spot a typo, push again thirty seconds later - and now two pipelines are running, one of them validating a commit that no longer matters. GitHub Actions solved this years ago with concurrency.cancel-in-progress; Tekton has no built-in equivalent, so on a Tekton-based platform those superseded runs keep burning CPU until they finish, producing results nobody will read.
KubeRocketCI 3.14 closes that gap with a single chart flag: pipelines.cancelInProgress. When enabled, the KRCI Tekton interceptor cancels still-running review PipelineRuns for the same pull request before triggering the replacement. The cancellation is graceful (CancelledRunFinally): the superseded run still executes its finally tasks, so your git provider gets a status for the old commit instead of an eternally "pending" check. This post shows the whole flow live on the local try-kuberocketci testbed - every screenshot and command output is from a real run.
Every feature branch you create in KubeRocketCI becomes a CodebaseBranch resource in Kubernetes - the object that drives its CI pipelines, records its built images, and feeds ephemeral preview environments. But when that branch merges and someone deletes it in GitLab or GitHub, the Kubernetes side never hears about it. The CodebaseBranch lives on: it clutters the Portal, offers a Build button for a branch that no longer exists, and on a busy platform these orphans accumulate by the hundreds.
KubeRocketCI 3.14 closes that gap. The codebase-operator now periodically verifies every branch against the real git repository, marks missing ones with a Stale condition (and a badge in the Portal), and - if you opt in - deletes them automatically, while refusing to touch any branch that is still wired into a deployment. This post shows the whole lifecycle live on the local try-kuberocketci testbed: every screenshot and command output below is from a real run.
GitLab CI integration in KubeRocketCI lets a single application run its CI pipeline in GitLab CI - on a GitLab Runner - instead of Tekton, while still being managed as a first-class Codebase on the platform. You set one field on the Codebase (spec.ciTool: gitlab), and KubeRocketCI generates a .gitlab-ci.yml in the repository; GitLab then runs the pipeline, with no Tekton involved. From then on, every merge request runs a review pipeline and every merge runs a build pipeline - all native GitLab CI, all on your own cluster.
This is part three of my hands-on series on the local try-kuberocketci testbed. In part one I stood up the full platform in two commands; in part two I built ephemeral preview environments from a feature branch. Both ran their CI in Tekton. This post takes the same kind cluster running KubeRocketCI 3.13 and shows the multi-CI path: how GitLab CI integration works, the three things you must set up before you enable it - a Runner, the onboarded CI/CD components, and a ConfigMap - and a full review-to-build run with real output.
An ephemeral preview environment is an isolated, temporary Kubernetes deployment created from a single feature branch and torn down when the work is done. Every branch gets its own namespace, its own image, its own URL - and zero of it lingers afterward. Ephemeral environments on Kubernetes make this pattern available on your own cluster - but a hands-on, open-source, portal-native version - feature branch to isolated namespace to one-click destroy, backed by real Tekton CI and Argo CD GitOps - is conspicuously missing from the public record.
So I built one, end to end, on the same local try-kuberocketci testbed from my last post: a kind cluster running KubeRocketCI 3.14.0 with Tekton, Argo CD, and self-hosted GitLab. This post is the full walkthrough - every screenshot, every line of terminal output, captured from a live run. We will take a stable main deployment, branch off it, ship a change that is visible only in the preview environment, inject per-environment config through GitOps, prove the two environments never touch each other, and then destroy the whole thing - leaving the baseline exactly as it was.
Building CI/CD on Kubernetes used to mean running Jenkins or GitLab CI in a pod and calling it done. Tekton changed that by making pipelines first-class Kubernetes objects - Tasks and Pipelines are CRDs, PipelineRuns are namespaced resources, and every step log is a container log. KubeRocketCI goes a step further: it ships a complete, production-grade CI/CD platform on top of Tekton so your team gets sensible defaults, a portal UI, GitOps-managed pipeline definitions, and opinionated quality gates - without the months of plumbing work that comes with assembling those pieces from scratch. I've seen teams go from a bare cluster to a working build-deploy loop in under a day using this stack.