BitCryptic

Template updated — v25.2.2 (image change) The template has been updated to protocol v25.2.2, following the Pi Core Team's latest release. What's changed: Image updated to: bitcryptic/pi-network-node:latest Wraps the official Pi Network image (pinetwork/pi-node-docker:organization-mainnet-v1.0-p25.2.2) with the same performance optimisations as previous versions. Upgrade notes for this version: Binary bump — stellar-core updated to v25.2.2, horizon to v25.1.0 No data migrations on first boot — straight binary swap, no pg_upgrade, no reingestion Ubuntu base and PostgreSQL 16 unchanged Existing users: Unraid's "Check for Updates" will detect the new tag automatically — just hit Apply Update Verify sync after restart: docker exec PiNetworkNode node-status (or curl http://localhost:31401 | python3 -m json.tool | grep ingest_latest_ledger and compare against https://api.mainnet.minepi.com)

Update — 2026-05-31 The image has been updated to track upstream v2026.529.0 (released 2026-05-29). If you're running the CA template, it already uses :latest so just stop the container, remove the image, and recreate — it will pull the updated image automatically. Notable upstream changes since the original post: - v2026.517.0 — Grok Build is now a first-class local runtime (adapter registry, UI, CLI, session handling) - v2026.529.0 — Inline document annotations and comments on issues, with revision-aware anchor snapshots No template changes required. Post any issues here and I'll do my best to help.

Template updated — v24.1.0 (image change) The template has been updated to protocol v24.1.0, in line with the Pi Core Team's upgrade schedule (deadline: June 2, 2026). What's changed: Image updated to: bitcryptic/pi-network-node:latest Wraps the official Pi Network image ( pinetwork/pi-node-docker:organization-mainnet-v1.0-p24.1.0 ) with the same performance optimisations as previous versions. Upgrade notes for this version: Routine binary bump — stellar-core updated to v24.1.0, horizon to v24.0.0 No data migrations on first boot for existing users already on v23.x Ubuntu base (24.04) and PostgreSQL 16 unchanged Existing users: Unraid's "Check for Updates" will detect the new tag automatically — just hit Apply Update Verify sync after restart: curl http://localhost:31401 | python3 -m json.tool | grep ingest_latest_ledger and compare against https://api.mainnet.minepi.com

please move to docker container area

Paperclip is an open-source AI coding agent platform that lets you run Claude-powered coding agents on your own server. This image is maintained by BitCryptic and built from the official Paperclip source with Unraid compatibility in mind. Features Claude-powered coding agents via Anthropic API Web UI served from the same container Authenticated or public deployment modes Tailscale support for private access Requirements PostgreSQL database — a separate Postgres container (e.g. postgres:16) on the same Docker network Anthropic API key from console.anthropic.com (required for Claude-based agents) A securely generated BETTER_AUTH_SECRET (openssl rand -base64 32) Installation Install via Community Applications and search for Paperclip, or drop the template XML directly into /boot/config/plugins/dockerMan/templates-user/ on your Unraid server. You'll need a PostgreSQL container running before starting Paperclip. The default DATABASE_URL assumes a container named postgres-paperclip on the same Docker network — adjust to match your setup. Required fields: DATABASE_URL — PostgreSQL connection string (default: postgres://paperclip:password@postgres-paperclip:5432/paperclip) BETTER_AUTH_SECRET — random secret for session signing, generate with openssl rand -base64 32 PAPERCLIP_PUBLIC_URL — the URL users will access Paperclip from (e.g. http://your-server-ip:3100 or your Tailscale hostname) PAPERCLIP_DEPLOYMENT_MODE — authenticated for private use, public for open access (default: authenticated) ANTHROPIC_API_KEY — required for Claude-based agents After starting the container, access the web UI at http://your-server-ip:3100. Notes Paperclip requires a PostgreSQL database — it will not start without a valid DATABASE_URL. If you don't already have a Postgres container, add one first and put both on the same Docker network. PAPERCLIP_PUBLIC_URL must match the URL you actually use to access Paperclip — if this is wrong, auth callbacks will fail. If accessing from multiple URLs (e.g. local IP and Tailscale hostname), set BETTER_AUTH_TRUSTED_ORIGINS to a comma-separated list of all valid origins. For private access, Tailscale is supported — enable it in the template and set PAPERCLIP_PUBLIC_URL to your Tailscale hostname. Links Template repository: https://github.com/bitcryptic-gw/unraid-templates Paperclip project: https://github.com/paperclipai/paperclip Docker Hub image: https://hub.docker.com/r/bitcryptic/paperclip Post any issues or questions here and I'll do my best to help.

