Skip to main content
£0.00 0

Basket

No products in the basket.

ASIC mining knowledge centre

How to Configure HiveOS for an ASIC Miner

Complete a secure HiveOS ASIC configuration with ASIC Hub, farm registration, device discovery, credentials, flight sheets, monitoring and recovery.

HiveOS ASIC configuration guide cover

A secure HiveOS ASIC configuration can use ASIC Hub as a bridge between stock-firmware miners and the Hiveon OS dashboard, avoiding a firmware replacement on supported devices. The Hub needs local IP access and miner credentials, so it belongs on a maintained, segmented host rather than an exposed desktop. Register the correct farm, discover a small test range, apply a reviewed flight sheet and verify pool acceptance before extending control to a fleet.

Choose the right Hiveon OS integration route

Reassess HiveOS ASIC configuration whenever network conditions, firmware, tariffs or official guidance changes.

Hiveon documents ASIC Hub as a bridge that collects statistics from each miner, sends them to Hiveon OS and applies supported configuration such as flight sheets. It does not require a special firmware on the ASIC, although its control features are more limited than custom firmware.

A direct ASIC client or Hiveon firmware is a different installation. Check exact model and control-board support, warranty, developer fee, recovery and security before replacing stock firmware. Do not mix instructions from the two routes.

ASIC Hub is appropriate when the miners are reachable by IP from a local host and stock firmware exposes a supported API. The Hub host becomes a management asset and a single point of monitoring failure, so design it deliberately.

Prepare the farm, network and Hub host

When reviewing HiveOS ASIC configuration, separate measured facts from forecasts so the result can be reproduced.

Create or identify the correct Hiveon OS farm and record who owns it. The farm hash registers a Hub into that farm and must be treated as a credential, not placed in screenshots, public scripts or support posts.

Place miners and the Hub in a dedicated operational segment. The Hub needs access to miner management interfaces and the Hiveon service, but it should not gain broad access to customer, payment or office systems. Do not publish its local web interface to the internet.

Use a supported Linux or Windows host with stable power, time, storage and updates. Hiveon currently documents Ubuntu 18 or later, Debian Stretch or later, or another systemd distribution with a suitable glibc for the Linux Hub; check the live requirements before installation.

ASIC Hub preparation record
Item Evidence Risk if omitted
Farm ownership Named account and recovery controls Fleet registered to wrong or lost account
Network range Approved miner subnet or IP list Unintended device scanning
Hub host Supported OS, backup and patch owner Single unmanaged failure point
Miner credentials Unique protected administration Fleet-wide compromise
Pool and wallet Verified flight-sheet values Hashrate sent to wrong destination

Install ASIC Hub from the official source

No conclusion about HiveOS ASIC configuration should rely on a single revenue snapshot or an undated specification.

Hiveon’s Linux guide provides a simple install script and a manual tarball method. For a controlled business deployment, verify the official download domain, retain the package and record the installed version. Review scripts before running them with elevated privileges.

The documented service is named asic-hub and the command-line tool is hubctl. Confirm the service runs under the expected account, its configuration and data paths have appropriate permissions and logs rotate. Do not continue if an unexpected binary, service or listening port appears.

The Hub web interface is documented on a local port. Bind or firewall it to trusted management addresses. Use a VPN or access proxy for remote administration rather than a public port-forward.

Register the Hub without exposing the farm hash

Hiveon documents registration through the local web interface or hubctl using the farm hash. Obtain it from the intended farm settings, register once and remove it from shell history or temporary notes where practical.

Confirm the Hub appears in the correct account before scanning miners. Give staff individual Hiveon accounts and the minimum farm role needed. Enable the account security and recovery controls available at the time.

If the farm or legal operator changes, use a controlled transfer rather than sharing the original account. Record who can modify flight sheets, wallet destinations, firmware and power actions.

Discover a small group of ASICs

ASIC Hub can add miners by IP, CIDR range, IP range or CSV according to the current guide. Begin with one or two known devices rather than scanning every local network. Confirm model, IP, MAC address and credentials before registration.

Use DHCP reservations or documented static addressing. Hiveon notes that its ARP scanner can track dynamic IP changes by MAC address, while static fleets can disable scanning to reduce router load. Some older miners may not expose a persistent MAC, so test the actual model.

CSV files can contain administration credentials. Store and destroy temporary import files securely and never email them in plain text. Prefer unique device or group credentials over one default password across the entire fleet.

Create and verify the flight sheet

A flight sheet can define the coin, wallet or account, pool endpoints and miner configuration supported by the integration. Obtain every pool hostname, port, worker format and password from the provider’s current documentation.

Verify the payout address or account independently and use deliberate priority for primary and failover pools. A backup endpoint under the same provider can help with regional failure but is not necessarily independent of the provider.

Apply the sheet to one test miner. Confirm the local interface shows the expected pool and the pool receives accepted shares under the intended worker. Only then copy it to a wider group.

