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.

Thanks @zichichi , not sure why my previous update didn't get pushed. I've updated the template and readme to reflect the latest required image again just now. The Pi project timeline is here for reference --> https://docs.google.com/document/d/1iqI7MZCfLqiZMYdGlXSQXpS1qK2q74nVK0jBER-S-mM/edit?tab=t.0

You get rewards - or at least a multiplier of your existing daily rewards, if you generate a NODE_PRIVATE_KEY elsewhere first and you add that in the docker template. You'll find that option to add it in the 'Show more settings...' section of my template. It's a bit convoluted right now to generate the key and pair with your Pi app on mobile but it can certainly be done. In summary, you need to go through the initial steps of installing a node on Windows or Mac. You don't need to let it run and download the whole chain history etc - you just need to initialise and pair with your app. Then extract the private key from that node, shut it down - then paste that key into your Unraid hosted docker node. If you start a linux/docker node with that NODE_PRIVATE_KEY field empty, then a key will be generated for you. Hopefully there will be an alternate method of pairing directly with that key sometime and the whole Windows/Mac thing can be avoided. FYI - my current 'to-do' list includes adding a web interface for this Unraid template, to surface some of the node stats/status and include the option to see/copy the private key for safe keeping.

[Support] NanoClaw — Lightweight Secure AI Agent for UnraidNanoClaw is a lightweight, open-source personal AI agent that runs securely on your own server. It connects to Matrix and Telegram (via skill) and runs every agent session inside its own isolated Docker container — so the AI only sees what you explicitly give it access to. Built as a minimal alternative to OpenClaw/Clawdbot, NanoClaw has ~15 source files you can actually read and understand. No complex config files — customise by telling Claude Code what you want changed. Features Matrix (E2EE) channel support — Telegram available via skill install; WhatsApp, Slack, Discord in development Per-conversation isolated Docker containers — true OS-level sandbox, not application-level permissions Scheduled tasks — morning briefings, weekly reviews, automated reports Web search and fetch built in Agent Swarms — spin up teams of specialised agents that collaborate Per-group memory via CLAUDE.md files Anthropic API key authentication (console.anthropic.com) Requirements Anthropic API key from console.anthropic.com — or a local model via per-group provider override (NANOCLAW_PROVIDER_BASE_URL + NANOCLAW_PROVIDER_API_KEY + NANOCLAW_PROVIDER_MODEL). Note: Claude Code OAuth tokens are no longer supported for automated/non-interactive use — CLAUDE_CODE_OAUTH_TOKEN will not produce a working agent. Matrix: Homeserver URL, bot user ID, and access token for a dedicated bot account Telegram: Bot token from @BotFather (optional — requires skill install, see NanoClaw changelog) At least one channel (Matrix or Telegram) must be configured Docker socket access (required — NanoClaw spawns isolated agent containers for each conversation) Installation Install via Community Applications and search for NanoClaw, or drop the template XML directly into /boot/config/plugins/dockerMan/templates-user/ on your Unraid server. Required fields: HOST_PROJECT_ROOT — must match the host path of your AppData volume. The template defaults to /mnt/cache/appdata/nanoclaw but this must reflect where Unraid has actually placed the appdata on your system. If your cache pool or appdata share is configured differently, it may be /mnt/user/appdata/nanoclaw or another path. Verify with ls /mnt/cache/appdata/nanoclaw — if that returns nothing, adjust accordingly. A path mismatch here will cause agent containers to silently fail to spawn. ANTHROPIC_API_KEY — required, from console.anthropic.com Telegram (optional, via skill): TELEGRAM_BOT_TOKEN from @BotFather Matrix (optional): MATRIX_HOMESERVER_URL, MATRIX_BOT_USER_ID, MATRIX_ACCESS_TOKEN MATRIX_BOT_PASSWORD — k2's Matrix account password, used once on first startup to bootstrap cross-signing keys (eliminates the "unverified device" warning in Element X). After the first successful start, the bootstrap is skipped automatically — safe to leave set or remove. Recommended: NANOCLAW_DOCKER_NETWORK — set to your Docker network name (e.g. ai-local) if you run Ollama, LiteLLM, or Paperclip on the same server. Without this, agent containers use the default bridge network and cannot reach those services by hostname. At least one channel (Matrix or Telegram) must be configured. After starting the container: Matrix: Invite your bot account to a room The room auto-registers on first message Send @Andy hello — Andy will respond Telegram (after skill install): Send /chatid to your bot The bot will reply with your chat ID and automatically register Send @Andy hello — Andy will respond The trigger word is @Andy by default (configurable via NANOCLAW_TRIGGER). To customise NanoClaw (change trigger word, add scheduled tasks, connect integrations), clone the repo and run claude in the project directory — Claude Code handles all configuration changes conversationally. Links Template repository: https://github.com/bitcryptic-gw/unraid-nanoclaw Add to CA directly: https://raw.githubusercontent.com/bitcryptic-gw/unraid-nanoclaw/main/NanoClaw.xml NanoClaw project: https://github.com/qwibitai/nanoclaw Docker Hub image: https://hub.docker.com/r/bitcryptic/nanoclaw Notes The Docker socket mount (/var/run/docker.sock) is required — NanoClaw uses it to spawn isolated agent containers for each conversation. This is the same pattern used by Portainer, Watchtower, and similar tools. Port 3001 is the internal credential proxy used by agent containers. It only needs to be accessible on the local Docker bridge network — you do not need to expose it externally. NanoClaw stores its data in four directories under AppData: data/, store/, groups/, and logs/. Post any issues or questions here and I'll do my best to help. Changelogv1.3.0 (2026-04-20) OneCLI credential support — NanoClaw now supports OneCLI as the core credential gateway for agent containers, aligned with upstream's architecture. Two new optional template variables: ONECLI_URL and ONECLI_API_KEY. Leave blank if you prefer the self-hosted native credential proxy (install the use-native-credential-proxy skill instead) Telegram removed from core — Telegram channel code has moved to the upstream qwibitai/nanoclaw-telegram skill repo, consistent with upstream's channel extraction architecture. Telegram remains fully functional via skill install; the bot token variable is retained in the template for compatibility New MCP skills — Vikunja task management skill added (VIKUNJA_URL, VIKUNJA_TOKEN). UnraidClaw, Tailscale, and Home Assistant skills stabilised and skill-files-only (env forwarding via template variables) Trigger matching tightened — trigger word must now appear at the start of a message (^@trigger) rather than anywhere in the message body Writable global memory mount — main agent now has write access to /workspace/global, fixing silent failures when Andy attempts to write global memory notes v1.2.55 (2026-04-10) Telegram is now optional — Matrix-only setups no longer require a Telegram bot token Fixed MCP skill credentials (Ollama, Home Assistant, Tailscale, UnraidClaw) not reaching agent containers — all integrations now work correctly out of the box New variable: NANOCLAW_DOCKER_NETWORK — set to your Docker network name (e.g. ai-local) to allow agent containers to reach Ollama, LiteLLM, and Paperclip by hostname. Defaults to ai-local in the template New variable: MATRIX_BOT_PASSWORD — used once at startup to bootstrap Matrix cross-signing keys, eliminating the "unverified device" warning in Element/Element X. Safe to leave set; bootstrap is skipped automatically after the first run Matrix room cleanup: NanoClaw no longer auto-joins unregistered rooms on startup v1.2.49 (2026-04-08) Matrix channel support with full E2EE (Rust crypto store, SQLite persistence across restarts) Telegram channel restored and stabilised ANTHROPIC_API_KEY now automatically injected into new group sessions — fresh installs no longer require manual file editing Matrix channel vars added to Unraid CA template v1.2.25 (2026-03-16) /chatid command now auto-registers the chat — no manual SQLite setup required Fresh installs work out of the box — no need to copy .claude.json from another machine Stale sessions cleared automatically on container restart/update Fixed agent container file ownership issues that caused silent failures Docker socket mount corrected from Device to Path type (fixes Unraid compatibility) Multi-arch image (amd64 + arm64) on Docker Hub

