---
title: Command line
description: Every sluurp command, what it is for, and the options used most.
section: Operations
order: 4
---

# Command line

<p class="lead">Everything Sluurp does is one binary, <code>sluurp</code>. <code>sluurp --help</code> lists the commands, and <code>sluurp &lt;command&gt; --help</code> every option of one. This page is the map.</p>

Every command takes `--dir <DIR>`, the folder that holds the data, one SQLite file per project. It is `sluurp_data` next to where you run it, unless you say otherwise.

## Serving

| Command | What it does |
|---|---|
| `serve` | Start the server: the API, the admin UI at `/_/`, and the app given to `--public` |
| `static` | Write the app out as plain files for a file host, islands still alive; `--base repo` for a site served from a folder ([Static sites](/docs/static-sites)) |
| `compile` | Build a single binary that serves one app, its files inside it |

`serve` options:

| Option | |
|---|---|
| `--public DIR` | The app at `/`: a folder, or a [repository's URL](/docs/getting-started). `NAME=DIR` serves another at `/NAME/`; give it more than once |
| `--addr HOST:PORT` | Where to listen; `127.0.0.1:8090` by default, this machine only |
| `--no-hot-reload` | Don't watch the files; for a server in production |
| `--attach NAME=FILE` | Use an existing SQLite database in place ([Existing SQLite databases](/docs/attach)) |
| `--events [ADDR]` | Take events over UDP from this machine ([Hooks and events](/docs/hooks-and-events)) |
| `--channel NAME`, `--apps` | Serve a published bundle, or every registered app by hostname, instead of a folder |

```sh title="Terminal"
sluurp serve --public ./app --public reports=./reports --addr 0.0.0.0:8090
```

## Data

| Command | What it does |
|---|---|
| `migrate APP` | Run an app's [migrations](/docs/migrations); `--plan` says what would run |
| `schema plan`, `schema apply` | Compare a `schema.json` with the database, or bring the database up to it |
| `import FILE` | Load collections and records from an import document |
| `superuser EMAIL PASSWORD` | Create an administrator, or reset one's password |
| `backup` | Copy every project to a dated snapshot folder |
| `migrations` | Show which of Sluurp's own internal migrations a project has had |
| `bench` | How fast collections are on this machine ([Why SQLite](/docs/why-sqlite)) |

## Packages

| Command | What it does |
|---|---|
| `add SPEC` | Vendor a package into an app: `add three`, `add npm:date-fns@4`, `add jsr:@std/path`, a CDN URL, or `font:inter:400,600` ([Packages](/docs/vendoring)) |
| `remove NAME` | Take a vendored package out again |
| `outdated`, `update` | Newer versions of what was added, and moving to them, as `pnpm` has them |
| `vendor` | List what an app vendors, `check` its files against their hashes, or `verify` them against where they came from |
| `cache` | Where Sluurp's package store and bundles are, and `clear` to empty them |

`add` and the others take `--app DIR`, the app to change: the current folder by default.

## Publishing

| Command | What it does |
|---|---|
| `push DIR` | Store an app build as a bundle; `--deploy CHANNEL` points a channel at it straight away |
| `bundles` | List the bundles, and what each channel serves |
| `deploy CHANNEL BUNDLE` | Point a channel at a bundle |
| `promote FROM TO` | Point one channel at whatever another serves: staging to production |
| `rollback CHANNEL` | Put a channel back on the version it served before |
| `app` | Connect a git repository, so its app is published from it on each push |

## Other

| Command | What it does |
|---|---|
| `emit NAME [JSON]` | Say an event to a server that listens for them |
| `i18n` | List the keys in an app's `i18n.json` that nothing uses |