Every release, dated.

The AppBahn operator now talks to the control plane over a Connect-tunnel instead of websockets. The practical upshot: your cluster can live behind NAT, a strict egress-only firewall, or an air-gapped network with a single outbound hole — and the platform still sees it.

What shipped

• Connect-tunnel server on the platform, client on the operator.
• Tunnel JWT minting + rotation at the operator side.
• Heartbeat + cluster-registration lifecycle across reconnects.
• CRD for cluster approval on the platform side.

Why this matters

Self-hosted customers rarely expose their Kubernetes API server to the internet. The previous transport assumed inbound reachability; this one does not. If you run on a private cluster, the operator now reaches out instead of being reached in.

Upgrade

helm upgrade appbahn appbahn/appbahn from any prior build. No config changes required. The operator negotiates the tunnel on first contact with the new platform build.

AppBahn’s test matrix picks up a new layer: full-stack end-to-end tests that run against a real Kubernetes cluster instead of mocks. Each test starts a K3s cluster in a testcontainer, installs AppBahn via the Helm chart, and drives the console through Playwright while the operator reconciles CRDs.

What shipped

• Reusable cluster-lifecycle JUnit extension (boots K3s, installs the chart, tears down).
• DNS override and Traefik ingress wired for deterministic routing inside the container.
• Playwright-driven console coverage for the happy paths.
• Allure reports uploaded per run.
• Resource-level navigation and fetching in the console sidebar tree.

Why this matters

Mocked tests missed real-world failure modes — admission webhook race conditions, operator-platform sync ordering, ingress reachability — that only show up against a live API server. The new layer costs about 30–60 seconds per test, but every regression we catch here is one we do not ship.

The first point at which AppBahn stops being “a platform for platform engineers to evaluate” and starts being “a platform developers can push to.” Given a Docker image, AppBahn creates a Deployment, a Service, and an Ingress, requests a TLS certificate, and returns a working URL. No Kubernetes manifests written by hand.

This is also the first tagged public build — everything that landed before this is reflected in the earlier entries below.

What shipped

• Resource creation flow (console + CLI) for Docker image sources.
• Operator reconciles Deployment/Service/Ingress from a single Resource CR.
• cert-manager integration for auto-issued TLS.
• Auto-generated domain scheme: {resource}.{env}.{cluster-domain}.
• Automated GitHub releases: every merge to master produces a dated tag (vYYYY.MM.DD-N) with signed container images and a Helm chart bump.

Why this matters

Everything before this release was scaffolding. This is the first point at which the deploy path itself is complete — and the first point at which a user can install a tagged, signed build instead of cloning from master.

The platform-as-a-product layer. Before this release, AppBahn had no opinion on how an organisation would actually be modelled inside it. After this release, it does.

What shipped

• Four built-in roles: owner, deployer, developer, viewer, scoped per environment.
• OIDC provider plumbing with group-to-role mapping for Keycloak, Okta, Microsoft Entra ID, and Google Workspace.
• Short-lived deploy tokens with rotation and revocation endpoints.
• Per-workspace quotas for CPU, memory, resource count.
• Admin flow for invite → accept → role assignment.

Why this matters

Self-hosted platforms that hand-wave authorisation do not survive contact with real organisations. The roles here are intentionally boring; the point is that your existing IdP drives them, and the quota enforcement is real rather than advisory.

AppBahn’s domain model, materialised. Every object has a slug (name-abcdefg), a URL that matches the console path, and a tier in the hierarchy that determines where RBAC and quota decisions are made.

What shipped

• Workspace CRUD + slug generation.
• Project CRUD scoped under a workspace.
• Environment CRUD scoped under a project.
• Resource slots prepared (deploy path lands with the first Docker deploy).
• Console URL pattern: /console/{wsSlug}/{projSlug}/{envSlug}/{resSlug}.
• API path pattern: /api/v1/workspaces/{slug}, etc.

Why this matters

Every subsequent feature — quotas, RBAC, deploy tokens, audit — attaches to one of these four tiers. Getting the hierarchy shape right up front was the only way to avoid re-plumbing it later.

First user-facing surface. The CLI ships as a single static binary via GoReleaser; appbahn login authenticates against the platform via OIDC; the landing page explains what AppBahn is to someone who has never seen it.

What shipped

• appbahn Cobra-based CLI with login, workspace, project, env, resource, deploy, member, token, and version command groups.
• GoReleaser pipeline producing signed binaries for Linux, macOS, and Windows, published to GitHub releases.
• Public landing page with the design-system-aligned dark theme.
• Login flow on the platform side — OIDC delegation to your IdP.

Why this matters

Distribution is a product decision. Shipping the CLI as a real binary from day two (rather than go run) meant packaging and signing had to work — and those are the things that decide whether people actually try a tool.

No user-facing feature works yet end-to-end, but every layer exists and the deploy pipeline can ship a working platform build onto a Kubernetes cluster.

What shipped

• Multi-module Gradle repo: backend platform, operator, shared modules.
• Vue 3 console wired to the platform via an auto-generated OpenAPI client.
• Helm chart that installs the platform and operator into a fresh cluster.
• GitHub Actions CI pipeline: build, test, publish container images.
• Release workflow producing signed Docker images + versioned Helm chart.

Why this matters

Starting a self-hosted platform with “it installs from a real Helm chart onto a real cluster” sets the bar for everything after it. No ad-hoc kubectl apply scripts, no hidden manual steps — the same install path that contributors see is the one users will.