Meshtastic Firmware Updates and Configuration Backups

A controlled procedure for improving remote infrastructure without turning an update into an avoidable site visit.

Do not update merely because a version exists

Firmware updates can fix security, stability, hardware and protocol problems. They can also change defaults, configuration fields, client compatibility and board behavior. A public infrastructure node should be updated for a stated reason, not from reflex. Read release notes, identify whether the change affects the installed hardware or network, and decide whether the benefit justifies the immediate risk.

Remaining permanently on old firmware is not a strategy either. Communities need a review policy: urgent security or serious reliability fixes are accelerated; normal feature releases are tested and deployed in batches; experimental builds remain on bench or explicitly experimental sites.

Back up more than settings

The Meshtastic Python CLI can export a device configuration to YAML using meshtastic --export-config > site-node.yaml, and a compatible configuration can later be applied with meshtastic --configure site-node.yaml. Treat that export as one part of a recovery package, not a magical disk image.

Also record the exact board and hardware revision, regional variant, firmware version, channel plan, administration public keys, antenna, node identity, special modules and any device-specific calibration such as ADC multiplier. Securely preserve channel keys and sensitive details separately from public documentation. A backup that cannot be matched to the correct physical device is a liability.

Protect keys and identity

Configuration exports may contain information that should not be public. Store them in access-controlled storage, keep an offline copy where appropriate and define who can retrieve them. Do not attach raw configuration exports to public map records or issue trackers.

Before restoring a backup to replacement hardware, consider node identity and cryptographic keys. Blindly cloning identity onto two simultaneously active radios can create confusing or unsafe behavior. The replacement procedure should ensure the old unit is offline or deliberately re-identified.

Use a staged update path

Stage	Action	Exit condition
Review	Read release notes and known issues	Clear reason and compatible hardware
Bench	Update equivalent spare hardware	Boot, radio, power and administration verified
Pilot	Update one accessible non-critical site	Stable observation period completed
Batch	Update a limited group	Each node individually verified
Close	Update records and retain rollback material	Known paths and management confirmed

Do not update every backbone node simultaneously. Preserve alternate paths and observers so the community can distinguish a failed update from a wider outage.

Prepare the node before flashing

Confirm the node, board target and current firmware.
Export and label the current configuration.
Capture expected telemetry and known link behavior.
Verify physical or remote recovery access.
Confirm stable power for the update.
Download and retain the tested firmware and tools before visiting the site.
Notify other operators if the node supports an important path.

Use the official flasher and instructions appropriate to the board. Some platforms use web flashing, drag-and-drop UF2 or device-specific tools. Selecting a similarly named but wrong target can leave a device unbootable until physically recovered.

Remote administration is not remote firmware flashing

Meshtastic remote administration can change radio and module configuration through authorized public-key administration on firmware 2.5 and later. That does not mean every board can safely receive and recover from a firmware flash over the LoRa mesh. Plan firmware work according to the board’s supported update path and the actual access available.

Managed Mode blocks ordinary clients from changing configuration. Enable it only after authorized remote administration has been proven end to end. Preserve more than one authorized administrator for important infrastructure, within the supported limit and community security policy.

Verify after updating

A successful boot screen is not acceptance. Confirm the firmware version, region, modem preset, frequency slot, channels, role, hop limit, rebroadcast mode, telemetry intervals, time, position policy and remote administration. Check that the node transmits and receives on known direct or representative paths and that power behavior remains normal.

Observe it through a realistic cycle. Solar nodes need overnight and charging evidence; gateways need backhaul recovery; busy relays need enough time to reveal congestion or resets. Record the result and update the inventory.

Have a rollback decision

Rollback if the update causes repeated resets, radio incompatibility, unacceptable power consumption, broken management or degraded service that cannot be corrected safely. Do not improvise configuration changes indefinitely on a live backbone node. Restore the last known-good tested state or swap in a prepared spare, then diagnose the new version on the bench.