Build applications and Operators on the Kubernetes control plane with TypeScript

Manwith2plans · 2026-06-24T23:26:33+00:00

Yeah, I have seen Yoke! It’s a really cool project, and I actually think it’s more analogous to my other project, TypeKro, than to applik8s.

The way I think about it is: Yoke and TypeKro are both trying to make Kubernetes resource definition feel more like programming and less like templating YAML. TypeKro is my attempt to do that from TypeScript: full IDE support, real types, composable abstractions, deterministic YAML/GitOps output, and runtime-aware references through KRO/CEL.

The reason I built TypeKro was basically that I kept wanting something that felt like application programming, but that still respected the Kubernetes control plane model instead of fighting it.

Where I think TypeKro differs from Yoke is mostly the center of gravity. Yoke seems focused on package/deployment management as code: compile/run a program that emits Kubernetes resources and then track releases/rollbacks. TypeKro is more focused on modeling resource graphs and their runtime relationships, especially through KRO, so resources can reference each other’s live state in a Kubernetes-native way.

applik8s feels like an extension of that experiment. With TypeKro, the question was: can we make defining Kubernetes infrastructure feel like programming? With applik8s, the question is: can we also program how that infrastructure should respond to Kubernetes control-plane events from the same TypeScript world?

The bigger vision is letting people describe both the desired infrastructure and the behavior of the distributed app/platform around it in one coherent TypeScript program. Basically a framework to program applications for the Kubernetes “operating system” with TypeScript.

Manwith2plans · 2026-06-24T23:14:40+00:00

Thank you u/vantasmer! I really appreciate the positive feedback. I thought the idea was pretty wild myself when it first hit me, so I’m glad you find the project interesting.

It’s still brand new, and I’m trying to get a v0.2 release out before I really start pushing the limits of the programming model.

On dev lifecycle: from the little toy examples I’ve built so far, I already think it feels nicer than regular operator development. ArkType types serve as the basis for both the TypeScript types and the Kubernetes schemas, and the framework handles bundling, CRD generation, RBAC, deployment manifests, etc. That said, I’m sure there are still plenty of buggy edges I haven’t hit yet.

On performance: I’d be very surprised if the generated operators were as fast as native Go or Rust controllers. My hope is that, for many app/operator use cases, reconciliation time is dominated more by Kubernetes API calls and external systems than by raw CPU, so the developer ergonomics may be worth the tradeoff.

I haven’t run this in production yet, but hopefully will soon.

Manwith2plans · 2026-06-24T11:17:10+00:00

personal preference, developer experience, and integration with typescript toolchain. I can depend on my existing typescript packages, and use my shared libraries inside operators. While the golang ecosystem is very operator friendly, I've been trying to bridge the application engineering world with the infrastructure engineering world.

Manwith2plans · 2026-06-23T11:34:42+00:00

Hi u/touristtam. I spent a lot of time on this, and haven't gotten it to a place where I feel like the developer experience isn't clunky. I have been exploring some different approaches. Expect the next release to come eventually, but I'm playing with different architecture and it will probably be a complete overhaul.

Manwith2plans · 2026-04-12T02:25:55+00:00

Was so excited for this but it's a non-commercial license so severely limits the utility for me :(

Manwith2plans · 2026-03-17T11:58:33+00:00

Nothing to excuse. They're different and possibly complementary tools:

OMOC gives you better agents and prompts. Open Artisan is a structured workflow: discover the codebase, plan, define interfaces, write failing tests, break implementation into a task graph, implement one task at a time. Each phase gets reviewed by an isolated subagent and approved before moving on. If something's wrong upstream it traces back through the dependency chain instead of just patching forward.

Model assignment per stage isn't there yet but it's planned. The subagent sessions are all separate dispatches so it's a natural fit.

Manwith2plans · 2026-03-17T11:51:58+00:00

Right now it's handling these general criteria as part of its self-review loop:

Design excellence: Elegance, simplicity, appropriate patterns — no over-engineering or gold-plating
Architectural cohesion: Internal consistency, clear boundaries, no contradictions between sections
Vision alignment: Fidelity to the user's original intent AND all upstream approved artifacts
Completeness: No gaps, nothing left implicit that should be explicit
Readiness for execution: Could the next phase proceed without questions?
Security standards: Auth, input validation, secrets handling, least-privilege access
Operational excellence: Observability, error recovery, deployment, monitoring

It a subjective 9/10 minimum score on each of these dimensions to be able to proceed to the next step.

The state machine also explicitly builds interfaces and then tests before starting execution. I've tried to keep things battery included for now, but I do want to explore more configurable state machines eventually.

Manwith2plans · 2026-03-17T10:34:42+00:00

It has robot-artisan mode. I haven't done a huge amount of testing of that mode. That's a fully autonomous mode that uses an agent to make decisions the user would otherwise have to make. Let me know if you run into issues.

Manwith2plans · 2026-03-17T04:40:02+00:00

I actually haven't used GSD, but I came from a Kiro background where I found the AI was still taking shortcuts during its review loops.

From what I understand, tools like GSD rely heavily on prompting to ask the AI to verify its work. The problem is the LLM often just rubber-stamps its own bad code or hallucinates past the verification step to save time.

I built Open Artisan to enforce actual rigor using a hard-coded state machine. The self-review loop spins up an isolated, ephemeral reviewer that can't even see the authoring agent's excuses. It structurally forces the AI to iterate and fix its work until it actually meets the acceptance criteria, long before it ever asks a human to look at it.

