AxeOS Dashboard Guide for Bitaxe and NerdQaxe

This AxeOS dashboard guide explains the web interface supplied by the open-source ESP-Miner firmware used across supported Bitaxe-family hardware and some compatible designs. It covers safe local access, pool and wallet settings, hashrate, shares, power, temperature, logs, updates and recovery. Exact fields vary by board and firmware release. So identify the hardware version first and use only a matching official image.

Understand what AxeOS controls

ESP-Miner is open-source firmware for ESP32-controlled Bitcoin ASIC hardware. Its web interface is called AxeOS. The official project exposes system information, ASIC settings, statistics, scoreboard, Wi-Fi scanning, logs, restart, pause, resume, firmware update and pool configuration through its interface and API.

AxeOS does not turn the device into a general-purpose miner. The ASIC chip still performs its fixed algorithm, normally SHA-256 for Bitcoin-oriented Bitaxe hardware. The interface controls how that hardware connects and operates.

NerdQaxe and other derivatives can differ in ASIC count, board sensors, power stages, cooling and supported builds. Confirm that the vendor points to the official or audited compatible firmware path.

Identify the board before setup

Record the product name, board family, revision, ASIC model, serial or MAC address, power supply rating and installed firmware version. Do not choose an image from the product nickname alone.

The ESP-Miner factory-flashing tool requires a firmware image matched to the hardware version. A configuration file can overwrite settings baked into the image. So inspect it before combining a factory image and configuration.

Connect on a trusted local network

After network connection, access the local IP address or the device’s mDNS hostname where supported. The official project documents a default hostname of bitaxe and advertises the HTTP service on port 80.

Do not forward that port from the public internet. Put mining devices on a separate network from customer, payment and office systems. Use a secured VPN for remote access rather than exposing the dashboard.

Give each unit a clear unique hostname and a DHCP reservation or documented address. Current ESP-Miner releases can resolve hostname conflicts by adding a MAC-derived suffix. But an asset record remains useful.

Configure the pool and payout identity

get the Stratum hostname, port, username or payout address, worker format, password field and security options from the pool’s current documentation. Do not copy an address from a video or seller screenshot.

ESP-Miner’s current API supports multiple pool slots and both documented Stratum V1 and Stratum V2 configuration fields. Available options depend on release and pool support. A protocol label is not proof that the endpoint, authority key or channel settings are correct.

After saving, confirm the dashboard connects and the pool account receives accepted shares under the intended worker. Test failover deliberately, then return to the primary endpoint.

Read hashrate and shares correctly

The live hashrate tile estimates work locally and can move rapidly. Pool effective hashrate is inferred from accepted shares and needs a longer period, particularly for a small miner with infrequent shares.

Use accepted share count, best share or scoreboard, pool credit and uptime together. A high best share is interesting but does not guarantee a future block. Solo mining remains probabilistic.

If local hashrate is normal but the pool receives nothing, recheck endpoint, port, payout identity, DNS, network and device time before changing voltage.

Monitor temperature, fan and power

Observe ASIC temperature, voltage, frequency, fan response and any power reading available for the board. Establish the normal values at the stock profile in the actual room before tuning.

Use the power supply specified for the hardware and connector. Undervoltage, an inadequate supply or loose connection can appear as hashrate instability. Power down before inspecting wiring and avoid touching exposed components during operation.

A dashboard temperature is one sensor, not a complete thermal survey. Check heatsink contact, airflow, dust and ambient temperature. Stop if the board shows repeated thermal shutdown, visible damage or an abnormal smell.

Treat overclock controls as an engineering change

The official ESP-Miner documentation states that frequency and ASIC core-voltage fields can be unlocked with an oc query option and warns that overclocking without extra cooling can overheat or damage a Bitaxe.

Change one parameter in a small step, allow the miner to stabilise and record accepted hashrate, errors, temperature and wall power. A higher local hashrate is not an improvement if efficiency, rejects or stability deteriorate.

Keep a known-good stock profile and respect vendor warranty. Some sellers may exclude damage or instability caused by tuning even though the firmware is open source.

Update firmware and AxeOS safely

Use the official ESP-Miner release page or a vendor’s documented compatible release. Read release notes for supported hardware, migrations and known issues. Back up pool and network settings without publishing credentials.

Current unified firmware embeds the AxeOS frontend in the main firmware image. The project warns that rolling back to older pre-unified firmware can leave an incompatible web partition, producing layout errors until a matching web image is restored.

Keep stable power during an update, wait for completion and do not refresh repeatedly. Afterward verify board identity, pool destination, hashrate, temperature and accepted shares before applying the release elsewhere.

Recover an inaccessible dashboard

First confirm power, network link, DHCP lease, hostname and IP. Try the documented recovery page at the device IP followed by /recovery when an unsuccessful custom web-interface update has hidden normal administration.

If factory flashing is required, use the official bitaxetool guidance and the exact hardware image. Record the installed state first and isolate the unit from the production pool during recovery.

Do not flash random binaries or use credentials embedded in a public configuration file. If the board, power stage or USB connection behaves abnormally, stop and get model-specific repair help.

Use logs and the API with care

ESP-Miner exposes downloadable logs, statistics and WebSocket data, plus actions such as restart and configuration change. These are useful for fleet monitoring but also expand the control surface.

Allow API access only from trusted management hosts. Do not place payout data, Wi-Fi credentials or unrestricted control endpoints into a public dashboard. Protect any third-party collector and retain versioned configuration.

When diagnosing, export logs before restarting. Remove credentials and network details before sharing them with support or a public issue tracker.

Common AxeOS mistakes

• Flashing by product nickname instead of exact board revision.
• Exposing the local dashboard directly to the internet.
• Entering an unverified pool username or payout address.
• Judging performance from a few minutes of hashrate.
• Increasing frequency and voltage together without a baseline.
• Updating production devices before testing one unit.
• Rolling back unified firmware without checking web-partition compatibility.
• Posting unredacted logs or configuration publicly.

Key points to remember

AxeOS is most useful when it turns a small open-source miner into a measurable, controlled device rather than a tuning experiment. Identify the exact board, secure local access, verify the pool and payout identity and establish a stock baseline.

Update from the official release, change one operating variable at a time and preserve a recovery path. The pool’s accepted work and stable temperature matter more than a brief dashboard peak.

Next steps

Use The Mining Shop UK’s security, pool and profitability guidance alongside the current ESP-Miner documentation, or send the exact board revision, firmware version and redacted logs when you need help separating configuration from hardware failure.