Telo is an execution engine (Micro-Kernel) that runs logic defined entirely in YAML manifests. Instead of writing imperative code, you define your routes, databases, schemas, screens, and AI workflows as atomic, interconnected YAML documents. Telo takes those manifests and runs them.
Built to be language-agnostic and infinitely extensible.
# Reconcile your manifest into a running application
$ telo ./examples/todo-app
{"level":30,"time":1771610393008,"pid":1310178,"hostname":"dev","msg":"Server listening at http://127.0.0.1:8077"}
Why use Telo?
- Open Standards: Built on YAML, JSON Schema, and CEL — no proprietary DSL.
- Static Analysis: CEL type checking, reference validation, and IDE diagnostics catch errors before runtime.
- Micro-Kernel Architecture: Telo itself knows nothing about HTTP or SQL. Everything is a module you import, scope, and compose with typed variable and secret contracts.
- Language Agnostic: Available as a Node.js runtime today, with a shared YAML runtime contract that allows for future Rust or Go implementations without changing your manifests.
What It Does
- Loads YAML resources and compiles CEL expressions (
!cel, !interpolate) into an in-memory registry.
- Resolves resource dependencies via a multi-pass init loop, handling ordering automatically.
- Indexes resources by Kind and Name for constant-time lookup.
- Dispatches execution to the controller that owns each Kind.
Example manifest
See examples/ for a list of working applications.
Status
Telo is under heavy development. While it is pre-1.0, breaking changes ship in minor releases — manifest shapes, kind schemas, and APIs can change between versions. Pin your imports and expect to update manifests when you upgrade. The core runtime, module system, and standard library are functional, but Telo is not yet recommended for production use.
1.0 lands when the Rust kernel reaches feature parity with the Node.js implementation — that is the milestone that freezes the manifest contract across runtimes.
The Meaning of Telo
The name Telo is derived from the Greek root Telos - meaning the "end goal", "purpose", or "final state". That is exactly the philosophy behind this runtime. In standard imperative programming, you have to write thousands of lines of code to tell a server exactly how to start. With Telo, you simply declare your desired final state.
You define the end state. Telo makes it real.
Philosophy
Modern platforms often spend disproportionate effort on technical mechanics-wiring frameworks, managing infrastructure, and negotiating toolchains-while the original business problem gets delayed or diluted. Telo pushes in the opposite direction: it treats kernel execution as a stable, predictable host so teams can concentrate on the business logic and outcomes instead of the plumbing.
By separating "what the system should do" from "how it is hosted", the runtime reduces friction for domain‑level changes. Teams can move faster on product requirements, experiment more safely, and keep conversations centered on value delivered rather than implementation trivia.
Telo also aims to join forces across all programming language communities, so the best ideas, patterns, and implementations can converge into a shared kernel truth without forcing everyone into a single stack.
YAML also makes the system more AI‑friendly than traditional programming languages: it is explicit, structured, and easier for tools to generate, review, and transform without losing intent.
Modularity
Telo is built around modules that own specific resource kinds. A module is loaded from a manifest, declares which kinds it implements, and then receives only the resources of those kinds. This keeps concerns isolated and lets teams compose systems from focused building blocks rather than monolithic services.
At kernel execution time, execution is always routed by Kind.Name. The kernel resolves the Kind to its owning module and hands off execution. Modules can call back into the kernel to execute other resources, enabling composition without tight coupling.
Architecture
The architecture is inspired by Kubernetes-style manifests: declarative resources, explicit kinds, and a control plane that routes work based on those definitions.
Those manifests were taken to the next level by allowing them to run inside a standalone runtime host.
See more at
License
Two licenses, split by directory. Each MIT directory carries its own LICENSE; everything else falls under the root LICENSE, the Sustainable Use License.
| MIT | Sustainable Use |
|---|
cel/, message-format/, sdk/, templating/, packages/glob/, packages/editor-protocol/ — the expression engine, the message core, the SDK and what a controller links against | analyzer/, kernel/, cli/ — what loads, checks and runs a manifest |
modules/, blueprints/ — the standard library | packages/ide-support/, packages/language-server/, packages/language-host/, ide/ — the editor tooling |
starters/, examples/, docs/, benchmarks/ | packages/runner-core/, packages/debug-wire/, packages/debug-ui/, apps/docker-runner/, apps/k8s-runner/ — the runners |
apps/hub/, apps/hub-web/, apps/plan-approval*/ | apps/studio/, apps/authoring-agent/, pages/ and everything not listed |
No MIT package depends on a Sustainable Use one, which pnpm run check:licenses enforces.
Contribution Note
By contributing, you agree that code and examples in this repository may be translated or re‑implemented in other programming languages (including by AI systems) to support the project’s polyglot goals.
