KubernetesJS: The React Moment for Cloud Infrastructure

No more YAML. Just types.

Today we're announcing KubernetesJS — a fully typed, zero-dependency TypeScript client for Kubernetes. It lets developers write infrastructure the same way they write applications: modular, composable, testable, and understandable.

Just as React replaced template spaghetti with reusable components, KubernetesJS replaces brittle YAML and Helm charts with real code.

Kubernetes DX needs an upgrade

Most developers today use Helm or kubectl to manage Kubernetes resources. While powerful, these tools are deeply tied to the past:

• Helm is fundamentally a templating engine. It wraps YAML in conditionals and patches, but the result is often more complexity, not less.
• kubectl is a CLI tool designed for terminals and stdout, not for composition.

Popular libraries like @kubernetes/client-node and kubernetes-client only run in Node.js environments. They cannot be used in the browser (and one of them has not been updated in 5 years).

KubernetesJS breaks that limitation.

Today, KubernetesJS is the smallest, fastest, and most versatile Kubernetes client available:

We built it to work in both Node.js and browser environments. This opens the door for something that was previously nearly impossible: frontend developers building real-time Kubernetes dashboards and automations directly in React. To make that even easier, we even generate TanStack Query hooks from KubernetesJS types—so you can consume Kubernetes data like you would any API, using React hooks.

Now frontend developers can own and operate infrastructure from the browser.

What if infrastructure felt like code?

KubernetesJS brings the developer experience of modern JavaScript to Kubernetes:

• You import a client.
• You write fully typed, predictable API calls.
• You organize infrastructure into functions or modules.
• You test and reuse logic across environments.
• You debug and inspect like you would any application.

There's no need to shell out to kubectl, parse stdout, or manage layers of templating logic. Just use the language and tools you already know.

Here's a basic example:

import { KubernetesClient } from 'kubernetesjs';

const client = new KubernetesClient({
	restEndpoint: 'http://127.0.0.1:8001',
});

await client.createAppsV1NamespacedDeployment({
	path: { namespace: 'default' },
	body: {
		apiVersion: 'apps/v1',
		kind: 'Deployment',
		metadata: { name: 'hello-world' },
		spec: {
			replicas: 1,
			selector: { matchLabels: { app: 'hello-world' } },
			template: {
				metadata: { labels: { app: 'hello-world' } },
				spec: {
					containers: [
						{
							name: 'app',
							image: 'node:18-alpine',
							command: ['node', '-e', 'require("http").createServer((_,res)=>res.end("ok")).listen(3000)'],
							ports: [{ containerPort: 3000 }],
						},
					],
				},
			},
		},
	},
});

It's just code. It runs anywhere and behaves the way you'd expect.

Helm was "Handlebars"

If you've ever worked with frontend frameworks before React, you'll remember Handlebars and jQuery templates. They worked, until they didn't.

React succeeded because it took a big leap: It gave developers a programming model, not just another syntax layer.

That's what we're doing with KubernetesJS.

Instead of fighting with values.yaml overrides and nested chart trees, you create functions. You pass parameters. You write logic. And you gain clarity.

function createPostgresDeployment(name: string) {
	return client.createAppsV1NamespacedDeployment({
		path: { namespace: 'default' },
		body: {
			apiVersion: 'apps/v1',
			kind: 'Deployment',
			metadata: { name },
			spec: {
				/* ... */
			},
		},
	});
}

Kubernetes primitives become reusable components. You can version, test, share, and refactor them—just like any other codebase.

Infrastructure you can test

Testing infrastructure has always felt like a bolt-on: shell scripts running kubectl get, hand-written checks, or expensive preview environments.

With KubernetesJS, infrastructure becomes testable by default.

describe('Postgres Deployment', () => {
	it('creates a postgres deployment and checks readiness', async () => {
		const deployment = await client.createAppsV1NamespacedDeployment({
			/* ... */
		});

		expect(deployment.metadata?.name).toBe('postgres-pgvector');

		const status = await client.readAppsV1NamespacedDeployment({
			path: { namespace: 'default', name: 'postgres-pgvector' },
		});

		expect(status.status?.readyReplicas).toBe(1);
	});
});

You can assert your expectations right inside your test suite. This opens the door to continuous testing, dry runs, safe previews, and eventually—real CI/CD for infra as code.

Who it's for

KubernetesJS is designed for:

• Fullstack developers who want to deploy infra without learning Helm.
• Platform engineers who want to create reusable modules across services.
• Teams migrating away from brittle YAML-based pipelines.
• Any JavaScript/TypeScript shop who wants better DX for their clusters.
• Frontend engineers who want to build dashboards and tools that talk directly to Kubernetes from the browser.

If you've ever wished you could just "write infrastructure like app code," this is for you.

Try it now

You can get started with a single command:

npm install kubernetesjs

Or visit the repo: github.com/constructive-io/kubernetesjs

---

This isn't just a new client. It's a new model.

Just like React unbundled the frontend, we believe KubernetesJS will unbundle cloud infrastructure and make it accessible to millions more developers.

If you've ever wanted to feel the same clarity and composability you get in application code—now you can.

KubernetesJS is the React moment for DevOps.

And it's only the beginning.

— The Constructive Team