wait, this is so much cooler than the token method.

If you have ever published an npm package from GitHub Actions, you already know the old ritual.

• create an npm token

• copy it into GitHub secrets

• wire it into CI

• pray it never leaks

• completely forget about rotating it

It works. But it has always felt slightly cursed.

A long-lived publish token sitting in CI is one of those things we all accepted because it was normal, not because it was actually a good idea.

I recently switched @kubeorch/cli to trusted publishing, and after implementing it, I genuinely don't want to go back.

The old npm token flow always felt wrong

The classic GitHub Actions setup usually looks something like this:

- name: Publish to npm
  run: npm publish --access public
  env:
    NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

Simple? Yes.

Great security model? Not really.

The problems are kind of obvious once you say them out loud:

• the token is long-lived

• it has to be manually created

• it lives in CI secrets

• it can be leaked by bad logging, bad workflow design, or just plain human error

• if it leaks, someone else may be able to publish your package

And for npm, that is not a small problem.

If someone gets publishing access to your package, that is not just "oops, secret got exposed." That can turn into a full supply-chain mess very quickly.

Malicious package version. Compromised users. Broken trust. Incident cleanup. Apology tour.

That is way too much risk to attach to one static secret you probably set up months ago and forgot existed.

Trusted publishing changes the model completely

This is the part I like.

With trusted publishing, npm no longer relies on a long-lived token stored in GitHub secrets.

Instead, npm trusts a specific GitHub repository and workflow identity.

So when your workflow runs, GitHub Actions uses OIDC to prove:

• which repository the workflow came from

• which workflow is running

• that this is a real CI execution and not some random person holding a leaked token

That means the mental model changes from:

whoever has the token can publish

to:

only this trusted workflow from this trusted repo can publish

That is just a way better default.

What I changed in kubeorch/cli

I set this up in the KubeOrch CLI release workflow.

The important part is that the publish job now allows GitHub Actions to request an identity token:

permissions:
  contents: read
  id-token: write

And the actual publish step looks like this:

- name: Publish to npm
  working-directory: ./npm-package
  run: npm publish --provenance --access public

That id-token: write permission is the key.

That is what enables the GitHub Actions workflow to mint the short-lived OIDC token npm uses for trusted publishing.

And --provenance is a really nice bonus here too, because now the publish includes provenance metadata instead of just "trust me bro, CI did it."

The nice part is what's missing

Here is the kind of release workflow that feels much better to me now:

name: Release and Publish

on:
  push:
    tags:
      - 'v*'

permissions: {}

jobs:
  release:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 20
          registry-url: 'https://registry.npmjs.org'

      - name: Publish to npm
        working-directory: ./npm-package
        run: npm publish --provenance --access public

What I like most is what you don't see anymore.

• no NPM_TOKEN

• no NODE_AUTH_TOKEN

• no secret copy-pasting

• no "did we remember to rotate this thing?"

The workflow identity itself becomes the credential.

That feels much more correct.

Why this is actually more secure

People say "more secure" all the time, so let me make it less vague.

1. There is no long-lived npm publish secret sitting in CI

This is the biggest win.

If your GitHub secrets get dumped, or a workflow accidentally exposes environment variables, there is no permanent npm publish token just sitting there waiting to be abused.

That alone makes this better.

2. Publishing is tied to your repository identity

npm is not just accepting some random string token.

It can verify that the request came from the exact GitHub Actions workflow you configured.

That is a much stronger model than "someone knew the secret."

3. It removes a lot of human error

Token-based publishing depends on developers doing secret management well.

Let's be honest. That's not where most teams are strongest.

People create a token once, put it in secrets, and never think about it again until something breaks.

Trusted publishing removes that whole maintenance burden.

4. Provenance makes the release story better too

This is another underrated part.

Using:

npm publish --provenance --access public

means the published package includes build provenance.

That is a much healthier direction for package ecosystems in general, especially after all the supply-chain nonsense we've seen over the past few years.

Why I think this was introduced now

My guess is pretty simple: the ecosystem had to learn the hard way.

Too many secrets in CI. Too many leaks. Too many package incidents. Too many workflows built around static credentials that quietly became high-value targets.

Once you look at it from that angle, the old token-based model starts to look kind of outdated.

Why should publishing a package depend on a secret that was manually created months ago and stuffed into a CI settings page?

Why is that the thing protecting your package lineage?

Trusted publishing feels like the obvious evolution:

• fewer secrets

• shorter trust window

• stronger identity guarantees

• better auditability

And the best part is that it is not one of those security improvements that makes everything more annoying.

It actually feels cleaner.

Tokens vs trusted publishing