A Pi Network Node for inclusion...hope I've landed at the right place for this to be considered. https://raw.githubusercontent.com/bitcryptic-gw/unraid-pi-network-node/main/PiNetworkNode.xml

Template has been updated to latest docker image, includes required version increase as of 1st March 2026 for Pi Network nodes.

Please consider including this in Unraid' CA

I'm maintaining an Unraid Community Applications (CA) template for running the Pi Network Node on Unraid (mainnet), via the BitCryptic wrapper image with performance tuning baked in. Repo (template + docs): https://github.com/bitcryptic-gw/unraid-pi-network-node Docker Hub: https://hub.docker.com/r/bitcryptic/pi-network-node Install via Community Applications — search for "Pi Network Node", or add this repository manually in CA settings: https://raw.githubusercontent.com/bitcryptic-gw/unraid-pi-network-node/main/PiNetworkNode.xml What the BitCryptic wrapper adds The template uses bitcryptic/pi-network-node rather than the upstream image directly. This bakes in three performance tuning env vars that significantly reduce CPU load on the host: - INGEST_DISABLE_STATE_VERIFICATION=true — disables periodic full ledger state scans (main CPU reduction) - PARALLEL_JOB_SIZE=1 — reduces horizon ingestion worker parallelism - HISTORY_RETENTION_COUNT=1000000 — retains ~8 weeks of ledger history instead of full history since genesis The latest tag always tracks the current Pi node release. Versioned tags (e.g. v22.1) are also available for pinning. Template notes - Persistent data: required mapping to /opt/stellar (Unraid appdata recommended) - Ports mapped (standard): 31401 (Horizon HTTP), 31402 (stellar-core peer), 31403 (local history / webfsd) - Required env var: POSTGRES_PASSWORD - Optional env var: NODE_PRIVATE_KEY (migration only — do not run two nodes with the same key) - Mainnet flags passed as Post Arguments: --mainnet --enable-auto-migrations If you need help, please include: - Unraid version - Container startup log (first ~200 lines after start) - docker ps --format '{{.Names}}\t{{.Ports}}' - Your /opt/stellar host path mapping Disclaimer: Community-maintained template; not affiliated with or endorsed by Pi Core Team.