Bitburner scripts, an orchestrator that plays the hacking simulation for you

How the scripts are organised

The collection is presented as a set of scripts for playing Bitburner, hosted on the author's personal GitHub, with the opening line that the best hackers dox themselves.

The structure is the interesting part, because it is a small scheduler rather than a flat set of utilities. There is an entry point called autopilot.js, described as the master orchestrator, and it starts daemon.js, which is the primary hacking script and in turn kicks off several helper scripts. The orchestrator monitors your progress throughout the game and takes special actions when it can.

That layering has a direct consequence for how you use it. Most scripts are primarily designed to be orchestrated by autopilot.js or daemon.js rather than run on their own, so running a helper directly may not do what you expect, because the orchestrator normally starts several instances of the same script with different arguments.

The download mechanism is deliberately unusual and worth understanding before you run anything. Rather than asking you to clone the repository, the README describes opening git-pull.js in a text editor from the terminal, copying its contents, and running it once to download the rest of the files. The README is candid that many of the downloaded scripts will be useless early in the game because they are only enabled by late-game features, and that they should not cause many problems just by being there.

That last point is the design. The scripts are versioned on the remote rather than in a local checkout, so a player updates by running the pull script again and gets the current set, which means the collection is expected to change as the game does.

Running scripts, arguments and the help flag

Scripts are run with the game's run command, and each one takes arguments to tweak its behaviour based on your preferences or the situation. The README recommends running them with the --help flag, which lists the arguments, the default values and a brief description of each. There is also an error version of that dialog if you make a mistake in how you invoke a script, which is a friendly touch for a tool people run with long argument lists.

Some scripts are meant to be run manually as needed, and the README gives a rough order in which you would experiment with them. scan.js shows the entire server network and important information about each server, described as a nicer replacement for the built-in scan and scan-analyze commands, with support for unlimited depth. git-pull.js is the one you already ran to download everything, and you run it again whenever you want to update.

The individual scripts are worth skimming because their names describe what they do. casino.js plays blackjack and reloads the game if it loses, which the README calls automated save-scumming, and once you win ten billion you cannot enter the casino again, which the README suggests is a good way to boost progress past the two hundred thousand needed to travel to Aevum. reserve.js reserves a set amount of money across all scripts, for example run reserve.js 200k, so that a goal is guaranteed rather than hoping the scripts cooperate.

The more advanced ones carry a requirement in their name, SF4 or SF9, meaning Source File 4 or Source File 9, the game's difficulty tiers. faction-manager.js reports how many augmentations you can currently afford and can purchase them with the --purchase flag. ascend.js is described as a nearly fully automated way to ascend, handling the steps before and after installing augmentations and resetting. farm-intelligence.js executes one or more of the best known methods for farming intelligence experience, with a note that the current best method works best if you delete all other scripts first.

The helpers are the ones you will use most. kill-all-scripts.js stops everything running on home and remote servers and removes the files copied out to remote servers. cleanup.js clears the temp folder, which the README notes contains hundreds of miniature scripts generated by the main scripts, and is useful for reducing save file size before exporting. grep.js searches one or all files for a string, which is how you find out what is spending your hacknet hashes. run-command.js evaluates a piece of code from the terminal, and the README suggests making an alias for it so you can type short commands and get output.

Configuration files and the update model

The README explains how to change a script's defaults permanently without losing the ability to pull the latest version, and the answer is a custom config.txt file for the script. The link in the README points at the configuration files section of the README itself.

The reasoning behind that is the key point. Because the scripts are pulled from a remote repository, anything you changed locally would be overwritten on the next update. A separate config file is the escape hatch: the script reads its settings from a file you own, so the update can replace the script without replacing your preferences.

The note about autopilot and daemon is specific and worth following. They will already run many instances of scripts with default arguments, so if you want to run a script with your own arguments you must either kill the default version first, or run your version before starting daemon.js. The reason is that daemon.js only starts scripts that are not already running, regardless of the arguments of the instance that is running. So the order of operations determines the configuration you get.

There is a file called reserve.txt in the repository root next to reserve.js, which is a small example of the pattern: a configuration file sitting alongside the script that reads it.

The repository top level shows the shape of the collection. There are about forty scripts directly in the root, including the orchestrators, the economy scripts such as stockmaster.js and sleeve.js, the combat and infiltration scripts such as bladeburner.js and gangs.js, and the analysis helpers such as analyze-hack.js, dev-console.js and dump-ns-namespace.js. Then there are two directories, Remote/ and Tasks/, plus a .github directory, a .gitattributes file, a .gitignore file, the LICENSE and the README. There is also optimize-stanek.js.og.js sitting next to optimize-stanek.js, which looks like a kept copy of an earlier version of that script.

The MIT licence and the JavaScript primary language are both unsurprising for a collection of in-game automation, and the last push was on 2026-05-04 with no GitHub releases, so the version record is the commit history.

What this is useful for, and the honest caveats

The reason to use a collection like this is time. Bitburner is a game about building an infrastructure and an income stream, and the systems are slow enough that a session optimised by hand takes a lot of waiting. The scripts remove the waiting and, more importantly, remove the bookkeeping: keeping a money reserve, buying servers with enough RAM, spending hashes on the right upgrades, and reaching an ascension point before the game resets.

Several of the scripts also solve specific mechanical problems rather than just grinding. casino.js turns a slow early-game grind into a blackjack run. ascend.js handles the sequence of steps around installing augmentations, which is fiddly and easy to get wrong on a first attempt. cleanup.js reduces save file size, which matters if you export and re-import saves.

The caveats are about trust and about what you lose. The scripts are JavaScript running inside the game's runtime, and they act on your save, so you are running code you did not write against a file you care about. The README mitigates this by keeping the scripts in a public repository where changes are visible, and by using the config file pattern so updates do not clobber your settings, but the honest position is that a pull script that rewrites your working directory is a supply chain decision, and reading the diff before running it is the reasonable habit.

The second caveat is that automation removes the game. If you play Bitburner to enjoy making the decisions about what to build and when to spend, handing that to an orchestrator leaves you watching a progress bar. The README's framing is that these scripts play the game for you, more or less, which is a cheerful way of saying the same thing.

The third is that the collection is tied to the game's current mechanics. The SF4 and SF9 requirements, the mention of unlockable features, and the note that the best farming method may change all point to scripts that need periodic updating as the game changes, which is exactly why the design pushes everything through a remote pull rather than a local clone.

Editorial conclusion

Adopt these scripts if you play Bitburner and want the automation handled for you rather than by hand, and you are comfortable running a script collection that overwrites its own configuration. Skip it if you want to learn the game by playing it, since the automation removes the decisions that make it a game. Verify first by reading autopilot.js and daemon.js before running them, and note that the first pull fetches the rest of the collection, so start by downloading git-pull.js and reading it.

Frequently asked questions

Official sources

1. alainbryden/bitburner-scripts on GitHub
2. Issues
3. License: MIT
4. README