🖥️ Droid Reboot

A full-fleet automation toolkit for Bitburner, the cyberpunk programming game.

Play in the browser · Get it on Steam · Official game source · Current documentation · NS API

Droid Reboot is a Bitburner 3.x automation toolkit built around one adaptive hacking controller. It discovers and roots the network, selects a money target, prepares it, and uses the rooted fleet for either early-game loop hacking or overlapping HWGW batches. A supervisor can also run the dashboard and unlocked side-system managers without letting them consume the RAM reserved for hacking.

The project is self-contained. It does not require Formulas.exe, an external framework, or the old /TheDroid/Manager-Startup.js layout.

This repository began as the original /TheDroid/ manager collection. Droid Reboot is its modern successor: the familiar discover, root, select, deploy, and hack workflow has been rebuilt for current Bitburner APIs, explicit RAM ownership, timed HWGW batching, and independently supervised side systems. Returning users should follow the new root-level install and start commands below; the archived Manager-Startup.js instructions no longer apply.

Install or update from GitHub

Run these commands in the Bitburner Terminal on home:

wget https://raw.githubusercontent.com/TheDroidYourLookingFor/BitBurner-Scripts/main/InstallDroidScripts.js /InstallDroidScripts.js
run /InstallDroidScripts.js

The installer downloads every JavaScript file in this repository and preserves the directory layout expected by the scripts:

/
├── droid-*.js
├── ServerExplorer.js
├── lib/
├── workers/
└── examples/

Downloads are staged and checked before any live script is replaced. Once every file is available, the installer stops running Droid processes on the normal network, writes the new files, cleans its temporary downloads, and optionally removes the obsolete /TheDroid/ installation after confirmation. Generated state files and saved Darknet credentials are not part of the install manifest and are left alone.

When the Terminal UI is available, the installer also creates a global shortcut:

Droid

That shortcut is equivalent to run /droid-start.js. If alias creation is unavailable, use the full command. The installer never restarts automation automatically after an update.

Useful installer options:

run /InstallDroidScripts.js --keep-legacy
run /InstallDroidScripts.js --no-alias
run /InstallDroidScripts.js --base-url https://raw.githubusercontent.com/USER/REPOSITORY/BRANCH/

The default URL assumes this project is published to the main branch of TheDroidYourLookingFor/BitBurner-Scripts.

Quick start

Start the full default setup:

run /droid-start.js

The supervisor starts the hacking controller, the status dashboard, the custom Overview HUD, and any safe manager whose API is currently unlocked. Managers that cannot fit beside the active hacking stage are deferred and retried later.

Stop everything owned by the toolkit across the rooted network:

run /droid-stop.js

Open or refresh the live dashboard manually:

run /droid-status.js
run /droid-status.js --once
run /droid-status.js --all

How the controller works

droid-start.js
└── droid-autopilot.js
    ├── droid-daemon.js
    │   └── droid-root.js
    │       ├── droid-loop.js                    fresh/low-RAM fleet
    │       └── droid-prep.js → droid-batch.js   prepared HWGW pipeline
    ├── droid-status.js + droid-custom-stats.js
    ├── unlocked safe managers
    └── droid-xp-launcher.js → droid-xp.js       optional XP share

Only one main work stage runs at a time. The daemon keeps discovery and rooting alive, while the active stage distributes workers over home and rooted RAM servers. Worker files have no imports, so copying and executing them remotely stays cheap.

In auto mode, a usable rooted fleet below 128 GB runs simple hack/grow/weaken loops. At 128 GB or more, the daemon prepares the selected target and hands it to the continuous JIT batch controller. Preparation uses overlapping weaken/grow/weaken waves; batching schedules overlapping HWGW jobs with explicit timing and only launches complete money batches.

Target selection favors expected money per RAM-second. A running batch controller keeps its selected target so a routine score change does not throw away an already-warmed pipeline. Restarting Droid performs a fresh selection.

