MetaCore 1.1.0: Redis replaced by embedded SQLite

Apps/MetaCore/docker-compose.yml

@@ -5,7 +5,7 @@ services:
   # Public ingress goes through the `metacore` hash-lock proxy below — this
   # service has no public Caddy labels and no exposed host ports.
   metacore-app:
-    image: ipcr-watch.nsl.sh/ipns/metadec.eth/metadec.eth/meta-core:1.0.24
+    image: ipcr-watch.nsl.sh/ipns/metadec.eth/metadec.eth/meta-core:1.1.0
     container_name: metacore-app
     # Hard RAM cap, swap disabled (memswap_limit == mem_limit) → OOM
     # instead of swap. Both values must move together or swap comes back.
@@ -31,7 +31,8 @@ services:
       - 80
 
     volumes:
-      # Shared infrastructure state (leader election, Redis dump, service discovery).
+      # Shared infrastructure state: the metadata store (db/meta-core.db, SQLite),
+      # the leader lock, identity and mounts.
       # Lives inside /DATA/AppData/metacore/ so CasaOS archives it on uninstall.
       - ${DATA_ROOT:-/DATA}/AppData/metacore/meta-core:/meta-core:rw
 
@@ -48,7 +49,7 @@ services:
       # `filePath` points into it. This MUST be a bind mount: without it the
       # directory is the container's writable layer, so any `docker compose
       # up -d` that recreates metacore-app silently deletes every poster while
-      # Redis keeps pointing at them. That is exactly what happened on
+      # the records keep pointing at them. That is exactly what happened on
       # watch.nsl.sh on 2026-08-03 (270 files → 0), and it is the reason a
       # fraction of poster CIDs 404 with a healthy-looking record behind them.
       # metacore-app is the only service that mounts /files; the gateway and
@@ -65,7 +66,7 @@ services:
       - BASE_URL=https://metacore-$APP_DOMAIN
       - TZ=$TZ
 
-    # Runs as root for nginx, Redis, rclone mounts
+    # Runs as root for nginx and rclone mounts
     user: 0:0
 
     healthcheck: