Change control for the things a customer can break remotely: firmware, pool settings, tuning profiles, and who carries the risk of each change.
A hosting contract fixes the power figure and the price, and then hands you a dashboard with a firmware version, a pool address, and a set of tuning sliders that neither party has written down anywhere. That gap is where most disputes over a bad week of hashrate start. The question is not only whether you may tune your own fleet. It is what happens, on paper, once you do.
What a customer can usually reach remotely
Most hosting setups give the customer some combination of four things: the firmware image running on each unit, the pool and worker configuration it points at, a power or frequency tuning profile, and in some cases a fan or thermal curve. Which of these you can touch, and whether you can touch all of them across the whole fleet at once or only unit by unit, is a hosting decision, not a technical constant. Ask for the list rather than assuming it matches the last site you hosted at, because the answer varies by operator and sometimes by rack.
Each of these settings does something different to the machine and to the site around it. A firmware change can move the unit's power draw and its acoustic and thermal profile in the same motion, sometimes without the interface making that obvious before you apply it. A tuning profile pushed above the manufacturer's stock curve raises heat output for the same footprint, while the site's cooling was sized against a specific heat load, not an open-ended one. That does not make tuning wrong. It means a change on your side of the dashboard has a physical effect on the operator's side of the wall, and a contract that treats it as purely your business is missing that connection.
The machine next to yours
The reason an operator cares about a change you make to your own hardware is rarely the hardware itself. It is the rack. Air-cooled containers and hot-aisle rows are designed around an expected heat load per position, and a small number of units pushed well past their stock profile can shift the thermal picture for everything sharing that airflow path, not just the unit that was changed. The same logic applies to draw: a site's power distribution is built to a planned figure, and machines running meaningfully above nameplate change the assumption that figure was built on, even if no single unit trips a breaker on its own.
This is also why blanket permission is rare in practice. An operator that lets every customer push firmware and tuning changes with no visibility into the aggregate effect is accepting a risk it cannot see coming, and one that blocks all remote changes outright is asking fleet owners to give up a tool they reasonably expect to use. The workable middle is a defined envelope: which parameters you can change without asking, which need a heads-up, and which need sign-off before they go live.
Approval, notice and what a fair clause says
A useful change control clause names the categories above separately rather than lumping them under one heading called "customer changes." It should say which changes you can make unilaterally, which require advance notice to the operator even if no approval is needed, and which require the operator's sign-off before you apply them, typically anything that would push draw or heat meaningfully above the profile the site was built for. It should also say how much notice each category needs and through what channel, since an email that sits unread for a week is not meaningfully different from no notice at all.
The other half of the clause is what happens to warranty and liability once a change has been made. If a firmware change or an aggressive tuning profile contributes to a hardware failure, the contract should say plainly whether that shifts liability towards the customer, and whether it affects any uptime commitment the operator has made for that unit going forward. Silence on this point does not mean the risk sits with the operator by default, it usually means the question gets argued after the fact, which is a worse position for both sides than having it written down first.
Logging and getting back to a known state
The last piece is less about permission and more about recovery. When a change is applied, is it logged against a timestamp and an account, in a form either side can pull later without a dispute over whose recollection is right? And separately, is there a defined way back to a known-good configuration if a change turns out to cause a problem, rather than a manual rebuild from memory? A site that can show you exactly what changed, when, and by whom is a very different partner to work with than one where a firmware update is a rumour by the time anyone is asking about a thermal event well after the fact.
What to ask before you tune anything
Before you push a fleet-wide firmware update or a new tuning profile at a hosted site, get clear answers to a short set of questions, in writing if the contract itself does not already cover them:
- Which settings can you change without notice, which need advance notice, and which need sign-off first?
- Who is notified, through what channel, and how far ahead of the change?
- What happens to warranty or liability on a unit if a change contributes to a failure?
- Is every change logged against an account and a timestamp, and can you pull that log yourself?
- Is there a defined rollback path to a known-good configuration?
If those answers are not in the document you were sent, raise them before the fleet goes live, not after the first thermal alert. At our facilities, pool and worker configuration stay with you; firmware changes and over- or underclocking follow the procedure in the service agreement and need written approval. The wider set of clauses a hosting agreement should answer is covered in our guide to the agreement itself. Our hardware page sets out the model families we host and how each is cooled.
