Multi-language runtime support via base images

[richardkiene]

Overview

Enable Fabricks to run code written in languages other than Rust (Python, JavaScript, Go, etc.) by supporting base images similar to Docker's FROM directive. This unlocks use cases like running MCP (Model Context Protocol) servers, which are commonly written in Python and JavaScript.

Motivation

• MCP servers: Great use case for Fabricks - security-critical, often third-party code, benefit from WASM sandboxing
• Developer adoption: Most developers don't write Rust; supporting Python/JS dramatically expands who can use Fabricks
• Capability-based security: WASM's sandboxing makes it safe to run untrusted code with explicit capability grants

Design Decisions

Composition Timing

Build time - Compose base runtime + user code during fabricks build so runtime stays fast.

How User Code Gets Into Components

WASI filesystem virtualization with componentize-py/jco under the hood:

• Base layer: Language runtime (Python interpreter, Node.js, etc.)
• User layer: Virtual filesystem with user's source files
• Composed via wasm-tools compose at build time

Build vs Adopt Runtimes

Wrap Bytecode Alliance tools:

• Use componentize-py for Python
• Use jco for JavaScript
• Fabricks provides the UX layer, caching, and OCI integration

Target User Experience

[from]
image = "fabricks.dev/runtimes/python:3.12"

[source]
path = "."
entrypoint = "server.py"

[capabilities.network]
listen = [8080]

User runs fabricks build and Fabricks handles:

1. Pulling the base runtime (cached)
2. Composing with user code
3. Producing a multi-layer OCI artifact

Proposed OCI Structure

{
  "layers": [
    {
      "mediaType": "application/vnd.fabricks.runtime.v1+wasm",
      "digest": "sha256:abc...",
      "annotations": { "fabricks.runtime": "python:3.12" }
    },
    {
      "mediaType": "application/vnd.fabricks.module.v1+wasm",
      "digest": "sha256:def...",
      "annotations": { "fabricks.entrypoint": "server.py" }
    }
  ]
}

Layer 0 (runtime) is shared/cached across all services using that runtime.

Implementation Phases

1. Multi-layer OCI infrastructure - Support for multi-layer manifests, layer caching, composition at build time
2. Python runtime support - Integrate componentize-py, publish fabricks.dev/runtimes/python base images
3. JavaScript runtime support - Integrate jco, publish fabricks.dev/runtimes/node base images
4. Additional runtimes - Go (TinyGo), Ruby, etc. as demand warrants

Related Issues

• Add default-external network for standalone services with listen ports #17 - Default external network for standalone services (affects how runtime services get network access)
• Future: MCP as first-class service type

References

• componentize-py - Python to WASM Component
• jco - JavaScript Component Tools
• WASI-Virt - Virtualize WASI capabilities
• wasm-tools compose - Component composition