Configure monitoring, alerts and scale

Decide which values matter: online state, accepted hashrate, temperature, fan, board detection, rejects and pool connectivity. Set thresholds from the exact model and normal baseline rather than a universal temperature or hashrate value.

Hiveon documents collection and submission intervals, connection timeouts and group sizing in the Hub configuration. Large fleets need capacity testing; setting an aggressive interval can overload the Hub, network or miners and create false offline states.

Send alerts to a monitored route and define an owner and response. An alert that no one acknowledges is only additional data. Separate a Hub-to-cloud API problem from an actual miner outage by checking local reachability and pool acceptance.

Secure updates, control actions and logs

Use the stable Hub update channel for production unless a documented beta fix is needed. Record the version, release notes, backup and rollback path. Updating the Hub should not silently authorise firmware changes on the miners.

Restrict bulk pool, reboot, power and firmware operations. Use a change ticket or at least a written approval with target group, expected outcome, stop condition and rollback. One incorrect fleet-wide action can interrupt every worker at once.

Hiveon documents the Hub log path and downloadable log. Retain enough history for incident diagnosis without exposing passwords, farm hashes or customer data. Protect logs from ordinary users who could erase evidence.

Test failure and recovery

  • Stop the Hub service and confirm miners continue their configured pool work.
  • Change one test miner’s IP and verify the chosen discovery method behaves as expected.
  • Revoke a Hiveon user and confirm access ends.
  • Restore the Hub configuration and local-state backup on a test host.
  • Test pool failover and return without changing the payout destination.
  • Simulate an API outage and distinguish it from a real miner fault.
  • Confirm local administration remains available if the cloud dashboard is unavailable.

Do not treat the dashboard as the only source of truth. Reconcile local miner state, pool accepted hashrate and electrical or hosting records.

When HiveOS ASIC configuration makes sense

A suitable deployment

ASIC Hub makes sense for a supported mixed or stock-firmware fleet that needs consolidated monitoring and controlled flight sheets without flashing every miner. The site must be able to maintain the Hub host and network boundary.

Scale only after a representative group has proven credentials, discovery, reporting and recovery.

Reasons not to deploy

Do not deploy when the model is unsupported, miner interfaces must be exposed publicly, the farm account has no recovery owner or the organisation cannot protect the fleet credentials held by the Hub.

A local dashboard may be safer and simpler for one or two miners if central control adds no operational value.

Common Hiveon OS setup mistakes

  • Following custom-firmware instructions when intending to use ASIC Hub.
  • Pasting the farm hash into public scripts or screenshots.
  • Scanning a broad business network instead of the miner segment.
  • Importing default credentials for every ASIC.
  • Applying an untested flight sheet to the full fleet.
  • Treating a cloud offline alert as proof the miner stopped hashing.
  • Leaving the Hub web interface exposed to the internet.

Frequently asked questions

Does ASIC Hub install firmware on my miner?

Hiveon documents ASIC Hub as separate bridge software that monitors and controls supported stock-firmware miners without replacing their firmware.

Where should ASIC Hub run?

On a maintained local Linux or Windows host that can reach the miner segment and Hiveon services, protected from public access.

What is a Hiveon farm hash?

It is the registration value that associates a Hub or worker with a farm. Treat it as a credential and do not publish it.

Can ASIC Hub find miners with changing IP addresses?

Its ARP scanner can track supported devices by MAC address, but static addressing or DHCP reservations are often clearer. Test the actual model.

Will miners stop if the Hub fails?

They should normally continue their last pool configuration, but monitoring and control stop. Test this on your deployment.

Should I use stable or beta updates?

Use stable for production unless a specific documented fix justifies beta risk and a rollback is ready.

Conclusion

A dependable HiveOS ASIC configuration begins with the right integration route, a protected farm account, a segmented Hub host and a small test group. Verify pool acceptance and wallet values before bulk flight sheets, then capacity-test monitoring and rehearse cloud, Hub and network failure. Central management is valuable only when it reduces operational risk without creating an unprotected fleet-wide control point.

Next steps

Review The Mining Shop UK’s miner security, remote access and hosting guidance before centralising a fleet, and ask for support if you need to match Hiveon OS management to a specific ASIC model or facility.

Conclusion: HiveOS ASIC configuration

Choose ASIC Hub when you need central monitoring without replacing supported miners' firmware; custom Hiveon firmware is a separate route with different warranty and recovery questions. Install the Hub from the current official source on a maintained local host, restrict its web interface and protect the farm hash and miner credentials.

Sources and further reading

On this page

Search More Guides

Continue Reading

Explore more practical guidance on ASIC hardware, profitability, setup, hosting and maintenance.

Need Advice for Your Mining Setup?

Use our guidance to build your shortlist, then speak to our team when you want help comparing hardware, power, hosting or repairs.
Contact our team
Browse ASIC miners