Skip to main content
Version: 0.7 (Next)

Konstruct 0.6.1

Released: July 2026

Highlights​

  • Blue/green deployments (API only) — deploy two named instances of the same application into one environment and switch live traffic between them through the Konstruct API
  • Named deploy instances — the deploy endpoint accepts an optional instance_name, so blue and green (or any names you choose) run side by side
  • Per-environment HTTP routes — new route endpoints map a hostname to whichever instance is live and flip traffic between them, backed by the shared Envoy Gateway
  • Postman collection — an importable collection walks through the full deploy → route → switch flow
  • API keys last up to 1 year — the maximum API key lifetime is raised from 30 days to 365 days

Blue/green deployments​

0.6.1 introduces a blue/green workflow for registered applications. Instead of replacing a running deployment in place, you run two named instances of the same app in the same environment and switch live traffic between them.

API only

In 0.6.1, blue/green deployments are driven entirely through the Konstruct API — there is no UI for named instances or route switching yet. Use the Postman collection below, or call the endpoints directly.

Named deploy instances​

Instances are created through the normal deploy endpoint, POST /api/v1/application-deployment/deploy, with an optional instance_name field:

  • Omit instance_name (or set it to default) to deploy the primary instance — existing behavior is unchanged. The deployment keeps the historical name {app}-{env}-{cluster}.
  • Set a name such as green to deploy an independent, separately versioned instance alongside the default. Its deployment is named {app}-{instance}-{env}-{cluster}.

Deploy both instances into the same environment_namespace so a single route can front them. Each instance tracks its own version.

Per-environment routes​

Once two or more instances exist, a set of per-environment route endpoints control which instance serves live traffic. The route endpoints live under the application path /api/v1/konstruct-application/{namespace}/{app}/environments/{environment}/route:

Method and pathPurpose
POST /application-deployment/deployDeploy an instance — instance_name selects blue/green
PUT …/routeCreate or update the environment's HTTP route — set hostname, gateway, port, and the active instance
GET …/routeRead the current route: hostname, gateway, and active instance
POST …/route/switchFlip live traffic to a target instance
DELETE …/routeRemove the route and its gateway resources

Routes are Gateway API HTTPRoutes that attach to the platform's shared Envoy Gateway — eg in the default namespace, backed by a public load balancer — and are differentiated by hostname, so you don't provision a gateway per app. The route's port must match the instance's Service port. Route changes are committed to the application's GitOps repository and reconciled by Argo CD; switching traffic is a metadata change with no pod restart, and rollback is a git revert.

Cutting over​

A blue/green release is:

  1. Deploy the current version as the default instance and configure a route with active: default.
  2. Deploy the new version as a second instance, green, into the same environment namespace.
  3. Verify green on its own.
  4. POST …/route/switch with target: green. Traffic moves to the new instance with no change to the hostname.
  5. If something's wrong, switch back to default.

Postman collection​

Import the collection and its environment to try the flow end to end:

In Postman, import both files, select the Application Instances environment, and set the token variable to a Konstruct API key (konst_api_…, not an MCP key) — see API keys. Then fill in baseUrl, namespace, appName, environment, and cluster for your platform. The requests run in order: deploy default → deploy green → configure route → switch traffic.

API keys: up to a 1-year lifetime​

The maximum lifetime for an API key is raised from 30 days to 1 year (365 days).

  • The expires_in_days field on the create-key API now accepts any value from 1 to 365. It still defaults to 30 when omitted.
  • Requests above 365 days are rejected.

Longer-lived keys reduce rotation overhead for long-running CI systems and MCP integrations. Keys still inherit the issuer's role and can be revoked at any time. See API keys for the full reference.

Upgrade notes​

Update the targetRevision in your platform team's Konstruct Argo CD Application manifest to 0.6.1:

spec:
  source:
    chart: konstruct
    repoURL: oci://europe-west2-docker.pkg.dev/civo-com/charts
    targetRevision: 0.6.1

Commit and push — Argo CD syncs the new version automatically. No manual migration steps are required. API keys issued before the upgrade keep their original expiry.

What's next?​