Beta
Kitwork is in public beta — spin up your first service from the starter
template.
Get
started →
Kitwork began as one developer's refusal to keep building on someone else's land. This is the story of how a lesson learned the hard way became a runtime you fully control.
01 — WHERE IT STARTED
Years ago a small price-comparison site — written from scratch in Go — climbed into Vietnam's top 100 e-commerce sites. It ran on a single 1-core server, and for a while it worked. Then, almost overnight, a search-engine change de-indexed it and the traffic vanished. The lesson landed hard and never left:
"If you build your house on someone else's land, you can lose it overnight."
The modern cloud only deepens that dependency. A typical platform stacks Redis for cache, Kafka for events, Consul for discovery, Kubernetes to orchestrate it all — each brilliant on its own, exhausting together, and demanding an operations team just to keep the lights on. Worse, the moment your code is compiled and deployed, your logic freezes inside a binary, reachable only through rigid pipelines.
The question that started everything was uncomfortable: what if you didn't have to rent any of it?
02 — A DIFFERENT QUESTION
Most engines chase one thing: how fast a line of code runs. Kitwork started from a different place — what actually costs a cloud system at scale? Rarely a slow instruction. It's the repeated runtime initialisation, the uncontrolled allocation, the context switches, the garbage collection — the endless small state changes.
We call the answer Energy Computing: model a system as E = W × T × S — work, time, and state transitions — and win by making fewer decisions, not faster ones.
And the other half of the question: why must logic stand still? If code is compiled ahead of time into bytecode, it stops being frozen and starts being portable — prepared so completely that the machine never has to ask again, only run.
"Bytecode is not about being low-level. It is about being done thinking."
03 — WHAT WE BUILT
Kitwork compiles a deliberately small, JavaScript-familiar language into bytecode and runs it on a custom stack-based virtual machine written in Go — no V8, no containers, no node_modules. Compute, data, edge and authentication live together in one process you own. Deploy a folder, get a live service.
In a cluster, every node runs that same runtime and simply takes a role — Gateway, Coordinator, or Worker. When one falls, another assumes its duties. The system degrades, but it does not die.
"A strong system is not one that never fails — it is one that keeps working when failure comes."
Measured, not marketed. Every figure here is reproducible against the engine.
04 — HONEST BY DESIGN
There are no borrowed logos on this site and no invented metrics. The products we point to are the ones we actually build and run on Kitwork ourselves — KitData, Bytecode, and the very site you're reading. The engine is open source under AGPL, and Kitwork is in public beta: you can download it, read every line, and own what you deploy.
05 — THE HANDS BEHIND IT
Kitwork is built by Huỳnh Nhân Quốc — a self-taught engineer from Tam Kỳ, with no degree, no investors, and no team. For a stretch of years he delivered packages by day to keep the servers paid, and wrote code by night. The engine that runs this cloud was built the same way: from string to []byte upward, understanding every layer before depending on it.
06 — WHERE IT'S GOING
The goal was never to add one more framework to the pile. It's a runtime you can hold in your hands — that boots in single-digit milliseconds, survives the loss of a node, and answers to no one but you.
"Go outside while it is still light."