melee
Hosting for small, single-purpose, mostly-idle Ruby apps: each one is compiled to a native binary, kept asleep until someone asks for it, and woken in about two milliseconds.
A melee app is a directory. It has an app.rb with routes in it, some .erb templates, some .sql
migrations, and a public/ folder. You push the directory; the server compiles it to a native binary and
serves it. When nobody is using it, nothing is running.
# app.rb
title "Notes"
get "/" do
render :index, notes: db.query("SELECT id, body FROM notes ORDER BY id DESC")
end
post "/notes" do
db.run "INSERT INTO notes (body) VALUES (?)", params.fetch(:body)
redirect "/"
end
melee new notes && cd notes
melee dev # http://127.0.0.1:4567
melee push # compiled, deployed, live
Where to go
| You want | Read |
|---|---|
| To know what this is and whether it fits | What melee is |
| To understand what happens when a request arrives | How a request reaches your app |
| To have written and deployed something | The tutorial |
| To look up a method | API reference |
| To solve a specific problem | The guides |
| To know what melee will not do for you | What melee cannot do |
| To run a server yourself | Operating melee |
If you are an agent writing app code, reference/llms.txt is the narrow index — the
app-facing surface and nothing else. llms.txt is this whole manual.
The state of things
melee is early. It runs, it is fast, and two real apps are deployed on it, but it is built and operated by the person who wrote it, and a few things a hosting platform normally has are missing: TLS is something you put in front, the CLI expects a checkout of this repository, and there is no recipe yet for standing a server up on a real host. What melee cannot do is the honest list, and it is worth reading before you build something on this.
The app-facing API — everything in the reference — has been through one deliberate design pass and is stable enough to write against. It is not frozen.