Liwiro

Liwiro is a local-first platform for designing, generating, running, and managing services. It is built around a straightforward observation: software demand is growing faster than teams can hand-build, connect, deploy, and maintain every service. Developers are still essential, but they have become a bottleneck when every change starts as a manual implementation task and ends as a separate operational task.

The goal is not to remove people from software development. It is to give people a better control surface. A developer or operator describes what a service should do, reviews the result, and stays in charge of the system after it is running.

From intent to a running service

The core of Liwiro is LAPIS, a JSON-based declarative service format. A LAPIS document describes service metadata, authentication, data models, and endpoints. It can be edited in the Service Builder, edited directly as JSON, uploaded from a file, and revisited later in the Service Manager.

From that one contract, Liwiro can:

• validate the service definition before it changes runtime state
• generate a runnable Flask API
• choose and manage a local runtime port
• start the generated service as a managed child process
• persist its contract and runtime metadata
• expose route documentation and example requests
• let an operator test, update, restart, stop, or remove the service

This makes the specification a living source of truth rather than a document that drifts away from the code and the deployed system.

How the stack fits together

flowchart LR
  A[Service Builder] --> B[LAPIS contract]
  B --> C[Liwiro backend]
  C --> D[Validate]
  D --> E[Generate API]
  E --> F[Managed service process]
  F --> G[VDB]
  C --> H[Service Manager]
  H --> F

What the platform includes

The frontend is a Next.js operator workspace with setup and sign-in, Service Builder, service fleet and detail views, route testing, VDB and VI portals, settings, user administration, and public documentation. The Flask backend owns validation, generation, runtime configuration, process control, and the APIs used by the workspace.

Generated endpoints support three useful levels of behaviour:

• CRUD for direct model-backed create, read, update, and delete work.
• Custom VQL when an endpoint needs a shaped data operation.
• Versa when it needs procedural logic or a multi-step workflow.

The browser does not receive direct database or runtime access. Liwiro mediates those actions through the backend, keeping credentials, transport choices, and permission checks on the server side.

Why it matters

Most generators stop after creating a codebase. Liwiro continues through the harder part: operating the result. The same contract used to create a service is available when the service must be inspected, tested, changed, restarted, or deleted. That shortens the path from an idea to a usable system while keeping the work reviewable and reversible.

Liwiro widens the software-innovation bottleneck by making repeatable service work declarative and operationally manageable. Humans can spend more time on product decisions, domain rules, and exceptions that genuinely require judgment, rather than rebuilding the same service plumbing for every new idea.

Relationship to Verun

Liwiro is the operator-facing layer of a larger stack. It uses Verun for persistent data operations through VDB and for custom scripting through the Versa interpreter. Liwiro provides the workflow and governance around those capabilities; Verun provides the underlying runtime building blocks.

Project scope

Built from 2025 to present as designer and implementer. The repository includes the control plane, frontend workspace, LAPIS schema and examples, generator, process manager, documentation, and regression tests.