Introducing Dotlanth v26.1.0-alpha

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.

A new kind of runtime.

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.

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
end

That 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.

Designed around a clear boundary.

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.

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.

Every run leaves a trail.

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.

This is a foundation, not a ceiling.

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.