CLI

The akurai binary is the whole toolchain. It has no subdependencies and runs anywhere a Linux binary runs.

akurai new <path>

Scaffold a new project from embedded templates. Creates frontend/, backend/, and data/, plus akurai.toml. Fails if the target exists and is non-empty.

akurai new myapp

akurai serve

Serve the current project. Registers every frontend/*.html as a template, renders pages against backend/page.json, routes through backend/routes.json (see Routing), and persists data to data/store.db (see Storage).

akurai serve --dir frontend --host 127.0.0.1 --port 8090

akurai dev

The same as serve, plus live reload. The dev server watches frontend/, content/, and backend/ and, on any change, pushes a reload to connected browsers over Server-Sent Events (a tiny EventSource script is injected into dev pages). Edit a template or stylesheet and the page refreshes itself — no plugin, no build step.

akurai dev --dir frontend --port 8090

Live reload is strictly a dev feature: akurai serve starts no watcher, injects nothing, and reserves the internal /_dev/* namespace as 404.

akurai version

Print the version.

akurai update

Self-update the CLI to the latest release (aliases: upgrade, self-update).

akurai update --check    # report whether a newer release exists; install nothing
akurai update            # download the latest release and replace this binary

It resolves the right binary for your platform from the project's GitHub releases, downloads it (via the system curl), and atomically replaces the running executable. See Updating for the full details and caveats.

Deploying

The binary is self-contained, so deployment is "copy the file and run it." Build a static binary for portability:

cargo build --release --target x86_64-unknown-linux-musl

Put it behind nginx for TLS and run it under systemd. That is exactly how akurai-framework.olibuijr.com — the site you are reading — is deployed.