Moving to Gitea.

README.md

@@ -190,38 +190,61 @@ everyone out. Fine for now with a small, trusted set of tailnet users.
 
 ---
 
-## Running on ZimaOS Without Building Locally
+## Running on the Server
 
-The repo publishes a built image to GitHub Container Registry via
-`.github/workflows/docker-publish.yml`, so ZimaOS (or any other machine)
-can just pull and run it instead of building from source every time.
+SaraView runs on SpineS as a **Portainer stack built straight from this
+repo**. Portainer clones the repo, builds the image from the `Dockerfile`
+and starts it, using `docker-compose.server.yml`. There's no image registry
+and no CI: pushing a commit is all a release takes.
 
-**One-time setup after this workflow first runs:** GHCR packages built by a
-workflow's built-in token default to **private**, even on a public repo.
-Go to your GitHub profile → Packages → `saraview` → Package settings →
-Change visibility → Public. Until you do this, pulling the image from
-ZimaOS will fail with an authentication error.
+The stack keeps SaraView's config and data in a plain directory on the
+server (`/DATA/AppData/SaraView` by default), not in a Docker volume, so
+redeploying or removing the stack never touches it.
 
-Here's a step-by-step tutorial for installing on ZimaOS.
+### First-time setup
 
-1. Copy `docker-compose.ghcr.yml` and `SaraViewConf.toml` to the ZimaOS box
-   (or wherever you're running `docker compose` from for this).
-2. Edit the volume paths in `docker-compose.ghcr.yml` the same way you
-   would for local `docker-compose.yml`. Real paths on the left of each `:`.
-3. In ZimaOS's dashboard, use **Install a customized app** (its Docker
-   Compose import option) and point it at that compose file. Or just run
-   ```docker compose -f docker-compose.ghcr.yml up -d``` directly if you'd
-   rather do it from a terminal on the box.
+1. On the server, create the directory and put the config in it:
+   ```bash
+   mkdir -p /DATA/AppData/SaraView/Data
+   cp SaraViewConf.toml /DATA/AppData/SaraView/
+   ```
+   The config has to exist before the first deploy: Docker would otherwise
+   create a *directory* named `SaraViewConf.toml` in its place.
+2. In Portainer: **Stacks** → **Add stack** → **Repository**, on the
+   SpineS environment.
+   - Repository URL: this repo on Gitea. For a private repo, turn on
+     **Authentication** with your Gitea username and an access token.
+   - Repository reference: `refs/heads/main`
+   - Compose path: `docker-compose.server.yml`
+   - Environment variables: `NotesDir` and `SaraTagDir` (required), and
+     `SaraViewDir` if the data shouldn't live in `/DATA/AppData/SaraView`.
+   - **GitOps updates** on, with polling (e.g. every 5 minutes), so new
+     commits on `main` redeploy on their own.
+3. **Deploy the stack.** The first build takes a few minutes (it builds the
+   frontend and installs the backend).
 
-**Updating later:** push to `main` (or tag a release like `v1.1.0`) to
-build a fresh image, then on ZimaOS re-pull and recreate the container.
-Either through its UI's update/recreate action, or:
+### Moving over from the old ZimaOS app
+
+The old install (the ZimaOS "customized app" pulling from GHCR) kept its
+data in a Docker named volume. Copy it to the new directory once:
 
 ```bash
-docker compose -f docker-compose.ghcr.yml pull
-docker compose -f docker-compose.ghcr.yml up -d
+docker volume ls | grep -i saraview          # find the volume's name
+docker run --rm -v <volume name>:/From -v /DATA/AppData/SaraView/Data:/To \
+    alpine sh -c "cp -a /From/. /To/"
 ```
 
+Then stop the old app in ZimaOS and remove its container
+(`docker rm SaraView`; the volume stays) before deploying the stack, since
+both use the container name `SaraView` and port 8420. Once the new stack is
+confirmed working, the old app and its volume can be removed.
+
+### Updating
+
+Push to `main`. With GitOps updates on, Portainer notices the new commit
+and rebuilds and redeploys by itself. Otherwise, press **Pull and redeploy**
+on the stack.
+
 ---
 
 ## Groups and Access Control