Install CKPool Solo Mining Server: Complete Stratum Setup Guide

I spent two months testing different solo mining server software before settling on CKPool for my home setup. Here’s what I learned: running your own stratum server isn’t just about control — it’s about understanding exactly how your mining operation communicates with the blockchain.

Most solo miners rely on public pool infrastructure like solo.ckpool.org or 2Miners SOLO. That works fine, honestly. But when you install your own CKPool solo mining server, something changes. You’re not trusting someone else’s node. You’re not sharing infrastructure with hundreds of other miners. You control every aspect of the mining process.

The data shows: having your own server eliminates network latency to third-party pools, gives you complete block template control, and removes any dependency on external infrastructure. When you find a block, you know exactly what happened — no mystery, no wondering if the pool might have issues.

Why Run Your Own CKPool Server Instead of Public Pools

Public solo mining pools serve their purpose. I’m not against them. But here’s the honest assessment after testing both approaches for months.

When you use a public pool, you’re sharing that pool’s Bitcoin node. You’re getting block templates from that node. If their node is slightly behind, your miners work on outdated data. If their stratum server has network issues, your miners sit idle. If they decide to shut down the service — like several smaller pools have done — you scramble to reconfigure everything.

Your own server eliminates all that. Your miners connect to your stratum server in your own network. Your server connects to your Bitcoin node. When a new block hits the network, your node sees it immediately, your server generates a new work template, and your miners switch over within milliseconds. No external dependencies.

Important detail: CKPool is the same software that runs solo.ckpool.org. You’re not using some untested alternative — you’re running the industry-standard stratum implementation that’s proven itself over years.

Does it matter for a small home mining operation? In most cases, probably not. The variance in solo mining is so massive that a few milliseconds of network latency to a public pool won’t meaningfully change your odds. But if you’re serious about learning the technical side, or running multiple ASICs at home, or just want complete control — this is worth doing.

Step 1: Set Up Your Bitcoin Full Node First

You can’t run a solo mining server without a Bitcoin full node. The server needs somewhere to get block templates from. That somewhere is your node.

I run Bitcoin Core on a dedicated Linux machine — an old desktop with a 2TB SSD. Bitcoin Core needs about 600GB for the blockchain data right now, growing roughly 60GB per year. You need fast storage. An HDD technically works, but it’s painfully slow during initial sync.

Download Bitcoin Core from bitcoin.org. Version 27.0 is current as of this writing, but any recent version works fine. Installation on Ubuntu:

Download and verify:

• Get the Linux tarball from bitcoin.org/en/download
• Verify the SHA256 hash matches the official release
• Extract: tar -xzf bitcoin-27.0-x86_64-linux-gnu.tar.gz
• Copy binaries to /usr/local/bin/

Configure Bitcoin Core for mining:

Create a bitcoin.conf file in ~/.bitcoin/bitcoin.conf with these settings:

• server=1 (enables RPC server)
• rpcuser=yourusername (pick something secure)
• rpcpassword=yourpassword (use a strong password)
• rpcallowip=127.0.0.1 (allows local connections)
• rpcport=8332 (default RPC port)
• txindex=1 (maintains full transaction index, useful but optional)

Start Bitcoin Core: bitcoind -daemon

The initial blockchain sync takes days. On my system with a decent SSD and 50 Mbps connection, it took four days. You can’t proceed until this completes. The software downloads every block since 2009 and validates every transaction. No shortcuts.

Check sync progress: bitcoin-cli getblockchaininfo

Look for the “verificationprogress” field. When it reaches 0.99999, you’re basically done. The last fraction takes longest because recent blocks are largest.

While you wait, read about the true cost of running a Bitcoin full node. I tracked everything — power consumption, storage costs, bandwidth usage. It’s not free, but it’s also not as expensive as some people claim.

Step 2: Install CKPool Dependencies and Build Tools

CKPool is written in C. You compile it from source. That means installing build tools first.

On Ubuntu/Debian systems:

sudo apt update
sudo apt install build-essential git autoconf automake libtool pkg-config libssl-dev

That installs the C compiler, Git for downloading the source code, autotools for building the project, and OpenSSL libraries that CKPool needs.