If I had to explain it to another maintainer in one minute, I'd say this.

Token-based npm publishing

• easy to understand

• easy to set up

• easy to forget about

• easy to leak

• annoying to rotate

• too much trust in one static credential

Trusted publishing

• slightly newer mental model

• much cleaner CI setup

• much better security story

• no long-lived npm token in GitHub secrets

• feels much more aligned with modern infra practices

That last part matters.

A lot of modern infra has already moved away from static credentials and toward short-lived identity-based access.

npm trusted publishers feels like package publishing finally catching up.

If you maintain an npm package, I would seriously consider switching

Especially if:

• your package is public

• other people install it

• you already release through GitHub Actions

• you care about supply-chain security even a little bit

The setup is not complicated.

And once it is done, the release flow actually feels simpler than the token-based version.

That is the rare part here.

Usually better security means more pain.

This one actually reduces pain.

Final thought

After switching @kubeorch/cli to npm trusted publishing, my honest takeaway is this:

this feels like the version of npm publishing we should have had from the start.

Long-lived publish tokens in CI were always a little sketchy. We just got used to them.

Trusted publishing is cleaner, more secure, and a much better fit for how CI/CD should work in 2026.

If you maintain an npm package and you are still using an npm token in GitHub Actions, I think this is worth a look:

• npm Trusted Publishers

I found it recently, implemented it in KubeOrch CLI, and now the old token method just feels unnecessarily risky.

And honestly? Good riddance.

I'm a founding engineer, I kept running into the same problem: Kubernetes is incredibly powerful, but it's also brutally complex to get right. The learning curve is steep, the feedback loop is slow, and one wrong indent breaks everything.

So I built KubeOrch — an open-source visual orchestration platform that lets you design, connect, and deploy Kubernetes workloads through a drag-and-drop interface. No YAML. No guessing. Just draw your architecture and hit deploy.

Here's what I built, how it works under the hood, and why I open-sourced the whole thing.

The Problem With Kubernetes Today

Kubernetes has won the container orchestration wars. It's the de facto standard. But the developer experience hasn't caught up with its adoption.

Consider what it takes to deploy a simple web app with a PostgreSQL database and a Redis cache on Kubernetes:

• A Deployment manifest for your app

• A Service to expose it

• A Deployment + PersistentVolumeClaim for Postgres

• A Service for Postgres

• A Secret for credentials

• A Deployment for Redis

• A Service for Redis

• A ConfigMap for environment variables

• An Ingress with TLS config

• NetworkPolicies if you care about security

That's 9+ YAML files, hundreds of lines, and dozens of ways to silently misconfigure something. And this is the simple case.

The tools that exist today — Helm, Kustomize, Lens — either abstract the YAML (but you still write it) or visualize existing clusters (but you still write it first). No one has tackled the core issue: the mental model of a distributed system is visual, but the tooling forces you to express it as text.

What KubeOrch Does

KubeOrch flips the workflow. Instead of writing manifests and hoping they wire up correctly, you:

1. Drag services onto a canvas (Postgres, Redis, Kafka, your app — 150+ components)

2. Connect them by drawing lines between ports

3. Deploy — KubeOrch generates the manifests, resolves dependencies, and applies them to your cluster

The platform has four main components:

1. KubeOrch Core (Go)

The brains of the operation. A Go API server built on Gin that handles:

• JSON-to-YAML transformation — your visual design is stored as a JSON graph internally; Core converts it to production-ready Kubernetes manifests at deploy time

• Automatic connection resolution — when you draw a line from your app to Postgres, Core figures out the right DATABASE_URL env var, the right service DNS name, the right port — without you specifying any of it

• Nixpacks integration — point Core at a GitHub repo and it builds a container automatically, no Dockerfile needed

• Service mesh support — Istio, ingress controllers, and load balancers are first-class citizens

• Real-time streaming — WebSocket-based log and metrics streaming from all running containers

// Example: Core's auto-wiring picks up connection intent and resolves it
type Connection struct {
    SourceService string `json:"source"`
    TargetService string `json:"target"`
    SourcePort    int    `json:"sourcePort"`
    TargetPort    int    `json:"targetPort"`
}
// Core resolves this into env vars, DNS entries, and NetworkPolicies automatically

2. KubeOrch UI (Next.js + TypeScript)

The visual canvas, built with:

• React Flow for the drag-and-drop workflow designer

• Next.js 15 with TypeScript

• shadcn/ui + Tailwind CSS v4 for the component library

• Zustand for state management

• WebSocket for real-time log streaming

The UI is intentionally opinionated. Services snap together intelligently — when you try to connect a Node.js app to PostgreSQL, the UI already knows what that connection means and pre-fills the configuration.