The local formula module implements the source-style grow inverse, including additive growth money and security caps. Batch planning therefore does not require the in-game Formulas.exe purchase.

Start modes and important options

Option	Behavior
--mode auto	Uses loop hacking below 128 GB of usable rooted RAM, then preparation and HWGW batching. This is the default.
--mode loop	Forces the low-RAM continuous worker loops.
--mode batch	Forces preparation followed by HWGW batching.
--mode xp	Runs the XP system as the primary workload and uses the full usable fleet by default.
--target HOST	Requests a specific valid money target instead of automatic selection.
--hack-percent 0.1	Caps the fraction stolen by each money batch.
--no-home	Keeps hacking, prep, batch, and XP workers off home; controllers still need somewhere to run.
--no-managers	Skips optional side managers. The status dashboard and custom HUD still run.
--no-stock	Disables only the stock manager.
--personal	Allows the idle-only crime manager to be supervised when Singularity is available.

Examples:

run /droid-start.js --mode loop
run /droid-start.js --mode batch --target n00dles
run /droid-start.js --mode batch --hack-percent 0.05
run /droid-start.js --mode batch --no-home
run /droid-start.js --no-managers

Run run /droid-start.js --help for the complete start-command syntax.

RAM and money reserves

Home RAM and cash are separate budgets:

run /droid-start.js --ram-reserve 32G --money-reserve 10m

• --ram-reserve accepts bare GB values or G, GB, T, and TB suffixes. The value is stored in /droid-ram-reserve.txt, and every Droid allocator honors it.
• --money-reserve accepts compact cash values such as 500k, 10m, 2b, and 1t. The supervisor publishes it to /reserve.txt for the spending managers.
• --reserve 32G remains a compatibility shorthand for RAM because it has a RAM suffix. A value such as --reserve 10m is treated as cash. Prefer the explicit flags when configuring both.
• --manager-reserve 4 controls the minimum home RAM kept between optional manager launches. The supervisor also protects enough space for the largest current work stage.

Set --ram-reserve 0 to clear the persisted home reserve.

Cooperative XP mode

Add an XP sidecar without surrendering the main money target:

run /droid-start.js --mode batch --xp
run /droid-start.js --mode batch --xp --xp-percent 20%

The default cooperative share is 10%. --xp-percent accepts 0.2, 20, or 20%. The XP manager prefers n00dles, avoids the active money target, and uses a rolling queue of small H/W/G/W units. Each process is capped at 128 threads, and the queue can retain successfully launched partial work instead of discarding an entire cycle.

The scheduler needs a 32 GB RAM allocation. droid-xp-launcher.js places it on a stable rooted server when home is too small and mirrors its state back to home for the dashboard. Use --xp-target HOST to request another XP target.

Automatically supervised managers

The default supervisor starts these only when their APIs are available and enough RAM remains:

Script	Responsibility	Unlock or condition
droid-programs.js	Buys TOR and missing port-opening programs while protecting the cash reserve.	Singularity
droid-cloud.js	Purchases and upgrades Bitburner 3.x cloud servers.	Cloud-server API
droid-hashnet.js	Spends hashes and buys production-aware Hacknet upgrades.	Hacknet/Hashnet API
droid-hacknet.js	Conservative node upgrader used as a compatibility fallback.	Hacknet API
droid-contracts.js	Scans rooted hosts and solves supported coding contracts.	Coding Contract API
droid-backdoors.js	Installs eligible backdoors and skips w0r1d_d43m0n by default.	Singularity
droid-gangs.js	Recruits, trains, ascends, equips, and assigns gang members.	Active gang
droid-stock.js	Runs a long-only portfolio using history before 4S and forecasts after 4S.	TIX API; disable with --no-stock

droid-status.js and droid-custom-stats.js are part of the normal interface and start even when optional managers are disabled. The status tail reports target state, rooted capacity, active servers and threads, earnings and XP rates, batch depth, HWGW thread totals, and the next scheduled event. The custom stats script writes a compact, sectioned Overview HUD.

