You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This repository will contain a Synology-optimized Docker setup for:
3
+
This project sets up a **self-hosted Bitcoin infrastructure** on a **Synology NAS** using Docker. It is tailored for power users who want to:
4
4
5
-
- Bitcoin Core
6
-
- Fulcrum
7
-
- ckpool-solo
8
-
- ckstats
9
-
- influxdb
10
-
- Mempool (Explorer)
5
+
- Run a **fully validating Bitcoin full node**
6
+
- Enable **solo mining** using their own ASIC hardware
7
+
- Analyze mining statistics and mempool data
8
+
- Operate with **full control**, **no third-party reliance**, and **local-first** architecture
11
9
12
-
Currently work-in-progress. Check back later for full setup instructions.
10
+
---
11
+
12
+
## ⚙️ What's Included?
13
+
14
+
This stack brings together multiple containers to deliver a comprehensive, modular Bitcoin infrastructure:
15
+
16
+
| Component | Description |
17
+
|----------------------|-------------|
18
+
|**Bitcoin Core**| The backbone: a full Bitcoin node that validates the entire blockchain and exposes RPC interfaces. |
19
+
|**Fulcrum**| High-performance Electrum server indexing the blockchain for wallet queries. |
20
+
|**CKPool (Solo)**| A modified solo mining pool implementation allowing ASIC miners to mine directly against your local node. |
21
+
|**CKStats**| Parses CKPool logs, stores mining events in PostgreSQL, and provides insights into hash rate, luck, and shares. |
22
+
|**Bitcoin Explorer**| Web-based block explorer using RPC access to your Bitcoin Core. |
23
+
|**Mempool**| Powerful mempool visualizer and blockchain explorer (requires InfluxDB + Grafana). |
24
+
|**InfluxDB**| Time-series database used by Mempool and CKStats to store block and mempool metrics. |
25
+
|**Grafana**| Dashboards for visualizing metrics from InfluxDB (e.g., hash rate, block times, mempool size). |
26
+
27
+
---
28
+
29
+
## 💡 Why This Project?
30
+
31
+
Running your own Bitcoin full node is the most secure and private way to use Bitcoin. By adding:
32
+
33
+
-**CKPool-solo**, you bypass centralized mining pools
34
+
-**Fulcrum**, you serve your own wallets like Electrum
35
+
-**Mempool + Explorer**, you get full insight into mempool congestion and fee estimation
36
+
-**Self-hosted stack on Synology**, you stay in full control of your data and operations
37
+
38
+
This project automates the setup of a resilient, modular, and observable Bitcoin stack using Docker — optimized for **Synology NAS environments** but portable to any Linux system.
39
+
40
+
---
41
+
42
+
## 🔐 Self-Custody, Full Control, Maximum Privacy
43
+
44
+
This stack is designed around **sovereignty**:
45
+
46
+
- No API keys
47
+
- No cloud services
48
+
- No third-party wallets
49
+
- No dependence on public electrum or explorer services
50
+
51
+
You validate everything. You own everything. You mine for yourself.
52
+
53
+
54
+
---
55
+
56
+
## 🛠️ Installation & Setup
57
+
58
+
To get started, you only need a Synology NAS with Docker support (or any Linux machine) and around **700 GB of free disk space**. Performance varies depending on storage type.
59
+
60
+
### 🧠 Storage Recommendations
61
+
62
+
For best results, especially during initial blockchain sync:
63
+
64
+
-**Optimal Setup:** Place the full blockchain and indexes on a **fast NVMe volume** (≈700 GB total).
65
+
-**Hybrid Setup (Recommended for Synology):**
66
+
-**Slow HDD** (e.g., `/volume1/data`) for blockchain data (`blocks` and `chainstate`)
Watch for `"initialblockdownload": false` which means that the blockchain has fully synced and is ready. This means your node is fully synced and ready to serve RPC requests.
144
+
145
+
> ⚠️ **Important:** Do not start `cksolo` (the mining pool) or your miner before this status is reached. Mining during the initial download phase will lead to rejected shares and wasted energy.
146
+
147
+
## CKSolo - Solo Mining Pool
148
+
149
+
[CKSolo](https://bitbucket.org/ckolivas/ckpool-solo/src/solobtc/) is a lightweight, minimalist solo mining pool originally developed by Con Kolivas. It is ideal for miners who want to mine solo, directly submitting shares to their own Bitcoin Core node without relying on a third-party pool.
150
+
151
+
In this setup, **CKSolo** connects to your `bitcoind` node and handles incoming mining work submissions via the Stratum protocol. If your miner finds a valid block, it is directly submitted and credited to your Bitcoin address.
152
+
153
+
> 🛠 CKSolo logs all activity into `/volume2/docker/appdata/cksolo/logs/ckpool.log`, which is read by CKStats for statistics.
154
+
155
+
### ⛏ Start CKSolo
156
+
157
+
Once `bitcoind` is fully synced, start CKSolo using:
**CKStats** is a companion service for CKSolo. It continuously parses the CKSolo `ckpool.log` file and stores relevant mining metrics in an embedded PostgreSQL database. This enables historical tracking of:
171
+
172
+
- Accepted and rejected shares
173
+
- Miner activity and status
174
+
- Found blocks (if you're lucky)
175
+
- Hashrate trends
176
+
177
+
CKStats is designed to be lightweight and runs alongside the solo pool to provide insights without adding unnecessary load or complexity.
178
+
179
+
### 📊 Start CKStats
180
+
181
+
Once `ckpool` is running, start CKStats using:
182
+
183
+
```bash
184
+
docker compose --profile bitcoin up -d ckstats
185
+
```
186
+
187
+
This will spin up the `ckstats` service, connect it to the CKSolo-log file, and initialize the database under under `./ckstats/pgdata`
188
+
189
+
> ℹ️ The `pgdata` directory is owned by user `100` and group `103` to match PostgreSQL's internal user. Do not change these permissions.
190
+
191
+
### ⚙️ Rebuilding or Reinitializing the Database
192
+
193
+
CKStats supports two environment variables for maintenance and development purposes, which are set in the `docker-compose.yml`:
194
+
```yaml
195
+
REBUILD_APP: "0"# Set to "1" to rebuild the app and run the migration
196
+
DB_REINITIALISE: "0"# Set to "1" to delete the entire database and wipe /ckstats/pgdata/*
197
+
```
198
+
199
+
Setting `REBUILD_APP=1` will trigger a fresh rebuild of the application and rerun any required database migrations during container startup.
200
+
This is useful if you made changes to the CKStats codebase or updated dependencies and want to apply schema changes.
201
+
202
+
Setting `DB_REINITIALISE=1` will **wipe all data** by deleting the entire PostgreSQL data directory (`/ckstats/pgdata/`) and initialize it from scratch.
203
+
Use this **with caution**, as all previously logged stats will be lost.
204
+
205
+
🛑 **Important:**
206
+
These flags only take effect during container startup. After a successful rebuild or reset, **you must set both values back to `0`** in your `docker-compose.yml` file to prevent unintended data loss on future restarts.
207
+
208
+
CKStats automatically handles:
209
+
- Full application rebuild (if requested)
210
+
- Database schema migrations
211
+
- Fresh initialization (if reset)
212
+
213
+
Once the CKStats container is running, you can access the stats dashboard via `http://<your-server-ip>:4000`
0 commit comments