Forget everything
you know about cloud.
Every assumption about how infrastructure works, how applications scale, how teams deploy. Built for a world that no longer exists. We started from scratch. Not a better Kubernetes. Not a smarter serverless. Something else entirely.
Start buildingOne program.
A million bricks.
Cloud infrastructure loses you at compile time. Your code gets flattened into binary and every logical structure disappears. The machine gets instructions. You lose context. That context is what LILY keeps.
We compile code in the shape it was written: classes, methods, functions, logical units. Each unit becomes a Brick. What you end up with is still one program, just broken into many small independent pieces, each one knowing exactly what it is and nothing more.
Software as flow,
not a stack.
We see servers as nothing more than a runtime for Bricks. Machines exist to reassemble these blocks in a continuous flow directly above the hardware, no operating system overhead, no container layer in between.
The result is software as a deeply decentralized product running directly on the machine. That opens up a lot of doors.
But what does
any of this get you?
Reproducibility
& Isolation.
We can isolate individual program parts, their memory access, data, and state. By snapshotting memory at the Brick level, we can granularly save and restore entire systems without the overhead of a full operating system.
Every Brick runs in its own isolated context. No shared state, no hidden dependencies. What you deployed yesterday runs identically today.
Scalability.
Our system doesn’t scale entire applications, only the parts that are actually under load. Program components that need more resources are individually offloaded to additional machines, while everything else stays put.
This lets us look at applications with far more granularity. If only your checkout is being hit, only your checkout scales.
Parallelization.
We know exactly which Bricks have persistent memory access. This means we can fan out multiple concurrent requests across Bricks in parallel and converge them only at the point where state is written.
The load itself becomes parallel, not at the application level, but at the level of individual program units.
Uninvasive
Fallback.
When a Brick fails due to a software error, we don’t just spin up a replacement. We restore the last known snapshot of that Brick, including its full state from the production setup, and continue processing from exactly where things left off.
True uninvasive fallback in production. No data lost. No manual intervention. No restart from zero.
Uninvasive
Observation.
We can tap into production at any point, intercepting and recording values as they pass between Bricks. No changes to your setup, no instrumentation required, no redeployment.
Read live values out of a running system without touching it. Observation as a first-class primitive, not an afterthought.
Merging
in Production.
We can see exactly which Bricks changed between two versions of a flow. If those changed Bricks have no persistent memory access, they can be migrated directly into a live production system, no downtime, no full redeploy.
Version your entire flow system. Migrate only what changed. Ship deltas, not deployments.
Cold & Warm
Starts.
Our Bricks don’t sit idle in RAM. Only the first few Bricks of a system, the entry points actually called on startup, are kept hot in memory. The rest of the system waits in long-term storage.
This makes hosting on LILY obscenely cheap. You pay for what your application actually uses, nothing more.
Superb
Redundancy.
Because we snapshot the persistent memory tied to each Brick, we can run the exact same flow on a second server in full synchronization, always. If server 1 goes down, server 2 takes over instantly.
No failover delay. No data loss. No intervention. This is how we guarantee 99.9999% uptime, baked into the program model, not bolted on as infrastructure.
