Awesome Miner Setup Guide: Managing an ASIC Fleet

Running a handful of ASICs by visiting each web interface stops scaling fast. Once a site holds ten or twenty units, operators need a single pane of glass that polls every machine, surfaces dead hashboards, and pushes pool changes in bulk. An Awesome Miner setup gives Windows and Linux operators that console without a per-rig subscription, and it speaks to most ASIC firmware out of the box. This guide walks through installation, adding miners, pool groups, alerting, and the dashboard habits that keep a small farm visible. It assumes familiarity with static IPs and pool credentials.

What does Awesome Miner do for an ASIC fleet?

Awesome Miner is fleet-management software that discovers, monitors, and controls ASIC and GPU miners from one interface. For ASIC operators it reads the miner API (CGMiner-style or vendor-specific), reports per-board hashrate, temperature, fan RPM, and pool status, and lets an operator restart, reconfigure, or firmware-flag dozens of units at once. The free tier covers a couple of miners; paid tiers scale by device count. It runs on a Windows host, with a separate remote agent for Linux and a web dashboard for browser access.

The practical value is consolidation. Instead of bookmarking twenty IP addresses, an operator sees one list sorted by hashrate or temperature, with red rows for anything offline. That visibility is the difference between catching a dropped hashboard in minutes versus at the next monthly payout. Awesome Miner is one option among several; the broader category and its trade-offs are covered in the ASIC remote monitoring stack overview.

Installing Awesome Miner on the management host

Pick a host that stays on. A low-power mini-PC or a always-on workstation on the same LAN segment as the miners works best, because discovery relies on scanning the local subnet. Download the installer from the vendor site, run it, and accept the default port for the local web service if browser access is wanted.

On first launch the software asks whether to manage ASIC miners, GPU rigs, or both. Choose ASIC. Set the host’s own network to a static address or a DHCP reservation so saved miner references do not break when the lease changes. For sites with miners on a separate VLAN, confirm the management host can route to that subnet before attempting discovery — the same segmentation principles in the ASIC static IP and firewall configuration guide apply here.

Adding miners and confirming the API connection

There are two ways to populate the fleet: automatic network scan and manual entry. The scan asks for an IP range — for example 192.168.1.1 to 192.168.1.254 — and probes each address for a recognizable miner API. Recognized units appear with model, hashrate, and firmware type pre-filled.

Manual entry suits miners outside the scanned range or behind a known static IP. Enter the IP, select the miner type (Antminer, Avalon, Goldshell, or a generic CGMiner profile), and supply API credentials if the firmware requires them. Stock Bitmain firmware exposes a read-only API by default; custom firmware often gates write actions behind a token. If a unit shows as connected but reports zero hashrate, the API is reachable but the miner is faulted — check the unit directly.

Grouping miners for bulk actions

Create groups by site, by model, or by coin. Groups are how bulk actions stay safe: applying a pool change to the “S21 XP — Site A” group avoids accidentally repointing a Scrypt unit at a SHA-256 pool. Operators running mixed catalogs — say Bitmain SHA-256 units alongside Fluminer Scrypt machines — should group strictly by algorithm at minimum.

Groups also drive how the dashboard reads. A flat list of forty identical model names tells an operator little; the same forty organized into “Rack 1”, “Rack 2”, and “Rack 3” turns the console into a layout map. When a group goes dark together, that points to a shared cause — a circuit, a switch, a PDU — rather than forty coincidental failures. Build the group structure to mirror the physical and electrical layout of the site so a pattern in the data maps to a pattern in the room.

One practical caution applies to credentials. If custom firmware on some units requires an API token for write actions, store those consistently and confirm the group action succeeded rather than assuming it did. A bulk pool change that silently fails on the locked-down units leaves a split fleet, half on the new pool and half on the old, which is harder to spot than a clean failure.

Configuring pools and failover

Awesome Miner stores pool definitions centrally and pushes them to miners or groups. Define each pool once with its stratum URL, worker name pattern, and password, then assign it. A worker-name template that includes the miner name keeps per-rig stats readable on the pool dashboard.