Great diagnostics — you've basically pinpointed it. The most likely culprit is a path mismatch in HOST_PROJECT_ROOT. This variable tells NanoClaw where its appdata lives on the host (not inside the container), because it needs to pass correct volume mount paths when spawning agent containers via the Docker socket. Without it resolving correctly, the path from "event decrypted" → "register group + persist message + spawn agent" fails silently at the point it tries to construct the container args — which matches exactly what you're seeing. Check what you have set for HOST_PROJECT_ROOT and verify it matches where Unraid has actually placed the appdata. The template defaults to /mnt/cache/appdata/nanoclaw but depending on your cache pool name or appdata share configuration it could be something different on your system — /mnt/user/appdata/nanoclaw is a common variation. You can confirm the real path with: bash ls /mnt/cache/appdata/nanoclawIf that returns nothing, try /mnt/user/appdata/nanoclaw and update the template variable to match. One other thing worth flagging while you're in the template — Anthropic has deprecated OAuth token auth for Claude Code in automated/non-interactive contexts. Even once agent containers are spawning correctly, CLAUDE_CODE_OAUTH_TOKEN won't get you a working agent. You'll need either an ANTHROPIC_API_KEY from console.anthropic.com, or if you're running Ollama or LiteLLM locally, you can use a per-group provider override (NANOCLAW_PROVIDER_BASE_URL + NANOCLAW_PROVIDER_API_KEY + NANOCLAW_PROVIDER_MODEL) to route agent sessions to a local model instead. Everything else you've described looks healthy — decryption is clean, the network exists, the Docker socket is mounted, and agent images are present. The OAuth situation aside, the HOST_PROJECT_ROOT path mismatch should be the only structural issue. Your post has also prompted us to update our template docs to make both of these requirements clearer — appreciate the thorough writeup, it's exactly the kind of feedback that helps. Give it a restart with both fixes applied and let me know what you see. If agent spawning still doesn't fire, grab the full docker logs output from a fresh message send and I'll dig further.

Hey nathan9214, glad you got it working! Telegram is still in there and should work — it's just not my primary channel so it hasn't had as much real-world testing in this build. Matrix is the native channel in the bitcryptic/nanoclaw template and tends to be the more repeatable path if you're open to it. That said, if Telegram is your preference, stick with it. The tweaking you did to get it running is likely the right approach for now. We're planning to re-align with upstream once their v1→v2 migration stabilises — that work is actively in progress over at qwibitai/nanoclaw — so the Telegram experience should improve as things settle. What did you end up having to tweak? Would be useful to know so I can document it properly for others.

Template updated — v23.0.1 (image change) The template has been updated to protocol v23.0.1, in line with the Pi Core Team's upgrade schedule (deadline: May 15, 2026). What's changed: Image updated to: bitcryptic/pi-network-node:latest Wraps the official Pi Network image ( pinetwork/pi-node-docker:organization-mainnet-v1.0-p23.0.1 ) with the same performance optimisations as previous versions. Upgrade notes for this version: - This is a heavier upgrade than previous versions — expect longer startup time than usual - Includes an in-place PostgreSQL upgrade (v12 → v16) and data migrations on first boot - Do not interrupt the container while it is starting — allow it to complete fully - Back up your /opt/stellar volume before upgrading if you haven't already - Existing users: Unraid's "Check for Updates" will detect the new tag automatically — just hit Apply Update - Verify sync after restart: curl http://localhost:31401 | python3 -m json.tool | grep ingest_latest_ledger and compare against https://api.mainnet.minepi.com

