Moving to Gitea.

.github/workflows/docker-publish.yml

@@ -1,52 +0,0 @@
-name: Build and publish Docker image
-
-on:
-  push:
-    branches: ["main"]
-    tags: ["v*.*.*"]
-  workflow_dispatch:
-
-permissions:
-  contents: read
-  packages: write
-
-jobs:
-  build-and-push:
-    runs-on: ubuntu-latest
-    steps:
-      - name: Check out repository
-        uses: actions/checkout@v4
-
-      - name: Compute lowercase image name
-        run: echo "IMAGE=ghcr.io/$(echo '${{ github.repository }}' | tr '[:upper:]' '[:lower:]')" >> "$GITHUB_ENV"
-
-      - name: Log in to GitHub Container Registry
-        uses: docker/login-action@v3
-        with:
-          registry: ghcr.io
-          username: ${{ github.actor }}
-          password: ${{ secrets.GITHUB_TOKEN }}
-
-      - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
-
-      - name: Compute tags
-        id: meta
-        uses: docker/metadata-action@v5
-        with:
-          images: ${{ env.IMAGE }}
-          tags: |
-            type=raw,value=latest,enable={{is_default_branch}}
-            type=semver,pattern={{version}}
-            type=sha,prefix=,format=short
-
-      - name: Build and push
-        uses: docker/build-push-action@v6
-        with:
-          context: .
-          file: ./Dockerfile
-          push: true
-          tags: ${{ steps.meta.outputs.tags }}
-          labels: ${{ steps.meta.outputs.labels }}
-          cache-from: type=gha
-          cache-to: type=gha,mode=max

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

docker-compose.ghcr.yml

@@ -1,15 +0,0 @@
-services:
-  saraview:
-    image: ghcr.io/srhtnin/saraview:latest
-    container_name: SaraView
-    ports:
-      - "8420:8420"
-    volumes:
-      - ./SaraViewConf.toml:/App/Backend/SaraViewConf.toml:ro
-      - saraview_data:/data/SaraViewData
-      - /path/to/your/notes:/data/notes:ro
-      - /path/to/SaraTag/.saratag:/data/SaraTag/.saratag:ro
-    restart: unless-stopped
-
-volumes:
-  saraview_data:

docker-compose.server.yml

@@ -0,0 +1,28 @@
+# The server deployment (SpineS), run as a Portainer stack straight from
+# this repo: Portainer clones it and builds the image from the Dockerfile on
+# every deploy, so there's no image registry involved. See README.md,
+# "Running on the Server".
+#
+# Paths are absolute host paths on the server: Portainer's copy of the repo
+# lives inside Portainer (on RibS), so "./something" wouldn't point at SpineS.
+# Set these as stack environment variables in Portainer:
+#   NotesDir      the notes directory to serve (required)
+#   SaraTagDir    SaraTag's .saratag directory (required)
+#   SaraViewDir   where SaraView's config and data live
+#                 (default /DATA/AppData/SaraView, the ZimaOS convention)
+services:
+  saraview:
+    build: .
+    image: saraview:server
+    # Always build from the checked-out commit instead of looking for a
+    # prebuilt image anywhere.
+    pull_policy: build
+    container_name: SaraView
+    ports:
+      - "8420:8420"
+    volumes:
+      - ${SaraViewDir:-/DATA/AppData/SaraView}/SaraViewConf.toml:/App/Backend/SaraViewConf.toml:ro
+      - ${SaraViewDir:-/DATA/AppData/SaraView}/Data:/data/SaraViewData
+      - ${NotesDir:?Set NotesDir to the notes directory on the server}:/data/notes:ro
+      - ${SaraTagDir:?Set SaraTagDir to the .saratag directory on the server}:/data/SaraTag/.saratag:ro
+    restart: unless-stopped