Always configure at least one backup pool. The primary-plus-backup pattern means a stratum outage fails over automatically instead of idling the fleet. The mechanics of ordering and reconnect behavior are covered in the pool failover configuration guide, and they apply identically whether the change is pushed by Awesome Miner or typed into each miner. Latency between the farm and the pool endpoint also matters for stale-share rates; the pool latency and worker URL guide explains how to pick the nearest endpoint.

Alerts, rules, and automated responses

Monitoring without alerting is just a prettier set of tabs. Awesome Miner supports rule-based triggers: notify when hashrate drops below a threshold, when a temperature crosses a ceiling, or when a miner goes unreachable for a set number of polls. Route notifications to email, a webhook, or a messaging integration.

Set thresholds against the model’s rated output, not a flat number. An S21 XP and a Goldshell altcoin box have wildly different nominal hashrates, so a percentage-of-expected rule is more useful than an absolute one. Temperature alerts should sit below the firmware’s own thermal-throttle point so the warning arrives before the miner derates itself. For hot climates, pair these alerts with the planning in the ambient temperature derating guide.

Automated restart rules — use with care

The software can auto-restart a miner that drops below a hashrate floor. This recovers transient faults without a human, but a restart loop on a genuinely failed hashboard masks the underlying problem. Cap automatic restarts at a small count per hour and alert on the cap so a recurring fault is not hidden by automation.

Dashboards and daily monitoring habits

The default dashboard aggregates total fleet hashrate, total power draw if the firmware reports it, and a count of online versus offline units. Pin the views that match how the site is run: a temperature-sorted list for thermal management, a pool-status view for payout questions, a power view for circuit-load awareness.

A workable daily habit is a thirty-second glance at total hashrate against the expected sum, plus a scan for any red rows. Weekly, review the alert log for units that recovered on their own — repeated self-recoveries usually point to a marginal PSU, a loose data cable, or a fan starting to fail. Those patterns feed directly into a maintenance queue.

When Awesome Miner is the right tool — and when it is not

Awesome Miner fits operators who want local control, a one-time or scaling license rather than a recurring per-rig fee, and a Windows-centric stack. It is strong for mixed ASIC-and-GPU fleets and for sites that prefer software running on their own hardware rather than a cloud service.

It is less ideal for operators who want a fully hosted, zero-maintenance cloud dashboard, or who run a single miner where the native web UI is enough. For those, a cloud platform such as the one covered in the Minerstat setup guide may be a better fit. Larger farms often layer Awesome Miner alongside firmware-native tuning; see the fleet management for mining farms guide for how these tools stack. Whatever console an operator chooses, the hardware behind it still has to earn its power bill — the Coin Web Mining catalog lists current-generation units with published efficiency figures.

Remote access and keeping the console reachable

Because Awesome Miner runs on a host inside the network, reaching it from outside the farm needs deliberate setup. The web dashboard can be exposed, but exposing a management console to the open internet is a security risk — anyone who reaches it can potentially reconfigure or stop the fleet. The safer pattern is a VPN into the farm network, so the management host is reachable privately rather than published publicly. The network-segmentation and firewall principles that make this safe are the same ones in the static IP and firewall guide.

Keep the host itself reliable. Awesome Miner only sees the fleet while its host is running, so a host that reboots, sleeps, or loses network leaves the operator blind even though the miners keep hashing. Disable sleep on the host, put it on the same protected power as the network gear, and confirm it restarts cleanly after a power event. A monitoring console that dies during the exact outage an operator most needs to see is worse than no console, because it breeds false confidence.

Back up the configuration. The fleet definitions, pool profiles, groups, and alert rules represent real setup effort, and losing them to a disk failure means rebuilding from scratch. Export the configuration on a schedule and store it off the host. With a backup in hand, a failed management host is a quick rebuild rather than a multi-hour reconstruction of the entire fleet map.

References

• ASIC model specifications and efficiency figures — ASIC Miner Value
• Mining firmware API and monitoring documentation — Braiins
• Antminer API and management notes — Bitmain
• Network hashrate and hashprice data — Hashrate Index