← Back to home
Open source · AGPL

Basalt

The deployment of the knowledge-based engineering workstation: a container stack described in one s-expression file, with an Emacs editing console, Gendl engines on Clozure CL and SBCL, and a monitor. One command reads the file, starts the containers on a shared network, and writes MCP client configuration so an AI agent can evaluate code inside any of them.

The point is reproducibility. A hand-assembled engineering box exists only on the machine it was assembled on. A Basalt deployment is a file, so the same environment comes up on a laptop, on a rented server, or on fifty of them, and a colleague gets it by cloning a repository. It is infrastructure as code for a live Lisp image a human and an agent share.

One command

Clone the repository and start the deployment. Images are pulled as needed, each container receives a generated instance name, services are health-validated, and startup prints the roster with the ports each one actually publishes.

$ git clone https://github.com/genworks/basalt
$ cd basalt && ./basalt up
[INFO] Assigning container instance names:
[INFO] Zarilk starts as the console
[INFO] Lisda starts as the engine ccl
[INFO] Moraal starts as the engine sbcl
[INFO] Lumune starts as the monitor
[INFO] Starting deployment Vyek
[SUCCESS] All services validated in 2s; the deployment is up
[INFO] Service roster:
Console Zarilk's console 6942->6942
Engine (CCL) Lisda's engine ccl 19080->9080
Engine (SBCL) Moraal's engine sbcl 29080->9090
Monitor Lumune's monitor (no published ports)

Deployment and instance names are generated per start; read yours off your own roster. The repository is public at github.com/genworks/basalt; issues and pull requests are welcome there.

What is in the deployment

A standard deployment is four services, each answering on its declared hostname. Which services a machine runs is declared in a file, not discovered by reading its history.

console
the Readymacs Emacs distribution: the interactive control surface, and the longest-running process in the stack
engine-ccl
Gendl on Clozure CL: HTTP, SLIME/Swank, and MCP
engine-sbcl
Gendl on SBCL, the second implementation, to check against
monitor
the autoheal watchdog: restarts services that stop passing their health checks

Additional services arrive by small configuration overlay repositories, licensed GDL Enterprise engines among them.

Restarts, recreates, and names

Every full start is a new deployment under a freshly generated name; the previous name is retired to a log and never reused. Containers carry generated instance names of their own: a restart keeps a container's name, a recreate assigns a fresh one. So an environment is never confused with its predecessor, and a report names exactly which incarnation misbehaved.

Several deployments can share one host, each with its own compose project, network, and port offset. Service hostnames stay the same inside each deployment, so nothing configured against a service name needs to know which instance it runs in.

Wired for agents from the first start

Startup generates MCP client registries covering every service the deployment declares, in Claude Desktop, Claude Code, Codex, and Grok formats, through Lisply-MCP. An agent evaluates code in the running engines the same way you do at the REPL, and the editing console's own terminal agents come preconfigured with the identical service roster.