# Hosting dasl.ing on supramundane

This directory is an `sm` service that hosts
https://dasl.ing/ behind the supramundane front proxy. Unlike a stock `sm`
static service, the content is **not** baked into the image: the container is
just a Caddy `file_server` rooted at `/data`, which is the service's directory
in the shared data root (`/srv/supramundane/data/dasl-ing` on the host). New
content lands there over SSH and is live immediately — no rebuild, no restart.

## One-time setup

1. Stand the service up (builds the container, mounts the data dir, wires
   `dasl.ing` into the front proxy):

   ```sh
   cd sm && sm deploy
   ```

2. Create a dedicated deploy key and authorize it on the server, for the same
   user `sm` deploys as (so it can write to the data dir):

   ```sh
   ssh-keygen -t ed25519 -f dasl-ing-deploy -N "" -C dasl-ing-deploy
   ssh $SUPRAMUNDANE 'cat >> ~/.ssh/authorized_keys' < dasl-ing-deploy.pub
   ```

   Then restrict the key so it can only ever rsync into the data directory,
   by prefixing its `authorized_keys` line with:

   ```
   command="rrsync -wo /srv/supramundane/data/dasl-ing",restrict 
   ```

   (`rrsync` ships with rsync.) The workflow relies on this restriction:
   rrsync anchors transfers inside that directory, which is why
   `DEPLOY_PATH` in the workflow is `"."`. If you ever use an unrestricted
   key instead, set `DEPLOY_PATH` to the absolute data dir path.

3. On Tangled (repo → **Settings → Pipelines**), pick a spindle for the repo
   and add three secrets:

   | Secret | Value |
   | --- | --- |
   | `DEPLOY_TARGET` | `<user>@<server>`, e.g. `robin@$SUPRAMUNDANE` |
   | `DEPLOY_SSH_KEY` | contents of `dasl-ing-deploy` (the private key, pasted whole) |
   | `DEPLOY_KNOWN_HOSTS` | output of `ssh-keyscan -t ed25519 <server>` |

   Then delete the local copy of `dasl-ing-deploy`.

## Continuous deploys

`.tangled/workflows/deploy.yml` runs `npm run build` and rsyncs the generated
`build/` directory — and only that — into the service's data directory on every
push to `main`. It can also be triggered manually from the repo's pipelines page.
The site is built in CI, so there is nothing to regenerate before pushing.

Redeploy this directory (`sm deploy`) only when the container itself changes
(Caddyfile, Dockerfile, compose, domains in service.json).