Verun: The Runtime Beneath a Managed Service

Most services begin with the same invisible work: set up storage, decide how requests become queries, add authentication, add a place for custom business logic, and expose the result through a transport. That repeated foundation work is one reason developers become a bottleneck. It is necessary work, but it is often rebuilt before a team can reach the part of the product that is actually new.

Verun is the runtime layer used by Liwiro to reduce that repetition. At the linked Liwiro revision, it is a Java 11 Maven project with two modules: VI and VDB. The split is simple and useful: VI runs Versa code; VDB owns data and commands.

VI runs custom service logic

VI is the Versa interpreter. It reads .versa source, tokenizes it, produces an abstract syntax tree, and evaluates it inside a runtime context. Scripts can use native modules and VDB helpers.

This is the right path when a generated endpoint needs branching, transformation, orchestration, or a multi-step operation that does not fit a direct database action. It is not a reason to turn every simple route into a script. A standard create, read, update, or delete route should stay a standard data operation when that is all it needs to do.

VDB owns data and authority-aware commands

VDB manages domains, databases, collections, model metadata, BSON-backed persistence, VQL commands, sessions, users, roles, and stored scripts. It is available through a console, HTTP, Unix sockets, and local named-pipe support. This gives services a common data layer instead of a fresh database integration per project.

The important design boundary is that VDB can do its core work without depending on VI. VI calls VDB through its public API when a script needs data. That keeps storage concerns clear and makes it easier to reason about which part of a request is data handling and which part is custom program logic.

How Liwiro uses both

Liwiro turns a LAPIS contract into a running service. A route can be one of three kinds:

1. CRUD for a direct operation on a model.
2. Custom VQL for a configured database command.
3. Versa for procedural behaviour.

The control plane validates that contract before creation, then generates the service, starts it as a managed process, and records its runtime state. VDB serves the data paths; VI serves the script paths. Liwiro adds the operator workflow around both: documentation, route testing, lifecycle controls, and permissions.

The practical outcome

Verun does not remove the need for developers. It removes some of the repeated setup that consumes their time. A team can concentrate on service rules, data shape, and product behaviour, while relying on a shared interpreter and database layer for the recurring mechanics. Liwiro then keeps the generated system visible and manageable after it starts running.

That is the useful form of automation: narrower manual plumbing, clearer boundaries, and more human attention available for the decisions that are actually difficult.