Konstruct product updates: Global resources, MCP support, and smarter permissions

6 minutes reading time

Written by

John Dietz
John Dietz

Director of Enterprise Cloud Solutions at Civo

May has been one of our busiest months yet for Konstruct. Across three releases, 0.5, 0.5.1, and 0.5.2, we've shipped some of the most requested platform-level changes since we launched: a unified model for sharing resources across organizations, native support for AI-driven workflows via MCP, a completely redesigned API keys experience, and a cleanup to how permissions actually work in multi-org environments.

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

You can explore the full release notes for 0.5, 0.5.1, and 0.5.2 directly in the docs.

Global vs. org-scoped resources

One of the most consistent pieces of feedback we've heard from platform teams managing multiple organizations is this: why do I have to recreate the same cluster template, pipeline template, or environment in every org?

Konstruct 0.5 introduces a single, consistent answer to that question. Every shareable resource (cluster templates, pipeline templates, Helm templates, environments, and GitOps catalog items) can now be created once and made available to every organization on the platform, or scoped to a specific list of orgs. That choice is made at creation time through an ‘Available to’ selector that appears throughout the platform.

Global resources are stored in the default namespace and are immediately visible to every org, including ones created after the fact. They're tagged with a green ‘Global’ badge across all list and detail pages, so there's never any ambiguity. Org-scoped resources work exactly as before, but are now clearly labeled with the org they belong to.

Only ‘Platform Admins’ and super-users can publish a ‘Global’ resource, which keeps the shared layer clean and intentional. Non-admin users can still create org-scoped resources as they always have.

There's also a quality-of-life improvement baked in: when you enter a create flow with a specific org selected in the ‘Viewing as’ dropdown, that org is pre-selected as the scope. Under ‘All organizations’, the form defaults to ‘Global’. Either way, you can change it before submitting.

MCP support

Konstruct 0.5 introduces a new type of API key specifically designed for AI assistants: MCP keys.

Where standard API keys (prefixed konst_api_) are meant for scripts, CI pipelines, and direct API calls, MCP keys (prefixed konst_mcp_) connect through the Konstruct MCP server and are designed to work with tools like Claude Code, Codex, and Gemini CLI. When you generate an MCP key, the success modal includes a tabbed snippet generator with ready-to-paste configuration for each supported client.

This opens up a new category of workflows: driving cluster provisioning, application registration, and platform operations directly from your AI assistant, without leaving your development environment.

API keys redesign

Even beyond MCP, the entire API keys experience got a significant overhaul in 0.5.

The list page now has a proper filter bar, search by name, filter by type, role, and creation date, and a sortable table with relative Last used timestamps that make dormant keys easy to identify at a glance. Per-row actions have moved into a kebab menu with two options: ‘View activity’ and ‘Delete’.

View activity opens a dedicated page for each key showing a full log of every request it made: the HTTP method, the tool name or API path, the response status, server-side latency, the calling user agent (e.g., Claude Code 1.0.43), and the source IP. It's filterable and sortable, which means auditing what a key has been doing is now straightforward, rather than something you have to reconstruct from logs elsewhere.

The revoke dialog also got a practical upgrade: it now surfaces an In active use callout when a key has been used in the last 24 hours, so you know before confirming which clients are about to start failing.

Per-organization permissions (0.5.1)

Earlier releases evaluated permissions globally. If you were a ‘Platform Admin’ in any organization, you effectively had Platform Admin authority everywhere you were a member. That was a pragmatic starting point, but it didn't reflect how most organizations actually want to manage access.

Konstruct 0.5.1 fixes this. Your role is now evaluated against the organization you're currently acting in, specifically, whichever org is selected in the ‘Viewing’ as switcher. A user who is Platform Admin in one org and Developer in another now has the appropriate authority in each, independently.

Within a single org, if you belong to multiple teams with different role mappings, the highest of those roles still applies. That part hasn't changed.

Global API keys (0.5.1)

Alongside per-org permissions, 0.5.1 introduces a new scope option when generating API keys: All your organizations.

Where a single-org key is scoped to one organization, ideal for a CI job or MCP client that only ever touches that org, a global key inherits whatever role you have across every org you belong to at the time it's issued. There's no role picker; Konstruct snapshots your current memberships when the key is generated. If your membership or role changes later, the recommendation is to revoke and reissue.

To go alongside this, the API keys page now includes an All your keys view that surfaces both single-org and global keys together, regardless of which org is selected in the Viewing as switcher. Previously, global keys could be easy to lose track of as you switched between orgs. That problem is now gone.

Delete environments (0.5.2)

Through 0.5.1, environments could be created but not removed from the UI. Cleaning up a stale environment meant going into Git directly and removing files by hand, something that was easy to get wrong and easy to forget.

Konstruct 0.5.2 adds a Delete action to both the environment list and the environment detail page. Team Admins can delete environments within their org; Platform Admins can delete any environment, including Global ones

When you confirm a deletion, Konstruct handles the full cleanup automatically across both GitOps repositories:

First, it removes the environment's configuration file from your platform GitOps repository, which tells Argo CD the environment no longer exists. Then it waits for Argo CD to finish draining the applications that were syncing into that environment. Once that's complete, it removes the environment's folder from your application GitOps repository.

Nothing is left to reconcile after the environment is gone, and you don't have to touch either repository yourself. The environment's name becomes available for reuse once the cleanup finishes.

Looking ahead

The 0.5 series has been about making the platform more composable and more manageable at scale. Global resources reduce duplication across organizations. Per-org permissions give teams the access model they actually need. MCP support opens up a new surface for how engineers interact with the platform day-to-day.

There's more coming. 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.

Get started with Konstruct

Find out how Konstruct gives you an Internal Developer Platform with a production-grade platform-as-a-service, deployed in minutes, fully owned and operated by you, on any cloud infrastructure.

👉 Find out more at civo.com/konstruct

John Dietz
John Dietz

Director of Enterprise Cloud Solutions at Civo

John Dietz is Director of Enterprise Cloud Solutions at Civo, where he helps organizations adopt scalable cloud-native platforms for application delivery and infrastructure management. His work focuses on enabling enterprise teams to modernize infrastructure and improve operational efficiency.

Before joining Civo, John co-founded Konstruct, a company focused on enabling self-managed platform infrastructure. Following its acquisition, he joined Civo to lead enterprise cloud initiatives. His career spans more than two decades across roles, including cloud-native engineer, site reliability engineer, and platform architect.

View author profile