3. OrchCLI (Go)

A CLI that handles the local dev loop:

# Initialize a KubeOrch project
orchcli init

# Start all services (supports hot reload)
orchcli start

# Fork and contribute to core or UI
orchcli init --fork-core
orchcli init --fork-ui

It supports concurrent operations with file locking to prevent config corruption, auto-detects your dev mode based on which repos you've cloned, and handles hot reload across all services.

Install it in one line:

curl -sfL https://raw.githubusercontent.com/KubeOrch/cli/main/install.sh | sh

Or via npm:

npm install -g @kubeorch/cli

4. Docs (Astro)

Full documentation site covering architecture, getting started, CLI reference, and API reference — built with Astro for fast static generation.

The Architecture Decision I'm Most Proud Of

The hardest problem in building KubeOrch wasn't the UI or even the Kubernetes API integration — it was automatic service wiring.

When two services are connected in the visual canvas, the platform needs to figure out:

• What environment variable should carry the connection string?

• What DNS name should the dependent service use?

• What port should be exposed?

• Does this connection need a NetworkPolicy?

• Does it need a Secret, or is the connection string safe to put in a ConfigMap?

The naive solution is to ask the user. But that defeats the whole point.

The solution I landed on is a service template system with typed ports. Every component in the library (Postgres, Redis, Kafka, etc.) is defined with its ports annotated with type metadata:

{
  "name": "postgresql",
  "ports": [
    {
      "port": 5432,
      "type": "postgres",
      "envVarTemplate": "{{TARGET_NAME}}_DATABASE_URL",
      "valueTemplate": "postgresql://{{USER}}:{{PASSWORD}}@{{SERVICE_DNS}}:5432/{{DB_NAME}}"
    }
  ]
}

When you draw a connection, Core matches port types, renders the templates with resolved values, and injects the result as environment variables into the dependent service — with a Secret for anything sensitive.

150+ services are defined this way, covering databases, queues, ML platforms, monitoring stacks, and more.

Why Open Source?

I could have built this as a SaaS. I thought about it.

But Kubernetes tooling lives and dies by community trust. Operators don't want their cluster credentials going through a third-party API. They want to run the control plane themselves, audit the code, and contribute fixes.

More importantly — the problems KubeOrch solves are universal. Every team fighting with YAML is fighting the same fight. An open-source project that solves this well becomes infrastructure for the entire ecosystem.

KubeOrch is Apache 2.0 licensed and structured as a CNCF-aspiring project with full governance documentation:

• Contributor ladder (from contributor → member → maintainer)

• Governance policy

• API stability policy

• RFC/proposal process in the community repo

The goal is to eventually donate this to the CNCF sandbox. The groundwork is already laid.

Getting Started

Try it locally

# Install the CLI
curl -sfL https://raw.githubusercontent.com/KubeOrch/cli/main/install.sh | sh

# Initialize a new project
orchcli init

# Start everything
orchcli start

Open http://localhost:3001 to see the visual canvas.

Run Core directly

git clone https://github.com/KubeOrch/core.git
cd core
go mod tidy
go run main.go

Core starts at http://localhost:3000.

Explore the repos

• KubeOrch/core — Go backend, orchestration engine

• KubeOrch/ui — Next.js visual canvas

• KubeOrch/cli — OrchCLI developer tool

• KubeOrch/community — Governance, roadmap, RFCs

• KubeOrch/docs — Full documentation

What's Next

The roadmap has three near-term priorities:

1. GitOps integration — sync your visual design to a Git repo and trigger deploys on push

2. Multi-cluster support — manage workloads across multiple clusters from one canvas

3. Plugin SDK — let the community build and publish custom components to the marketplace

If any of these problems interest you, the contributor guide is in the community repo and issues are open.

Closing Thoughts

Kubernetes isn't going anywhere. But the developer experience has a long way to go before it matches the power of the underlying platform.

KubeOrch is my attempt to close that gap — to make the visual mental model of distributed systems the primary interface, not a second-class visualization layer bolted on top of YAML.

If you've felt the pain of Kubernetes configuration, give it a try. And if you want to help build it, the doors are open.

GitHub: github.com/KubeOrch

Follow me on X/Twitter for more.

It isn’t.

Drawing boxes and arrows is easy. The real problem starts after that. Because once a user connects an API to Postgres, or a worker to Redis, or a frontend to a backend, the system now has to answer a much harder question: how do you turn that graph into infrastructure people can actually deploy and trust? That is the real problem KubeOrch Core is trying to solve.