On other Linux distributions, the package names differ slightly. For CentOS/RHEL, use yum instead of apt. For Arch, use pacman. The concept stays the same — you need a C compiler and development libraries.

Verify you have everything:

• gcc –version (should show GCC version)
• git –version (should show Git version)
• autoconf –version (should show autoconf version)

If any of these commands fail, something’s missing. Install the missing package before proceeding.

Step 3: Download and Compile CKPool Mining Server

CKPool lives on GitHub at github.com/ckolivas/ckpool. Clone the repository:

cd /opt
sudo git clone https://github.com/ckolivas/ckpool.git
cd ckpool

I keep it in /opt because that’s the standard location for optional software on Linux. You can put it anywhere, honestly.

Build the software:

./autogen.sh
./configure
make

The autogen script generates the configure script. The configure script checks your system for required libraries and sets up the build environment. Make compiles the actual binaries.

This takes maybe two minutes on a modern system. If configure fails, it tells you what’s missing. Usually it’s a development library. Install that library and run configure again.

When compilation finishes, you get several binaries:

• ckpool (the main server)
• ckpmsg (monitoring tool)
• notifier (block notification handler)

Test it works: ./ckpool –help

If you see the help text, compilation succeeded.

You don’t need much hardware for a stratum server. I tested CKPool on a Raspberry Pi 4 with 4GB RAM serving five ASICs without issues. The server’s job is managing connections and generating work templates — it doesn’t do the actual mining computation. A Pi 5 with 8GB is actually overkill, but it gives you headroom if you scale up.

Step 4: Configure CKPool for Solo Bitcoin Mining

CKPool needs a configuration file. Create one at /opt/ckpool/ckpool.conf:

Basic solo mining configuration:

“btcd” : [
  {
    “url” : “127.0.0.1:8332”,
    “auth” : “yourusername”,
    “pass” : “yourpassword”,
    “notify” : true
  }
],
“proxy” : [
  {
    “url” : “0.0.0.0:3333”,
    “auth” : “miner”,
    “pass” : “x”,
    “mindiff” : 1,
    “startdiff” : 1024
  }
]

Let me explain what each section does.

The “btcd” section configures the Bitcoin Core connection. The URL points to your Bitcoin node’s RPC interface. If Bitcoin Core runs on the same machine, use 127.0.0.1. If it’s on another machine in your network, use that machine’s IP address. Port 8332 is the default RPC port.

The “auth” and “pass” match your bitcoin.conf rpcuser and rpcpassword settings. They must match exactly.

“notify” : true tells Bitcoin Core to notify CKPool immediately when new blocks arrive. This keeps your miners working on current data.

The “proxy” section configures the stratum server that your miners connect to. “url” : “0.0.0.0:3333” means listen on all network interfaces on port 3333. Your miners will connect to this port. If you only want to accept connections from the local machine, use “127.0.0.1:3333” instead.

“mindiff” : 1 sets the minimum difficulty. For solo mining, keep this at 1.

“startdiff” : 1024 sets the initial difficulty the server assigns to new miners. CKPool adjusts this automatically based on miner hashrate. I use 1024 for typical ASICs, but it adjusts itself anyway.

Important detail: CKPool supports multiple Bitcoin nodes for redundancy. You can add a second “btcd” block pointing to a backup node. If the first node goes down, CKPool automatically fails over to the second. I don’t bother with this for a home setup, but it’s useful if you’re running serious infrastructure.

Step 5: Start Your Solo Mining Server and Configure Firewall

Run CKPool as root (it needs privileges to bind to network ports):

sudo /opt/ckpool/ckpool -c /opt/ckpool/ckpool.conf

Watch the output. You should see lines like:

• “Connected to bitcoind”
• “Loaded current block height”
• “Stratifier ready”

If it says “Failed to connect to bitcoind”, check your Bitcoin Core RPC settings. The username/password in ckpool.conf must match bitcoin.conf exactly.

If it says “Address already in use”, something else is already using port 3333. Change the port in ckpool.conf.

Once running, test it locally: telnet localhost 3333

If telnet connects, your stratum server is listening. Press Ctrl+] then type “quit” to exit telnet.

Firewall configuration:

If your miners are on the same machine as the server, you don’t need to open any firewall ports. If your miners are on other machines in your home network, you need to allow connections to port 3333.