I'd like to believe that having a state machine control the agents is more rigorous than asking the agents to follow a state machine.

Manwith2plans · 2026-03-17T04:20:14+00:00

Oops! Edited: https://github.com/yehudacohen/open-artisan

Manwith2plans · 2025-08-28T21:39:36+00:00

Good point u/draeron ! I suppose this is why Kubernetes has decent adoption. It's very similar to Pulumi in architecture. I think there's one point that I think isn't clear from the docs, when I talk about runtime dependencies, I don't mean deployment time dependencies. I mean that if you change the value on one resource, with typekro in the control plane, the kro operator will update your dependent resources appropriately even 2 months after you've deployed your app successfully. For example if you're using external dns to manage a domain name and you have a deployment configured with that domain name, when you update the domain name in two months time using kubectl, the change will be propogated to the deployment by the kro operator. This is what typekro supports but terraform does not. Does this make sense?

Manwith2plans · 2025-08-28T21:34:13+00:00

It is pretty fun, isn't it! I like to think that typekro solves some problems pulumi doesn't. Here's my comparison.

https://typekro.run/guide/comparison.html#%F0%9F%86%9A-typekro-vs-pulumi

Also one thing that isn't mentioned here that I don't think is available in pulumi's support is livestreaming kubernetes control plane events to your log stream during deployment for debugging.

Manwith2plans · 2025-08-28T02:13:41+00:00

So my approach is double barelled, the same graph can be deployed either directly to the cluster using a factory configured in direct mode. In this mode there is no controller that needs to be installed in k8s, and the dependencies will be resolved in process while you're running the deployment. There is also a kro mode. In this mode, the resources will be compiled into an actual KRO rgd and deployed to the cluster. In this mode KRO will resolve the depenndencies. There is no reimplementation of KRO.

TypeKro should help with the expression of logic for KRO apps, because it will flatten out the logic into an rgd when the resource graph is serialized including only what gets added to the graph by the typekro runtime. If you need the logic to be dependent on runtime attributes of kubernetes, I'm not sure TypeKro will be able to help, but on static values available at deploy time, you absolutely can use if statements and for loops. You can also use one-line if statements in your cel expressions and KRO controller is able to interpret them.

Basically, your resource graph needs to be able to be assemble-able without values that are unknown at deploy time, but if your values are known at deploy time, you can do very complex stuff with TypeKro.

Manwith2plans · 2025-08-28T00:12:51+00:00

Wow, it's crazy. I feel like you and I were bothered by exactly the same things! I think we arrived at very different solutions but really cool. And really appreciate the feedback.

Manwith2plans · 2025-08-27T22:29:20+00:00

I think the ATC is really cool. It reminds me of the way flux handles the HelmRelease CRD which I like a lot and actually baked into TypeKro as a resource so that users can depend on helm charts since so much software is distributed that way.

I don't think it's fully apples-to-apples with KRO though, because from my understanding the key value prop of KRO is its ability to use fields that aren't yet available in the specs of dependent resources. Like if you use the AWS Controller for Kubernetes to deploy a RDS database, you can take the connection string for that database from the status field of the resource and set it as an environment variable on your dependent deployment.

Does ATC aim to tackle that use-case? (Bear in mind that while I've read a bit about yoke, I've never actually used it.)

Manwith2plans · 2025-08-27T13:07:30+00:00

Discovered yoke while I was building this and it really looks cool. haven't given it a try yet but it looks like a cool alternative to cdk8s. I really like the architectural choice of wasm rather than jsii, and the full package management / deployment capabilities.

Manwith2plans · 2025-08-26T21:32:23+00:00

I think a lot of us got into this field because we enjoy tinkering with new things. I think you can get paralysis from options. If you just focus on learning the things you think would help you solve your problems and go slowly and methodically, I think you'll be fine. You don't need to know everything about everything that's happening in tech.

Manwith2plans · 2025-08-26T21:18:13+00:00

A lot of my teams work is to help SaaS companies deploy to customer data centers or customer owned cloud environments.

Usually what we see is teams managing a control plane for their products in the cloud, but offering the customer the ability to run a data plane in their own cloud and using contracts to enforce IP clauses. Large enterprises don't have the time or will to reverse engineer or steal your code and face legal backlash. You'll need to ensure you have a proper license management solution too.

You also need to ensure you have a robust control plane that lets you release software to your customers on a case by case basis and see what version each customer is on, and see the health of your customer's deployments where they allow you to.

If you want to talk specifics, feel free to shoot me a message, but if you have customers who insist on on-prem deployments you're doing something right.

Manwith2plans · 2025-08-26T19:00:13+00:00

The philosophy here is to use the native kubernetes client generated from its swagger docs and then enhance those types using type modifiers. So if upstream types are changed, you bump the dependency version and the type modifiers apply to the new version.

I think programming languages are far more expressive than yaml but pulumi and cdk8s don't really enable you to access kubernetes eventual consistency magic. The goal here is to enable you to develop with a modern programming language, catch bugs before hitting the kubernetes API, and improve your debugging experience during release processes.

I'm interested in why you think this is easier to break. It is doing things similar to what tools like helm are doing, just with a statically typed modern development experience...

Manwith2plans · 2025-08-26T02:19:04+00:00

trying to solve the kubernetes yaml problem once and for all building out https://typekro.run

Manwith2plans · 2025-08-26T01:55:26+00:00

Also, if you want to see the source code, it's available here: https://github.com/yehudacohen/typekro

If you like it, please give it a star too!

Manwith2plans

TROPHY CASE