I've been running a self-hosted Bitcoin solo mining setup on Unraid using ckpool, and I've put together a Community Applications template to make it easier for others to do the same. ckpool-solo runs ckpool in BTCSOLO mode (-B flag), built from the official source by Con Kolivas (the same developer behind cgminer). It acts as a stratum server that bridges your ASIC miners to your local Bitcoin Core node. Every share your hardware submits is checked against your own node — no pool, no third party, 100% of any block reward to your own address. --- Requirements - A fully synced Bitcoin Core node with RPC enabled (running on Unraid or LAN-accessible) - At least one ASIC or miner that supports stratum (Bitmain, Braiins OS, etc.) - A Bitcoin address for block rewards --- Installation Add the template repository directly to Community Applications: https://raw.githubusercontent.com/bitcryptic-gw/unraid-ckpool-solo/main/CkpoolSolo.xml Or copy the XML to /boot/config/plugins/dockerMan/templates-user/ on your Unraid server. --- Setup 1. Create your AppData directory: /mnt/cache/appdata/ckpool-solo/ 2. Copy config/ckpool.conf.example from the GitHub repo and edit with your RPC credentials and Bitcoin address 3. Set up rpcauth in bitcoin.conf (use the official rpcauth.py script from the Bitcoin Core repo) 4. Start the container — stratum will be available on port 3333 5. Point your miners at stratum+tcp://[unraid-ip]:3333, username = your Bitcoin address, password = anything --- Notes - Uses the -k flag to clear stale PIDs on startup (prevents issues after unclean shutdowns) - Exclude from Appdata Backup to prevent SIGTERM restarts mid-backup - Running on fixedips Docker network with a static IP — adjust the template to match your network setup if needed - Tested with two Bitmain S9s running Braiins OS + Stratum V2 --- Realistic expectations Solo mining is a lottery. The odds of finding a block with consumer hardware are low — this is for homelab hobbyists who want full sovereignty over their mining setup. I run it powered by excess solar via a TP-Link Kasa smart plug, so the marginal cost is near zero. --- Links - GitHub (template + Dockerfile): https://github.com/bitcryptic-gw/unraid-ckpool-solo - Docker Hub: https://hub.docker.com/r/bitcryptic/ckpool-solo - ckpool upstream: https://bitbucket.org/ckolivas/ckpool-solo Happy to answer questions or take feedback on the template.

Template has been updated to use 'latest' tag instead of the specific versions, to make for smoother and easier updates.

Template updated — v22.1 (image change) The template has been updated to protocol v22.1, in line with the Pi Core Team's upgrade schedule (deadline: April 27, 2026). What's changed: Image updated to: bitcryptic/pi-network-node:v22.1 Wraps the official Pi Network image (pinetwork/pi-node-docker:organization-mainnet-v1.0-p22.1) with the same performance optimisations as previous versions. Upgrade notes for this version: Quick upgrade, under 5 minutes expected downtime No heavy data migration Existing users: Unraid's "Check for Updates" will detect the new tag automatically — just hit Apply Update Verify sync after restart: curl http://localhost:31401 | python3 -m json.tool | grep ingest_latest_ledger and compare against https://api.mainnet.minepi.com

I would imagine the bonus earn rate would be tied to running on mainnet, though I'm not sure.

Template updated — v21.2 (image change) The template has been updated to protocol v21.2, in line with the Pi Core Team's upgrade schedule (deadline: April 6, 2026). What's changed: The template now points to a BitCryptic-maintained wrapper image rather than the upstream image directly: bitcryptic/pi-network-node:v21.2 This image is built from the official Pi Network image (pinetwork/pi-node-docker:organization-mainnet-v1.0-p21.2) with three performance optimisations baked in that significantly reduce host CPU load: INGEST_DISABLE_STATE_VERIFICATION=true — disables periodic full ledger state scans (the main CPU reduction) PARALLEL_JOB_SIZE=1 — reduces horizon ingestion worker parallelism HISTORY_RETENTION_COUNT=1000000 — retains ~8 weeks of ledger history rather than all history since genesis On our test node this dropped host load average from ~4 to under 1, and horizon CPU from ~57% to under 3%. The Dockerfile and GitHub Actions build pipeline are open source at https://github.com/bitcryptic-gw/unraid-pi-network-node if you want to inspect what's in the image. Upgrade notes for this version: Quick upgrade, under 5 minutes expected downtime No heavy data migration (unlike the 19.x upgrades) Verify sync after restart: curl http://localhost:31401 | python3 -m json.tool | grep ingest_latest_ledger and compare against https://api.mainnet.minepi.com

I don't follow your questions, sorry. Do you mean that I have the template pointed at my repo? I monitor the upstream and do periodic sync's to the latest stable builds. You can always switch the repo and point to the upstream directly or another if you wish. I'm not sure what you mean by 'run once and forget' ? NanoClaw is an open source project, anyone can contribute fixes or features (skills). I have a few that I've submitted.

My active container is using around 2.5GB. It may use more while doing the initial download as the database does a lot of inserts etc. No ETA on the UI, I plan to spend some time on that in the next couple of days. I'll come back to you with some examples of CLI status checks you can do.