I’ve setup a fairly reliable system at home for monitoring and maintaining my Chia farming setup, so I decided to write up what I have done for anyone who needs a little guidance on doing similar. This was inspired in no small part by still seeing after all this time, the occasional person seeking support who is running a dozen or more versions prior to the current. Folks seem shocked to hear that “set it and forget it” is a bad idea and that they have been missing out on potential blocks due to soft forks, etc.
This is not the be-all, end-all definitive guide for every use case, but it’s meant to be a starting point for folks who have yet to start anywhere. There might be other ways some folks would like to do some things, and that’s fine. You might have different preferred tools (mine’s Ansible) or esoteric environment setups that require extra steps that might make you think my advice is bad. It’s not, it’s just different… to each their own.
For my setup, we’re going off a few basic assumptions here:
- You have Ubuntu or a similar Linux environment for your setup running as a CLI (personally, I feel it’s not advisable that you are running Windows or Mac with the GUI for a high availability background server farming setup)
- You have installed via the official release packages. (While it’s perfectly reasonable to install via source for specific needs from development branches, betas, or other troubleshooting/testing purposes, for a set-it-and-forget-it farmer setup, a release package install is the officially supported path.)
- Things like setting up Ansible and manually adding the Chia release packages to your apt repository are out of scope for this.
In my case, I have my farm divided into my primary farmer with most of the harvesting on that same system, as well as a remote harvester on a Synology NAS (any space not currently allocated to my NAS for it’s primary use that is left over, is allocated to as many plot files as I can fit with 1TB of empty space overhead. Anytime I use up more of that space, I delete a few plot files to keep my overhead), and my Node running on a dedicated VM.
I have this setup because I have a few various test and development things running, and being able to have them all talk to the same node is convenient (and bandwidth friendly) as well as putting me in an easy-recovery state for my node, if it has issues without impacting my farm.
For the Farmer/Harvester and the Node, I have installed Chia via the Ubuntu package, and I use the official docker container on the Synology in Harvester-only mode.
For my farmer, it’s an Ubuntu system running simply the farmer, harvester, and wallet services.
In order to avoid duplicated bandwidth usages from the Farmer due to the default settings having the wallet service talk to a random Node on the internet and not the local remote node, if your node is on a remote instance like I have, then you need to do the following:
Step 1: Change the wallet config on the farmer server to:
wallet: connect_to_unknown_peers: False trusted_peers: 0ThisisanexampleNodeID7ff9d60f1c3fa270c213c0ad0cb89c01274634a7c3cb9: anything_can_go_here
For the NodeID for trusted peer, get this by doing chia show -s and copying the node ID on the node instance)
Step 2: Change your Node instance’s config to:
full_node: exempt_peer_networks: ["192.168.1.0/24"]
This will make sure your Node ALWAYS accepts connections from your farmer, even if it’s peer count is full
I also have custom defined services setup for the farmer and node, to make management and restarts much easier, as well as making Ansible runbooks far simpler.
[Unit] Description=Chia Farmer Service [Service] Type=forking User=my_user WorkingDirectory=/home/my_user/ ExecStart=chia start farmer-only harvester wallet ExecStop=chia stop -d all Restart=no [Install] WantedBy=multi-user.target
[Unit] Description=Chia Node Service [Service] Type=forking User=my_user WorkingDirectory=/home/my_user ExecStart=/usr/bin/bash -c "chia start node" ExecStop=/usr/bin/bash -c "chia stop -d all" Restart=always [Install] WantedBy=multi-user.target
For monitoring, I am using chia-monitor. It’s not the single best solution, but it works for my needs and while seemingly no longer updated much, I’ve had zero issues and if it ain’t broke don’t fix it! (Though I do plan to replace it down the road with the CNI-developed chia-exporter sooner or later, probably when 2.0 comes out in a few weeks after this writing.) It creates a simple status output text page, that Prometheus can scrape for me and feed into Grafana. For simplicity, I have setup a service to manage it.
The monitor application, and the service config, are setup on both the farmer and the node.
[Unit] Description=chia-monitor prometheus exporter Wants=network-online.target chia-farmer.service After=network.target network-online.target chia-farmer.service Requires=chia-farmer.service BindsTo=chia-farmer.service StartLimitIntervalSec=0 [Service] Restart=always User=my_user ExecStartPre=/bin/sleep 60 ExecStart=/usr/bin/env bash -c 'cd ~/monitoring_chia/chia-monitor; pipenv run python -m monitor' [Install] WantedBy=multi-user.target
Making life easier for updating
Now for the the point of all the above work. Once you have set things up, updating Chia becomes trivial, which is the important part of all of this!
This simple runbook will connect to all my chia_prod hosts (which are defined elsewhere within Ansible as the farmer and node), and update their package repo, update the code, restart the services, and then restart the monitors for good measure as they get cranky if you restart chia and not them after. (There is a secondary runbook triggered by this one not covered here that also rebuilds the Docker container on the synology NAS to the latest version as well, by making a quick call to my Portainer agent on that device.)
The Ansible playbook
--- - hosts: chia_prod become: yes tasks: - name: Stop Chia service ansible.builtin.service: name: chia state: stopped - name: Update the repository cache and update Chia to latest version ansible.builtin.apt: name: chia-blockchain-cli state: latest update_cache: yes - name: Start chia service ansible.builtin.service: name: chia state: started - name: Restart monitroing service ansible.builtin.service: name: chia-monitor state: restarted
That’s it! If you take a little time to the above leg work, one simply command of
Will do everything you need to update Chia, each time a new release comes out, across all your systems!