The stock manager opens its own live dashboard beside the main status panel. Start it manually with --no-tail if you want it to run headlessly:

run /droid-stock.js --no-tail
run /droid-stock.js --once

Opt-in player automation

These scripts are installed but are not part of the default supervisor because they take over player activity or make unusually consequential changes:

run /droid-crime.js --mode karma --fast-crimes-only
run /droid-gym.js --stat strength --goal 100 --reserve 1m
run /droid-faction.js --factions Netburners,CyberSec --rep-goal 12500
run /droid-casino.js
run /droid-darknet.js

• droid-crime.js optimizes expected money, karma, or kills. The supervised --personal form runs only while the player is idle.
• droid-gym.js trains one configured combat stat and protects a cash reserve.
• droid-faction.js works only the explicitly listed factions and can optionally target or purchase selected augmentations.
• droid-casino.js automates blackjack at Iker Molina Casino. It uses advanced strategy, saves new winning peaks, and can reload after configured losses; --no-save-scum makes losses permanent.
• droid-darknet.js explores the Bitburner 3.x Darknet, authenticates known server models, collects cache data, and launches bounded phishing workers.

Use each script's --help option for its full command line.

Darknet safety

Darknet automation is deliberately manual. By default it reuses credentials from /droid-darknet-passwords.txt, searches local clues for additional credentials, traverses Labyrinth servers, and sleeps on topology mutations when that API is available. The home controller owns the dashboard; copied controllers and phishing workers remain headless.

These actions are opt-in because they change more of the Darknet state:

• --stasis protects deployed servers.
• --migrate induces movement on eligible neighbors.
• --promote-stock FOO,BAR runs stock propaganda.
• --storm-seed executes STORM_SEED.exe and can catastrophically mutate the Darknet.

Use --no-phish for exploration and cache collection only, --no-labyrinth to leave Labyrinth puzzles manual, or --once for a single discovery pass.

Server tools

Graphical explorer

run /ServerExplorer.js
run /ServerExplorer.js --sort name

ServerExplorer.js opens a draggable, resizable native network window with routes, requirements, root state, backdoor state, search, sorting, and per-host actions. Rooting uses the port programs currently on home. Connect and Backdoor actions use the Terminal bridge instead of Singularity, so keep the Terminal page open while clicking them. The w0r1d_d43m0n Backdoor action stays disabled unless the explorer is launched with --allow-world-daemon.

Server snapshot

run /droid-poll-server.js n00dles

This prints access, RAM, timing, money, security, thread estimates, and the controller's target score for one server.

Standalone maintenance commands

run /droid-root.js --root-only
run /droid-prep.js n00dles
run /droid-cloud.js --budget 0.2 --utilization-trigger 0.8 --once
run /droid-hashnet.js --once
run /droid-contracts.js --once
run /droid-backdoors.js --once

Normally the daemon and supervisor own these jobs. Standalone commands are useful for testing or one-off maintenance; avoid running a second copy against an active controller unless the script is explicitly designed for it.

Repository map

Entry points and orchestration

• InstallDroidScripts.js — staged GitHub installer and updater.
• droid-start.js — primary launcher; validates home RAM and starts the supervisor.
• droid-autopilot.js — restarts the daemon, interface, XP sidecar, and unlocked managers.
• droid-daemon.js — persistent low-RAM stage controller.
• droid-deploy.js — lightweight compatibility entry point for the daemon.
• droid-root.js — network scan, rooting pass, target choice, and mode handoff.
• droid-loop.js — low-RAM continuous hacking stage.
• droid-prep.js — target preparation and handoff to batching.
• droid-batch.js — persistent JIT HWGW controller.
• droid-xp-launcher.js / droid-xp.js — remote-capable XP scheduler and rolling queue.
• droid-stop.js — stops toolkit controllers, managers, and workers across the network.

Interface and optional systems

