Konstruct product updates: GitLab support, platform broadcasts, and a permission model built for scale

July has been one of our most structurally significant releases yet for Konstruct. With 0.6, we've shipped a second git provider, a completely reworked authorization model, new tooling for AI-assisted troubleshooting, and a handful of improvements that are smaller in scope but large in impact for day-to-day platform operations.

Let's walk through what shipped and why it matters.

GitLab as a first-class git provider

Until now, Konstruct supported a single git provider: GitHub. That wasn't always a constraint people mentioned upfront, but once a team running GitLab showed up, it became the first question.

0.6 changes that. GitLab is now a first-class git provider alongside GitHub, supported from the same getting-started flow and treated as a peer throughout the platform.

The onboarding experience mirrors what GitHub users already know. You authenticate with GitLab via OAuth, select the GitLab group to use as the org namespace, and Konstruct handles the rest, creating the GitAccount CR automatically on group selection, initializing the GitOps repository with main as the default branch, and setting up a GitLab sub-group as the org namespace.

Under the hood, the implementation is built around a GitLab Group Access Token. When you authorize via OAuth, Konstruct exchanges the grant for a token with api, read_repository, and write_repository scopes. That token is stored in a konstruct-git-config Secret on the control plane, and all operators, the workloadcluster-operator, team-management-operator, and application-operator, read from this centralized config rather than managing per-resource credentials.

The meaningful difference from GitHub is the URL structure and auth model. GitHub uses a GitHub App installation token and a flat {org}/{repo} path. GitLab uses a Group Access Token and nested group paths: gitlab.com/{group}/{subgroup}/{repo}. The operators handle this distinction transparently, so the experience from the UI is consistent regardless of which provider you're using.

If your organization runs on GitLab and has been waiting for native support, this is the release to upgrade to.

Platform broadcasts

One thing that's been missing from Konstruct's admin capabilities is a native channel for communicating with users across the platform. Until 0.6, if you needed to announce a maintenance window, surface an incident update, or push a policy change, you were relying on email, Slack, or something entirely outside the platform.

0.6 introduces a broadcast system that gives Platform Admins a first-party way to reach every user on the platform.

Broadcasts are managed through a new section in the admin sidebar. You create one using a Markdown editor, pick a severity level — info, success, warning, or critical, and optionally set start and end dates for scheduled announcements. Active broadcasts appear as a colored banner at the top of every page for all users: blue for info, green for success, amber for warning, red for critical.

Under the hood, broadcasts are backed by a cluster-scoped Broadcast CRD managed by the team-management-operator. Scheduling logic is evaluated at read time rather than persisted to status, which means a broadcast is either active or it isn't, based on the current time and whatever schedule you set. The full CRUD surface is available through the API at /api/v1/broadcasts, and write operations record who created or last updated each entry from the caller's JWT identity.

This is a straightforward feature on paper, but it closes a real gap. Platform admins responsible for communicating operational state to large engineering teams shouldn't have to leave the platform to do it.

MCP diagnostics

In 0.5, we introduced MCP keys, a dedicated API key type for connecting AI assistants like Claude Code to the Konstruct platform. 0.6 extends that integration with a new set of diagnostic endpoints specifically designed for AI-driven troubleshooting.

When an AI assistant is connected via the Konstruct MCP server, it can now:

• List operator pods in the konstruct-system namespace and fetch their logs directly
• List all Konstruct CRDs scoped to *.konstruct.civo.com, and inspect their schemas, versions, and scope
• List and retrieve CR instances for any Konstruct CRD

The goal is to give AI assistants enough visibility into the platform's internal state to do meaningful troubleshooting — not just surface-level status checks, but the ability to inspect what the operators are doing, what resources exist, and what state they're currently in. Sensitive fields are scrubbed from CR instance responses before they leave the API. The operator namespace and label selector are configurable via environment variables, and the Helm chart automatically includes the required RBAC permissions for the konstruct-api ServiceAccount.

For teams that have adopted AI-assisted platform workflows, this makes those workflows significantly more capable when something goes wrong.

Looking ahead

0.6 is one of the more structurally significant releases we've shipped. GitLab support opens the platform to a large segment of teams that were previously excluded by the GitHub-only constraint. The RBAC overhaul gives us a permission model we can build on without constantly working around it. MCP diagnostics extend AI-assisted workflows into operational troubleshooting. And the reliability improvements address failure modes that were hard to reproduce but real when they happened.

There are no breaking changes for end users in this release, and upgrading is straightforward, update targetRevision to 0.6.0 in your platform GitOps repository and Argo CD handles the rest.

If you want to see what Konstruct looks like in your environment, schedule time with me here, or read more about where Konstruct is headed.