---
title: Deploying
description: Run Sluurp on a server, with HTTPS in front, backups and upgrades.
section: Operations
order: 1
---

# Deploying

<p class="lead">A Sluurp app in production is one binary, one app folder and one data folder on a machine you control. There is no database server to run beside it, and no build to ship.</p>

## On the server

Install the binary, put the app beside it, and make an administrator:

```sh title="Terminal"
curl -fsSL https://raw.githubusercontent.com/SluurpHQ/sluurp/master/install.sh | sh
sluurp --dir /srv/sluurp/data superuser you@example.com a-long-password
sluurp --dir /srv/sluurp/data serve --public /srv/sluurp/app --no-hot-reload
```

- `--dir` is where the data lives: one SQLite file per project. It is the only folder that must be kept.
- `--no-hot-reload` stops Sluurp watching the app's files, which a server doesn't need.
- `--public` can also be the app's [repository URL](/docs/getting-started): it is cloned on first start, and brought up to date on each restart.

Sluurp listens on `127.0.0.1:8090`, so it answers this machine only. Give it `--addr 0.0.0.0:8090` to take requests from outside, or better, put a proxy in front.

## HTTPS

Sluurp serves plain HTTP; a reverse proxy in front adds HTTPS. [Caddy](https://caddyserver.com) gets and renews the certificate by itself:

```text title="Caddyfile"
school.example.com {
  reverse_proxy 127.0.0.1:8090
}
```

Live updates, sync and cursors use WebSockets, which Caddy passes through as they are. Behind nginx, pass the `Upgrade` and `Connection` headers.

## Keeping it running

A service that starts Sluurp with the machine and restarts it if it stops, with systemd:

```ini title="/etc/systemd/system/sluurp.service"
[Unit]
Description=Sluurp
After=network.target

[Service]
ExecStart=/home/sluurp/.sluurp/bin/sluurp --dir /srv/sluurp/data serve --public /srv/sluurp/app --no-hot-reload
User=sluurp
Restart=always

[Install]
WantedBy=multi-user.target
```

```sh title="Terminal"
sudo systemctl enable --now sluurp
```

## Backups

`sluurp backup` copies every project to a dated snapshot in the data folder's `snapshots/`. In the admin UI, **Backups** schedules them and keeps as many as you say. Copy the snapshots off the machine too: a backup on the same disk doesn't survive that disk.

## Upgrades

Replace the binary and restart. Sluurp brings its own tables up to date when it starts, and runs the app's [migrations](/docs/migrations) that it hasn't run yet. Take a backup first; `sluurp migrate APP --plan` shows what will run.

## Or no server at all

A site that needs no API, sync or server functions, such as a landing page or docs, can be published as plain files with [`sluurp static`](/docs/static-sites), on GitHub Pages or any file host.