Chia Harvesters Automation: How to Scale Your Farm Across Multiple Machines

• Key Takeaway 1: The most reliable Chia farm setup runs one full node (farmer + wallet) on your best machine and deploys lightweight harvesters on every other storage machine — this saves bandwidth, protects your keys, and makes your farm faster.
• Key Takeaway 2: Each harvester needs its own unique TLS certificate signed by your main machine’s Certificate Authority (CA) — sharing certificates between harvesters will break your farm silently.
• Key Takeaway 3: Automating auto-start with systemd on Linux or Task Scheduler on Windows means your harvesters come back online after a reboot without you touching a single keyboard.
• Key Takeaway 4: Free tools like Chiadog parse your debug.log in real time and send mobile alerts the moment a drive disconnects, a harvester goes offline, or you win a block reward.
• Key Takeaway 5: Automated plot transfer with rsync or Robocopy eliminates manual file moves and keeps your storage machines full without daily oversight.

Chia harvesters automation means setting up your farm so that every machine starts, runs, monitors itself, and fills its drives with plots — all without you being there to babysit it. Done right, a properly automated multi-harvester Chia farm can run for weeks without manual input, alerting you only when something genuinely needs attention.

What Is a Chia Harvester and Why Run Multiple Machines?

Before you can automate anything, you need to understand the architecture Chia was built around. A Chia farm isn’t just “one computer running a program.” It’s a split system. Your main machine runs three things at once: the full node (which syncs the blockchain), the farmer (which receives challenges from the network every nine seconds or so), and the wallet (which holds your keys). Your harvester machines do exactly one job: scan the plot files stored on their hard drives and check whether any of them answer the current challenge. That’s it.

This split is the official recommended setup from Chia Network for any farm using more than one computer.^[1] The reason is simple and practical. If every machine ran a full node, each one would be downloading and syncing the entire Chia blockchain independently — wasting bandwidth, CPU, and storage. By keeping the blockchain on one machine and letting the rest focus purely on scanning plots, your farm becomes leaner, your responses to challenges are faster, and your private keys only ever live in one place.

For crypto miners making the jump from GPU or ASIC rigs, think of it like this: the farmer is your mining pool software and the harvesters are your individual rigs. Each rig reports in, does its check, and reports back. The difference is that Chia harvesters use almost no electricity compared to a GPU rig — they’re basically just spinning hard drives attached to a low-power computer.

How TLS Certificates Keep Harvesters Secure

The connection between your farmer and each harvester is encrypted using TLS (Transport Layer Security), the same technology that secures websites. Your main machine acts as a private Certificate Authority (CA) — it’s the authority that issues and signs security certificates for every harvester that joins your farm. When you initialize a new harvester, you temporarily point it at a copy of your main machine’s /ca directory and run chia init -c [path-to-ca]. This generates a unique certificate for that harvester, signed by your farm’s CA.

One critical rule: never copy the entire /ssl directory from your main machine to a harvester. Every harvester must have its own unique certificate. If two machines share the same certificate, your main node treats them as one machine, causing silent failures and missed proofs. After initialization, the CA files in the temp folder can be deleted — the harvester only needs its own signed certificate to operate going forward.^[1]

Configuring the Harvester to Point at Your Farmer

Once the certificate is created, you need to tell the harvester where your farmer lives. Open ~/.chia/mainnet/config/config.yaml on the harvester machine and find the farmer_peer section under harvester: (not the full_node section — that’s a common mistake). Set the host value to your main machine’s local IP address and leave the port as 8447. A static local IP on your main machine is strongly recommended here; if your router’s DHCP reassigns the IP after a reboot, every harvester loses connection to the farmer instantly. After saving the config, run chia start harvester -r to bring it online. Within a minute or two, the Farm tab on your main machine’s GUI will show the new harvester’s plots appearing in the “Last Attempted Proof” pane.

Quick Decision Table: Which Chia Harvesters Automation Approach Is Right for Your Setup?

Automating Harvester Auto-Start: Never Miss a Challenge After a Reboot

The most basic automation task — and the one that immediately saves you the most frustration — is making sure your harvesters restart themselves after a power cycle, software update, or crash. Without this, every time a machine reboots (and they will reboot, whether you plan it or not), your farm shrinks until you manually SSH in or physically walk to the machine and restart it. That’s proofs missed. That’s XCH left on the table.

Setting Up Auto-Start on Linux with systemd

On any Linux-based harvester (Ubuntu, Debian, Raspberry Pi OS, etc.), systemd is the right tool for the job. You create a small service file that tells the operating system to start the Chia harvester on boot, restart it if it crashes, and log its activity. Here’s what a working service file looks like:

[Unit]
Description=Chia Harvester
After=network.target

[Service]
Type=forking
User=YOUR_USERNAME
WorkingDirectory=/home/YOUR_USERNAME
ExecStart=/home/YOUR_USERNAME/chia-blockchain/venv/bin/chia start harvester
ExecStop=/home/YOUR_USERNAME/chia-blockchain/venv/bin/chia stop harvester
Restart=on-failure
RestartSec=30s

[Install]
WantedBy=multi-user.target

Save this as /etc/systemd/system/chia-harvester.service, then run sudo systemctl daemon-reload, sudo systemctl enable chia-harvester, and sudo systemctl start chia-harvester. The Restart=on-failure line is what makes this powerful — if the harvester process crashes for any reason (a Chia update, a memory issue, anything), systemd will automatically restart it after 30 seconds without any input from you.

Setting Up Auto-Start on Windows with Task Scheduler

Windows harvesters can achieve the same result using Task Scheduler. Create a simple batch file (call it something like start_harvester.bat) that changes directory into the Chia daemon folder and calls chia.exe start harvester. The exact path will include your Chia version number, typically inside %LOCALAPPDATA%\chia-blockchain\app-[version]\resources\app.asar.unpacked\daemon\. Then open Task Scheduler, create a new basic task, set the trigger to “At startup” or “At log on,” and point the action to your batch file. The key setting to get right is to enable “Run whether user is logged on or not” — without this, the task only fires if someone is actively logged in, which defeats the purpose on a headless harvester box.

A harvester that restarts itself automatically is the single highest-value automation you can add to a Chia farm. It transforms a machine that needs daily check-ins into one that truly runs in the background for weeks.

Chia Harvesters Automation for Monitoring: Know the Second Something Goes Wrong

Auto-start keeps your harvesters running. Monitoring tells you when they aren’t. These two things work together — you can’t have a truly automated farm without both. The good news is that the Chia community has built excellent free tools specifically for this purpose.

Chiadog: Lightweight Log-Based Alerting for Every Harvester

Chiadog is an open-source Python watchdog that runs alongside your Chia processes and parses the debug.log file in real time.^[2] It watches for specific patterns in the log and sends you a push notification the moment something looks wrong. The list of conditions it detects is exactly what a serious farmer cares about: a harvester going offline, a hard drive disconnecting (which shows up as a sudden drop in plot count), a proof search taking too long (which can indicate a failing drive or CPU bottleneck), skipped signage points, and successful block finds. It also sends a daily summary so you always know your farm’s baseline health even when nothing has gone wrong.

What makes Chiadog particularly useful for multi-harvester farms is its remote monitoring mode. You don’t need to install it on every machine separately. You can run a single instance on your main farmer machine and connect it to each harvester via SSH, reading each remote machine’s debug.log over an encrypted connection. Set up SSH key authentication between your farmer and each harvester once, point Chiadog at each machine’s log path, and one central process watches your entire fleet.^[3]

Prometheus + Grafana for Larger Farms

For farms running ten or more harvesters, a dashboard gives you a bird’s-eye view that log parsing alone can’t provide. The chia-monitor tool by philippnormann collects metrics directly from the Chia daemon via its RPC and WebSocket interfaces and exports them in a Prometheus-compatible format.^[4] Hook that into a Grafana dashboard (community dashboard ID 14544 is ready to import) and you get real-time graphs of plot counts per harvester, proof response times, sync status, wallet balance changes, and more — all in one browser tab. This is the setup serious large-scale farms use because it turns reactive problem-solving into proactive capacity management.

Expert Perspective on Harvester Response Time

“Harvesters control the actual plot files by retrieving qualities or proofs from disk. Tape drives are too slow for farming. The protocol was designed to support hard disks, but nothing slower.”

— Chia Network Official Documentation, Harvesters^[5]

This matters for automation because it means you can use monitoring response times as a health proxy. If Chiadog or your Grafana dashboard shows average proof search times creeping above 5 seconds on a harvester, that’s an early warning of a failing drive or an overloaded CPU — not just a slowness issue. Catching this early, before it causes missed challenges or a complete harvester disconnect, is exactly what automated monitoring is designed to do.

Automating Plot Distribution Across Your Harvester Network

Plots don’t move themselves. If you’re plotting on a dedicated machine (which is the right way to do it — keep plotting and farming separate), you need a reliable way to push finished plot files to the right harvester drives without manually moving files every time a plot completes.

Using rsync on Linux for Hands-Free Plot Transfers