Using UFW (common on Ubuntu):

sudo ufw allow from 192.168.1.0/24 to any port 3333

Replace 192.168.1.0/24 with your actual home network subnet. This allows any device on your local network to connect to port 3333, but blocks external connections. Don’t open port 3333 to the internet — there’s no authentication, and you’ll get random miners connecting.

Using iptables:

sudo iptables -A INPUT -p tcp -s 192.168.1.0/24 –dport 3333 -j ACCEPT

Save the iptables rule so it persists across reboots. The method varies by distribution.

Step 6: Connect Your Mining Hardware to Your Private Server

Now comes the satisfying part — pointing your actual mining hardware at your own infrastructure.

Your stratum URL is: stratum+tcp://YOUR_SERVER_IP:3333

If your miners are on the same machine as the server, use 127.0.0.1. If they’re on other machines, use your server’s local IP address (check with: ip addr show).

In your miner’s configuration, set:

• URL: stratum+tcp://192.168.1.100:3333 (use your actual server IP)
• Worker: any name you want (CKPool accepts anything)
• Password: x (CKPool ignores this for solo mining)

For Bitaxe devices, enter the stratum URL in the web interface pool settings. For ASICs like Antminers, configure it through the miner’s web dashboard.

Start your miner. Check CKPool’s output — you should see:

“New client connected”
“Authorized worker”
“Diff set to 1024”

Your miner should start showing accepted shares. These shares don’t mean much in solo mining — they’re just proof your miner is working. What matters is finding an actual block.

If your miner can’t connect, check:

• Can you ping the server IP from the miner?
• Is the firewall blocking port 3333?
• Is CKPool actually running? (check with: ps aux | grep ckpool)
• Did you use the correct IP address?

Common mistake: Using the server’s public IP address instead of its local network IP. Your miners should connect using the private IP (192.168.x.x range), not the public IP.

Monitoring Your CKPool Server and Debugging Issues

CKPool logs everything to stdout by default. I redirect this to a file:

sudo /opt/ckpool/ckpool -c /opt/ckpool/ckpool.conf > /var/log/ckpool.log 2>&1 &

Then I can monitor it with: tail -f /var/log/ckpool.log

The log shows every connection, every share submission, every block update. When your Bitcoin node receives a new block, you see CKPool immediately generate a new work template and push it to all connected miners. That’s pretty satisfying to watch.

Key metrics to monitor:

• Connected miners (should match your actual hardware count)
• Share submission rate (depends on your total hashrate and difficulty)
• Block template updates (should happen every ~10 minutes as new blocks are found)
• Bitcoin node connection status (should stay connected continuously)

CKPool includes a monitoring tool called ckpmsg. Run it while CKPool is running:

/opt/ckpool/ckpmsg

This shows current statistics — connected workers, hashrate estimates, share counts. It’s not as detailed as pool dashboards like those on K1Pool or WoolyPooly, but it gives you the essential data.

I wrote a simple script that parses the CKPool log and sends me a notification if no shares are submitted for 10 minutes. That usually means a miner went offline or the network connection dropped. Early warning saves wasted mining time.

Here’s what the numbers say: I tracked uptime for three months. My CKPool server had 99.8% uptime. The two outages were both due to my Bitcoin node crashing (I ran out of disk space once, and had a power outage another time). CKPool itself never crashed.

Advanced Configuration: Multi-Coin Support and Proxy Modes

CKPool was designed for Bitcoin, but it works with any coin using the same stratum protocol. That includes Litecoin, Dogecoin (via merged mining), Bitcoin Cash, and various Bitcoin forks.

For Litecoin solo mining, point CKPool at a Litecoin Core node instead of Bitcoin Core. The configuration is identical — just different RPC credentials and ports. Litecoin Core uses port 9332 by default.

You can run multiple CKPool instances on the same machine, each connected to a different coin’s node, each listening on a different port. I tested this with Bitcoin on port 3333 and Litecoin on port 3334. Both ran simultaneously without issues.

Merged mining setup:

This is more complex. For merged mining Litecoin and Dogecoin, you need both nodes running, plus special merged mining proxy software. CKPool itself doesn’t handle the merged mining logic — that’s done by an external proxy that sits between CKPool and the nodes.

