Hello, brick
Compile a four-line C program to a portable WASM bundle and run it.
Every compiler tutorial starts the same way. We will too, because the goal here is to prove the toolchain is wired up end to end before you build anything real. By the time you reach the bottom of this page, you will have a content-addressed .brick file on disk and a running program greeting you from inside Wasmtime.
The source
Save the following four lines as hello.c in an empty directory. No build script. No Makefile. No header gymnastics.
#include <stdio.h>
int main(void) {
printf("Hello, brick\n");
}Standard C99. lly ships with a libc that targets WASI, so the familiar stdio.h resolves without any flags. The same source compiles unchanged on Linux, macOS, and Windows because the output is a WASM bundle, not a native executable.
Compile and run
Two commands. The first invokes the C frontend plugin to lower the source into a single-module brick. The second hands that brick to the runtime plugin, which boots a Wasmtime instance and runs _start.
Forty kilobytes is the whole program: WASM bytecode, a manifest, and a SHA-256 fingerprint. Open it with lly bundle inspect hello.brickif you want to see the layout. The fingerprint is deterministic, so rebuilding the same source on a different machine produces a byte-identical artifact.
Extension dispatch
The interesting trick is that lly compile does not care which language you hand it. The extension picks the frontend. hello.cpproutes to frontend-cpp. hello.js routes to frontend-js. hello.rs would route to frontend-rust if you had it installed. The output format is identical in every case, because every frontend lowers to the same intermediate representation before the WASM backend takes over.
That means the rest of the toolchain — lly run, lly bundle inspect, lly void deploy, the CAP fleet, the brick cache — never has to know which source language produced a given brick. A C HTTP server and a Next.js app are the same kind of object once they hit disk.
What just happened
Behind those two commands, lly resolved the frontend-c plugin from ~/.lly/plugins/, parsed hello.c, lowered it through BIR (the brick intermediate representation), emitted a wasm32-wasi module, signed and packed the result into a brick, and then handed that brick to the runtime plugin which instantiated it inside Wasmtime with WASI preview1 imports wired up. The whole round trip took less than 50 milliseconds.
Next step
A C hello-world proves the pipeline works. The point of lly, though, is that the same flow scales to real applications. Compile a Next.js App Router project into a single brick with the nextjs plugin, then push it to the LILY fleet with lly void deploy. Two commands, public URL.
Continue with Deploy a Next.js app to do exactly that, or read Bricks are bundlesfor the format details, or jump to lly compilefor the full flag reference.