Software should be legible. You should be able to look at a running system and know, with confidence, what it did, what it was allowed to do, and what happened when something went wrong.
Most runtimes today treat observability and security as layers you bolt on. They are afterthoughts, patched in after the architecture has already been set. Dotlanth takes the opposite approach. Every execution decision is deliberate, every side effect is recorded, every permission is explicit.
Dotlanth is a runtime designed from scratch around three principles: one file, one runtime, and nothing hidden.
You describe what you want to build in a plain-language file called a dot file. Not JSON, not YAML, not a configuration format masquerading as a programming language. Something closer to pseudocode: readable on the first pass, writable without a manual.
A dotDSL file: the entire definition of an HTTP API
dot 0.1
app "hello-api"
allow log
allow net.http.listen
server listen 8080
api "public"
route GET "/hello"
respond 200 "Hello from Dotlanth"
end
endThat file is the complete source of truth. The runtime reads it, validates it, enforces the permissions you declared, and begins execution. No imports. No boilerplate. No hidden defaults.
At the heart of Dotlanth is a register-based virtual machine. Your dot file compiles into a typed internal representation that the VM interprets directly. The VM is intentionally simple: it executes instructions, manages a register file, and calls out to the host runtime when it needs to make something happen in the world.
That call-out, the syscall, is where everything interesting happens. Writing a log? Syscall. Starting an HTTP server? Syscall. Every side effect is routed through a single, centralized boundary. This is not an implementation detail. It is the architecture.
Why does this matter? Because a single choke point means a single place to enforce permissions, a single place to record what happened, and a single place to audit. There are no clever shortcuts that bypass security. There are no logs that silently disappear. The architecture makes good behavior the only path forward.
The capability model is deny-by-default. If you haven’t declared allow net.http.listen in your dot file, your process cannot listen on a socket. Full stop. Security is not a setting you can forget to enable. It is the starting state.
From the moment a program begins executing, Dotlanth is recording. Run metadata, structured log events, server start times, incoming requests, and outgoing responses. All of it flows through the syscall boundary and into a local database called DotDB.
This is what we call record-first. Observability is not a plugin. It is the default mode of execution. You do not opt in to having a run history. You would have to actively opt out. We do not give you a way to do that in v26.1.
The practical effect is immediate: you run your service, a request comes in, and you have a complete structured record of what happened before the request, during it, and after it. That record is queryable. It is local. It is yours.
One File
Your entire API lives in a single dot file. The runtime derives everything from it.
One Boundary
All side effects (logs, network, state) route through a single capability-gated syscall layer.
One Record
Every run is automatically persisted. You always know what your software did.
What comes next builds directly on this. Deterministic replay. Richer DSL expressions. More syscall surface area. Developer tooling. A visual interface for run history. All of it requires a trustworthy foundation, and that is what v26.1.0-alpha is.
Software that is legible. Execution that is trustworthy. A runtime that tells you exactly what it did.
That is what we are building. v26.1.0-alpha is the first brick in that wall. If you are a builder who cares about runtime transparency, security by design, and execution you can actually reason about, we’d love for you to try it.