On Linux-based farms, rsync is the standard solution. A simple cron job can scan your plotting output directory every few minutes and push any new .plot files to the target harvester. Here’s a minimal example of what that looks like in practice:

# Runs every 10 minutes, syncs new plots to harvester1
*/10 * * * * rsync -av --remove-source-files /mnt/plotting/completed/*.plot harvester1-user@192.168.1.x:/mnt/plots/

The --remove-source-files flag deletes the plot file from the plotter after a successful transfer, automatically freeing up the plotting drive for the next plot. You can set up multiple lines — one per harvester — and use a load-balancing script to check free space on each harvester before deciding where to send the next plot. Tools like chia_plot_manager wrap this logic in a full management suite that tracks available space per machine and routes plots intelligently.

Using Robocopy on Windows for Plot Transfers

Windows farmers have Robocopy, which is built into every modern version of Windows and works very well for this task. A basic Robocopy command for continuous plot monitoring looks like this:

robocopy "C:\Plotting\Completed" "\\HARVESTER1\Plots" *.plot /MOV /W:5 /R:3

The /MOV flag moves files (deleting from source after transfer), /W:5 waits 5 seconds between retries, and /R:3 retries 3 times on failure. Wrap this in a batch script and schedule it via Task Scheduler to run at startup and you have a persistent background process handling all your plot distribution automatically.

Automated plot distribution with rsync or Robocopy eliminates the daily manual file-moving that kills the economics of running a Chia farm at scale. Once set up, you add drives, point the destination path at the new machine, and the system fills it without any further action from you.

Comparison: Manual Harvester Management vs. Chia Harvesters Automation

Troubleshooting Common Chia Harvester Connection Problems

Even a well-automated farm runs into issues. Most harvester connection problems fall into a handful of predictable categories, and knowing what to look for cuts debugging time from hours to minutes.

Harvester Not Showing Up on the Farm Tab

If a harvester is running but not appearing in the farmer’s Farm tab, the first thing to check is the firewall. Port 8447 must be open and accessible on your main machine from the harvester’s IP. This is a TCP connection — the harvester dials out to the farmer, not the other way around. On Linux, sudo ufw allow 8447/tcp handles it. On Windows, add an inbound rule in Windows Defender Firewall for port 8447. The second thing to check is whether the harvester’s config.yaml has the correct static IP for the farmer in the farmer_peer section. A wrong or outdated IP here means the harvester is reaching out to a dead address and silently failing.

SSL Certificate Errors After a Chia Update

Major Chia updates sometimes change the CA structure, which can invalidate existing harvester certificates. This is one of the rare situations where you do need to repeat the CA copy and chia init -c process on each harvester. Chiadog’s SSL error detection will flag this quickly if you have it running. The fix is the same as initial setup: copy the updated /ca directory to each harvester temporarily, run chia init -c [path], clean up the temp directory, and restart the harvester service. If you have this documented as a shell script, a five-machine update takes about ten minutes instead of an hour.

Proof Response Times Over 5 Seconds

The Chia protocol expects harvesters to respond to challenges within a tight window. If your debug.log or Chiadog alerts show proof search times regularly exceeding 5 seconds, there are three likely causes. First, a failing or fragmented hard drive that’s taking too long to seek across plots. Second, too many plots assigned to a single harvester machine that can’t scan them fast enough. Third — particularly relevant on combined plotter/harvester setups — CPU cores being starved by active plotting. The fix for the last case is what the official Chia docs specifically recommend: exclude one or two CPU cores from your plotter’s configuration so the harvester process always has dedicated compute resources available.^[1]

Scaling to a Large Farm: Architecture That Stays Automated at Any Size

As your farm grows past five or six harvesters, the architecture decisions you made early start to matter more. The pattern that works well at large scale — whether you’re running a dozen machines at home or a NAS-heavy operation — follows a few consistent principles. Your farmer node should be your most reliable machine, ideally on a UPS so it doesn’t lose power when everything else might. Your harvester machines should be as minimal as possible: low-power ARM boards or refurbished mini PCs work perfectly since they’re only scanning plots, not running a blockchain. Network segmentation matters on large farms — if your plot transfer traffic from plotter to harvesters is sharing the same link as your farmer-to-harvester signage point communication, you can create congestion that causes missed challenges. A basic VLAN split or separate switch for plot transfers vs. farming traffic eliminates this entirely.

For provisioning new harvesters at scale, Ansible is worth learning. An Ansible playbook can take a freshly imaged machine from zero to a fully configured, certificate-signed, auto-starting harvester in under five minutes without any manual steps. You write the playbook once — install Chia, copy CA, run init, configure the IP, write the systemd unit, enable and start the service — and then run it against any new machine by name. This is how professional operations add capacity: not machine by machine with manual steps, but with a single command that handles the entire provisioning sequence.

A Case Study Worth Noting

The Machinaris project demonstrated this architecture at its most polished: it packaged Chia, Bladebit plotter, Chiadog monitoring, and a full web UI into a Docker-based stack deployable across multiple machines with a single compose file, showing what fully automated multi-harvester management looks like in a production-grade open-source tool. Note that as of 2024 the project’s maintainer indicated active development is winding down, so verify compatibility with your current Chia version before deploying.^[6]

For more on how the Chialisp programming layer underpins the smart contract logic that makes Chia’s farming rewards and pooling protocols trustless, see our deep dive on how Chialisp is transforming blockchain smart contracts.

Conclusion: A Chia Farm That Runs Itself Is Within Reach

Chia harvesters automation is not a single tool or a one-time setup — it’s a layered approach that builds on itself. Start with the foundation: one farmer, properly split harvesters, each with their own TLS certificate pointing at your main machine on port 8447. Layer in auto-start with systemd on Linux or Task Scheduler on Windows so reboots are no longer events that shrink your farm. Add Chiadog for real-time alerting so you find out about problems in seconds rather than hours. Set up rsync or Robocopy to move finished plots automatically. And as your farm grows, add Ansible for provisioning and Grafana for fleet-wide visibility. At each stage, you’re converting manual work into background processes — and that conversion is exactly what lets a Chia farm scale from three machines to thirty without adding thirty times the management overhead. Take the first step today: get systemd configured on your harvesters, and your farm immediately becomes more resilient than it was yesterday.

Chia Harvesters Automation FAQs

What is chia harvesters automation and why does it matter?

Chia harvesters automation is the process of configuring your farm’s harvester machines to start, restart, monitor themselves, and receive new plots without any manual intervention. It matters because every minute a harvester is offline or a drive is disconnected is a missed chance to respond to a network challenge and win XCH — and manual management simply doesn’t scale past a few machines.

How do I set up chia harvesters automation for multiple machines at once?

To set up chia harvesters automation across multiple machines, start by running the official “Farming on Many Machines” procedure for each harvester — copying the CA from your farmer, running chia init -c on each machine, and setting the farmer’s IP in each harvester’s config.yaml. Then add a systemd service (Linux) or Task Scheduler task (Windows) on each machine, and optionally use an Ansible playbook to push these steps to all machines simultaneously rather than one at a time.

What tools should I use to monitor my Chia harvesters automatically?

Chiadog (github.com/martomi/chiadog) is the most widely used free tool for automated Chia harvester monitoring — it parses your debug.log and sends mobile alerts for offline harvesters, dropped drives, and slow proof searches. For larger farms wanting dashboards, the chia-monitor tool paired with Prometheus and Grafana provides full fleet-wide metrics visibility.

Why is my harvester not connecting to the farmer after setup?

The most common reasons a harvester won’t connect to the farmer are a blocked port 8447 on the main machine’s firewall, an incorrect or dynamic farmer IP in the harvester’s config.yaml, or a Chia update that invalidated the harvester’s TLS certificate. Check the farmer’s debug.log for connection attempts and set a static local IP on your main machine to prevent the IP-change issue from recurring.

Can I automate plot transfers as part of my Chia harvesters automation setup?

Yes — automating plot transfers is a core part of a fully automated Chia farm. On Linux, a cron job running rsync with the --remove-source-files flag pushes finished plots from your plotter to harvester drives and cleans up automatically. On Windows, a scheduled Robocopy task with the /MOV flag does the same job without any manual file management needed.

Chia Harvesters Automation Citations

1. Chia Network. “Farming on Many Machines.” Official Chia Documentation. docs.chia.net.
2. Martomi. “Chiadog: A Watchdog Providing Peace of Mind That Your Chia Farm Is Running Smoothly 24/7.” GitHub.
3. Martomi. “Monitoring Multiple Harvesters.” Chiadog Wiki. GitHub.
4. Philippnormann. “Chia-Monitor: A Comprehensive Monitoring and Alerting Solution for the Status of Your Chia Farmer and Harvesters.” GitHub.
5. Chia Network. “Harvesters.” Official Chia Documentation. docs.chia.net.
6. Guydavis. “Machinaris: An Easy-to-Use WebUI for Crypto Plotting and Farming.” GitHub.
7. ChiaTribe. “Chialisp: Transforming Blockchain and Unlocking Next-Gen Smart Contracts.” ChiaTribe.com.