KubeOrch, at a high level, is a visual orchestration platform for Kubernetes. People see the canvas first, which makes sense. It is the most visible part of the product. But the interesting engineering work sits underneath it: the translation layer that takes a graph of services and connections and turns it into Kubernetes manifests, configs, secrets, and deployable topology.

A visual orchestrator is really a compiler

The easiest way to understand this kind of system is to stop thinking of it as a design tool. It is much closer to a compiler. The input is not code, but intent. A user places services on a canvas, connects them, configures them, and describes the shape of the system they want. The job of the core engine is to take that intent and compile it into concrete infrastructure.

That sounds neat in one sentence, but it gets complicated very quickly in practice. If a user draws: frontend → api → postgres that is not just a pretty diagram. That implies a whole chain of real infrastructure decisions. You need workloads. You need services. You need DNS and service discovery. You need environment variables. You need configuration handling. You probably need secret handling too. You need some sensible assumptions about what is public, what is internal, and what should be wired automatically versus exposed explicitly.

That is why the core matters so much. Anyone can build a canvas that lets users drag components around. The harder part is building a system that can look at that graph and say, “I know what this means operationally.” But most Kubernetes workflows force people to immediately translate that mental model into YAML, naming conventions, resource definitions, and low-level platform details. By the time you get to something deployable, the original system idea is buried under configuration. That mismatch is what made KubeOrch interesting to me in the first place.

The visual layer is not supposed to replace engineering. It is supposed to preserve the mental model long enough for the platform to generate the lower-level infrastructure correctly.

That is a very different goal from just “making Kubernetes easier.” The core starts with templates, not hardcoded cases One thing became obvious pretty early: if every component had to be special-cased in the engine, the whole thing would collapse. You can get away with that for a demo. You cannot get away with it for a real orchestration engine.

If Postgres has one path, Redis has another, RabbitMQ has another, MongoDB has another, and every new service adds more branching logic somewhere deep in the backend, the system becomes harder to extend every time you add a component. So the core has to be template-driven. That means the engine needs reusable definitions for how different classes of services should be rendered into infrastructure.

A service is not just a visual object on the canvas. It carries a deployment shape, configuration expectations, connectivity assumptions, and resource-generation rules. That abstraction matters a lot. Once the system is template-driven, adding a new kind of component becomes much more manageable. You are no longer stuffing one more exception into a giant orchestration switch statement. You are extending a model. That is the difference between building a feature and building a platform.

The interesting part is what a connection really means

This is where visual orchestration stops being a UI problem and becomes an engine design problem. On the canvas, a connection is just an edge. Inside the core, that edge carries meaning.

It is the system saying:

• this service depends on that service

• this dependency needs to be resolvable at runtime

• this relationship should turn into infrastructure wiring

That usually means the engine has to synthesize actual deployment semantics from what looked like a simple line in the UI. A connection can imply internal addressing. It can imply generated environment variables. It can imply service discovery. It can imply dependency ordering. It can imply whether certain values should come from plain config or from secrets.

That is why I like the architecture diagram so much when explaining this system. It makes it obvious that the canvas is only the first layer. The real work happens in the path from graph state to orchestration logic to generated resources. That translation layer is the engine. And if it is not designed carefully, the whole system becomes either too magical or too fragile.

“Magic” is useful until it breaks trust

This is probably the hardest design tradeoff in a tool like this. A visual orchestrator should not force users to manually wire every single thing. If it does, the whole abstraction fails. But it also cannot become one of those systems that hides so much logic that users stop understanding what is happening underneath. That is where infrastructure tools get dangerous. If a platform silently makes a bunch of decisions for you and those decisions are wrong, you do not just get a weird UI bug. You get broken deployments, bad defaults, leaky abstractions, or security mistakes. So the question is never just “what can we automate?” The better question is:

what can we automate safely, consistently, and transparently enough that users can still build a correct mental model?

That is where a lot of the real product thinking in KubeOrch Core sits. Not every complexity should be exposed. But not every complexity should be hidden either. Some things should absolutely be inferred. Others should remain visible because they reflect real infrastructure constraints. That balance matters a lot more than people think. Security defaults are part of the productOne thing I feel strongly about is that a visual infra tool should not become “easy” by quietly becoming careless. There is a wrong way to simplify Kubernetes, and it usually looks like this: hide everything, wire everything automatically, and hope users never ask too many questions. That is fine for screenshots. It is terrible for trust. If a platform is generating real infrastructure, security defaults are part of the product. Things like separating config from secrets, avoiding unnecessary exposure, and making relationship wiring explicit enough to be understood are not optional details. They are central to whether people can rely on the system.

If you want to build in this space, KubeOrch/Core is open source, and I think this layer of infrastructure tooling still has a lot of room for new ideas.