• droid-status.js — live operational dashboard.
• droid-custom-stats.js — custom Overview HUD.
• droid-poll-server.js — one-server diagnostic snapshot.
• ServerExplorer.js — standalone graphical network explorer.
• droid-cloud.js, droid-programs.js, droid-backdoors.js — infrastructure and progression.
• droid-hashnet.js, droid-hacknet.js, droid-stock.js — investment managers.
• droid-contracts.js, droid-gangs.js — unlocked side systems.
• droid-crime.js, droid-gym.js, droid-faction.js — opt-in player activity.
• droid-casino.js, droid-darknet.js — specialized opt-in automation.

Libraries and workers

• lib/common.js — paths, constants, formatting, reserves, process ownership, and dashboard state.
• lib/network.js / lib/root-network.js — network discovery, rooting, routes, and target scoring.
• lib/allocator.js — free-RAM accounting, synchronized remote copies, and distributed execution.
• lib/formulas.js — local grow and security formulas.
• lib/batcher-v3.js — active batch planner and JIT executor.
• lib/batcher.js — previous planner retained for compatibility and comparison; the active controller imports batcher-v3.js.
• workers/hack.js, grow.js, weaken.js — delayed money-batch operations.
• workers/hack-loop.js, grow-loop.js, weaken-loop.js — continuous low-RAM operations.
• workers/xp-hack.js, xp-grow.js, xp-weaken.js — delayed XP operations.

The examples/ram-dodge.js pair demonstrates a dynamic-import controller with an explicit ns.ramOverride(). It is educational and is not used by Droid Reboot itself.

Generated files

The toolkit may create these files on home; they are runtime state, not repository assets:

• /droid-dashboard.txt
• /droid-autopilot-state.txt
• /droid-xp-state.txt
• /droid-target-handoff.txt
• /droid-ram-reserve.txt
• /reserve.txt
• /droid-darknet-passwords.txt

Reinstalling does not overwrite them. droid-stop.js removes transient dashboard state but preserves reserve settings and Darknet credentials.

Local development and syncing

NetscriptDefinitions.d.ts, NetscriptGlobals.d.ts, and tsconfig.json provide local JavaScript type checking. They are development files and are not copied into Bitburner by the installer.

The workspace works with the Bitburner File Sync VS Code extension. Edits made outside VS Code do not trigger its save hook, so after an external edit open the Command Palette (Ctrl+Shift+P) and run Bitburner: Sync All Files. Preserve the repository's root, lib, workers, and examples paths because the scripts use absolute imports.

Troubleshooting

• A module is missing: rerun the installer and confirm all files report as staged. Do not flatten lib/ or workers/.
• Droid says it is already running: use run /droid-stop.js, then start it again.
• A stage will not launch: lower --ram-reserve, use --no-managers, or wait for more home/rooted RAM. Batch preparation requires more controller RAM than loop mode.
• An optional manager does not start: its API may still be locked, its game system may be inactive, or the supervisor may be protecting RAM for the main stage.
• An update appears stale on remote hosts: rerun the installer, then restart Droid. The allocator refreshes remote worker copies before launching new jobs.
• Explorer Connect/Backdoor buttons do nothing: switch to the Terminal page before using them.

Run --help on the relevant entry point before changing advanced defaults.

Community and resources

• Official Bitburner documentation — current guides and game mechanics.
• Netscript API reference — generated API definitions for script development.
• Official Bitburner Discord — game help and development discussion.
• Bitburner subreddit — community scripts, questions, and discussion.
• TeemoPewPew on Twitch — the original project author's channel.

Credits and contributing

This repository preserves the ideas and work that grew out of the original Droid scripts while replacing the old framework with the current implementation. Some techniques were inspired by Bitburner's documentation, wiki, source code, and community scripts; credit belongs to the authors who developed and shared those ideas.

Contributions are welcome. Fork the repository and submit a pull request for fixes or additions, or open an issue for bugs, questions, feedback, and help. For a useful bug report, include the Bitburner version, launch command, selected mode, relevant dashboard or Terminal output, and whether the problem survives a clean stop and restart.