What a server needs

A Linux machine, root, Ruby, a built Spinel compiler and a checkout of melee. There is no package to install, and that is the biggest thing standing between melee and other people running it.

Be clear about the stage first. melee has only ever been operated by the person who built it. There is a working server, a working deploy, and a real sandbox; there is no installer, no systemd unit, no TLS and no backups. Everything on this page is true and none of it is a product.

The machine

What has to be on it

Ruby 4.0, with the sqlite3 gem. The build step (stdlib/bin/melee-build) is a CRuby script that the server shells out to on every deploy. Not needed to serve — only to build.

The gem is easy to miss and the failure is silent: the build step checks each migration by running it against a scratch database, and without sqlite3 that check is skipped, not failed. A server missing it builds happily and a migration with a typo first fails when the app next opens its database. gem install sqlite3.

The Spinel compiler, built from the commit melee is pinned to. It is a git submodule; you build it with make deps && make inside it. This is the part with no shortcut: there is no release binary to download.

A C compiler and libssl. Spinel emits C and links it; the app binary depends on libc, libm and libssl.

A checkout of the melee repository, because the server needs the standard library sources (--stdlib) and the build script. This is the honest core of the packaging problem: the server is not self-contained.

The two melee binaries, melee-server and melee, built with cargo build --release.

Getting them

From a checkout, with mise for the toolchains:

git clone --recurse-submodules <the melee repository>
cd melee
mise run setup          # tools, the Spinel submodule, the sqlite3 gem, a Spinel build
mise run build          # melee-server and the melee CLI into supervisor/target/release

mise run setup is written for a development machine. On a server you want the same three things: the toolchains, a built vendor/spinel/bin/spin, and cargo build --release.

What the CLI needs, on your own machine

melee runs where you write the app, not on the server, and works in any directory: the standard library travels inside the binary and is unpacked into ~/.melee/stdlib/<id> the first time it is needed. Install it from a checkout with mise run install (cargo install --path supervisor/melee-cli --root ~/.local, so it lands in ~/.local/bin); melee --version names the three things that have to agree — the CLI, the standard library it carries and the Spinel commit it is pinned to.

melee dev and melee test need Ruby 4.0 and the sqlite3 gem: they run the app under CRuby and never invoke the compiler. melee check (and melee test --spinel) compile the app locally, so the first one builds the pinned Spinel into ~/.melee/spinel/<pin> — about half a minute on a laptop — which needs git, make, a C compiler and curl, plus OpenSSL’s headers (brew install openssl@3 on macOS). melee toolchain shows where each of these is coming from and whether it matches the pin; melee toolchain install builds the compiler ahead of time. MELEE_CLI_HOME moves ~/.melee.

melee push, melee logs, melee env and the rest only need the binary and network access to the control API.

What is missing, specifically

These are P-03 and P-06 in the project’s own TASKS.md — packaging, and a deployment recipe. Until they exist:

• there are no prebuilt melee binaries or packages to download: installing it means a Rust toolchain and a checkout of the repository;
• the server is not self-contained the way the CLI is: it still needs a checkout for the standard library and the build script;
• there is no service unit, so keeping the server running across reboots is yours to arrange;
• there is no TLS anywhere, so the control API’s token and every melee env value cross the network in the clear unless you put something in front.

Next

Running melee-server — the flags and what they mean.