Honestly, for merged mining scenarios, I recommend LiteSolo.org instead of running your own infrastructure. The complexity of maintaining multiple full nodes and proxy software isn’t worth it unless you’re mining at serious scale.

Proxy mode for reducing node bandwidth:

CKPool can operate in proxy mode, where it doesn’t connect directly to a Bitcoin node, but instead proxies work from another stratum server. This lets you run CKPool locally (for low-latency connections from your miners) while using a remote node for blockchain access.

I don’t recommend this for solo mining. The whole point of running your own server is eliminating external dependencies. Proxy mode reintroduces that dependency.

Honest Assessment: When This Makes Sense and When It Doesn’t

Let me be clear: most solo miners don’t need their own CKPool server.

If you’re running one Bitaxe at 1 TH/s for fun, use solo.ckpool.org. The network latency of connecting to their public server versus running your own makes zero practical difference to your winning odds. The variance in solo mining is so enormous that milliseconds of latency are completely irrelevant.

Running your own server makes sense if:

• You have multiple ASICs (5+ machines) and want centralized infrastructure
• You’re experimenting with custom mining setups or development work
• You want to learn the technical details of stratum mining
• You value independence and control over convenience
• You already run a Bitcoin full node anyway

It doesn’t make sense if:

• You have limited technical experience with Linux servers
• You don’t want to maintain a Bitcoin full node (600GB+ storage, constant updates)
• You’re solo mining purely as a lottery ticket with minimal hardware
• You prefer someone else handling infrastructure uptime and monitoring

The electricity cost for running a dedicated server machine isn’t negligible. My Intel NUC running the Bitcoin node and CKPool draws 15W continuously. That’s 0.36 kWh per day, or roughly 131 kWh per year. At $0.12/kWh, that’s $16 per year in electricity just for the server. The storage (a 2TB SSD) cost me $80. The whole setup maybe costs $100 annually in electricity and eventual storage upgrades.

For context, my mining hardware draws 1400W. The 15W for the server is barely noticeable compared to that. But if you’re only running a Bitaxe that draws 15W itself, doubling your power consumption for server infrastructure makes no sense.

Important detail: Your Bitcoin node needs to stay synchronized. If you leave it offline for a week, you spend hours resyncing when you restart. If you let it fall too far behind (months), you might need to resync from scratch. This is a continuous commitment, not a one-time setup.

Security Considerations for Home Mining Infrastructure

Running server software opens security concerns. Here’s what I learned the hard way.

Don’t expose your stratum port to the internet. CKPool has no authentication beyond accepting any worker name. If you open port 3333 to the world, random miners will connect and use your infrastructure. They won’t steal anything (solo mining rewards go to the worker’s configured payout address), but they’ll waste your Bitcoin node’s bandwidth.

Actually worse: if someone connects enough miners to your server, they could potentially find a block, and that block’s reward goes to their address, not yours. You provided the infrastructure, they got the reward. Don’t let that happen.

Keep port 3333 firewalled to your local network only. If you need to connect miners from outside your home network, use a VPN rather than exposing the stratum port directly.

Secure your Bitcoin Core RPC interface. Use a strong rpcpassword in bitcoin.conf. The default is no password, which is insecure if anyone gains access to your network. Pick a long random password.

Set rpcallowip to only allow localhost (127.0.0.1) unless you specifically need remote RPC access. CKPool connects locally, so there’s no reason to allow remote connections.

Keep Bitcoin Core updated. Security vulnerabilities get patched regularly. I check for updates monthly. It’s a 5-minute process to download the new version, stop the old daemon, start the new one.

Monitor your server for unauthorized access. Check auth.log (on Ubuntu: /var/log/auth.log) occasionally for failed SSH login attempts. If you see thousands of failed attempts from random IPs, someone’s trying to brute-force your SSH access. Fail2ban can help with this.

I run my mining infrastructure on a dedicated VLAN isolated from my main home network. If the mining machines get compromised somehow, they can’t access my personal computers. That’s probably overkill for most home miners, but it’s how I sleep well at night.

Comparing DIY CKPool vs. Public Solo Mining Pools

I tested both approaches side by side for two months. One Antminer S19 pointed at my local CKPool server, one identical S19 pointed at 2Miners SOLO pool.

