Kitwork
Runtime workbench for multi-tenant websites
A Go host where each site is a folder, each folder is a runtime node, and a small JavaScript subset can be compiled to bytecode and executed on a hand-written stack VM. It is the place where I test the ideas from this site in real pages.
Project context active
01 / Why
Why it began
Kitwork began after years of building applications on top of runtimes I did not control. I wanted to understand what really happens between an incoming request and a response, and what changes when the host, compiler, bytecode, virtual machine, and tenant boundary are designed as one system.
02 / Built
What I built
The project is a Go host for folder-based tenants. A deliberately small JavaScript subset is parsed, compiled to bytecode, and executed by a hand-written stack VM. Native capabilities connect guest code to routing, templates, data, HTTP, collections, JITCSS, and the small browser runtime without pretending that tenant code owns the machine.
03 / Learned
What it taught me
The most important lesson has not been raw speed. It has been clarity of authority. Source code describes intent; the compiler transforms it; the VM executes instructions; the host decides which parts of the outside world are available. Performance, isolation, caching, and developer experience all become easier to reason about when those boundaries are explicit.
A tenant is a boundary, not only a folder.
Native capabilities should make authority visible.
Static work should avoid VM execution when possible.
The runtime should remain small enough to understand.
04 / Today
Where it is now
Kitwork is active and still changing. This website runs as one of its tenants, so new ideas are tested against real pages before they become abstractions. The goal is not to present a finished platform. It is to keep the runtime understandable while the work becomes more capable.
Related writing