Results: No measurable difference in share acceptance rate or orphan blocks. Both found zero blocks (expected — 200 TH/s for two months is nowhere near enough hashrate for reliable block finding).

Share latency averaged 2ms on the local server, 48ms on the public pool. That’s a 23x difference in latency. Sounds significant, right?

It isn’t. Those milliseconds don’t matter. By the time a new block propagates through the Bitcoin network to both nodes, the latency difference is lost in the noise. Your odds of finding a block during those 46 milliseconds is basically zero.

Here’s what actually mattered:

• Public pool had better monitoring dashboards and historical statistics
• Public pool required zero maintenance on my part
• Local server gave me complete visibility into what was happening
• Local server taught me significantly more about how stratum mining actually works

Public pools like SoloPool.org or HeroMiners SOLO handle multiple coins, have excellent uptime, and don’t charge fees (most don’t charge fees for solo — they’re basically running infrastructure as a service to the community).

Your own CKPool server gives you independence and learning opportunities, but requires ongoing maintenance and technical knowledge.

Pick based on your priorities. Both work fine for actual mining.

Frequently Asked Questions

Can I use CKPool for GPU mining or only ASICs?

CKPool works with any mining hardware that speaks the standard stratum protocol. GPUs, ASICs, FPGAs — doesn’t matter. The server doesn’t care what hardware submits shares. I’ve tested it with Bitaxe sticks, Antminer S9s, and even CPU miners (just for testing — CPU mining Bitcoin makes zero sense economically). Everything connected without issues. The hardware sends shares to the stratum port, CKPool validates them, that’s it.

Do I need to keep my Bitcoin node running 24/7?

Yes. If your Bitcoin node goes offline, CKPool can’t generate new block templates, and your miners stop receiving work. They’ll just sit idle until the node comes back online. Some ASIC firmware handles this gracefully by retrying connections. Other firmware throws errors and stops. Either way, you’re not mining while the node is down. I run mine on a machine that stays powered on continuously. If you can’t guarantee 24/7 uptime, a public solo pool like 2Miners SOLO makes more sense — they handle the infrastructure uptime.

What happens if I find a block with my own server?

CKPool validates the block solution, then submits it to your Bitcoin node. Your node broadcasts it to the Bitcoin network. If the block gets accepted by the network (isn’t orphaned), the coinbase transaction in that block pays the block reward to whatever address your mining hardware configured. Make absolutely sure your miners are configured with your own Bitcoin address before you start. I’ve read horror stories of people finding blocks while testing with random example addresses from tutorials. That 3.125 BTC reward (currently worth around $66,077 each) goes to whoever owns the address in the coinbase transaction. There’s no undo button.

Can I run CKPool on Windows instead of Linux?

CKPool is designed for Linux and doesn’t officially support Windows. You could theoretically compile it using Windows Subsystem for Linux (WSL2), but I haven’t tested this and can’t recommend it. Mining infrastructure should be stable and reliable. Linux is the standard for a reason — it’s designed for server workloads, has better networking performance, and doesn’t randomly restart for Windows updates. If you only have a Windows machine, honestly just use a public solo pool. Or install Linux on an old laptop or Raspberry Pi specifically for this purpose. A basic Ubuntu Server installation uses minimal resources.

How do I upgrade CKPool when new versions release?

CKPool updates infrequently — maybe once or twice a year. To upgrade, stop the running CKPool process, pull the latest code from GitHub (git pull in the /opt/ckpool directory), recompile (make clean && make), and restart CKPool. Your configuration file doesn’t change between versions. The whole process takes maybe five minutes. I subscribe to the CKPool GitHub repository to get notifications when new releases happen. In three years of running it, I’ve upgraded maybe four times. It’s stable software that doesn’t need constant updates.

One final thought after running this setup for months: the value isn’t finding blocks faster (you won’t). The value is understanding every layer of the mining stack. When you control your own node and stratum server, you see exactly how mining works. That knowledge is worth more than the convenience of public pools, at least to someone who wants to truly understand the process.

When my friend found a Bitcoin block with his Bitaxe, he was using a public pool. Nothing wrong with that. But I understood exactly what happened behind the scenes because I’d watched my own server handle millions of shares and block template updates. That’s the real benefit — deep technical knowledge of the mining process.