Change admin password
Admin & client
Setting the client version writes it into the build; a client rebuild + restart is needed for it to take effect. "Stop all clients" sends a stop to every currently-running client across all PCs.
Hooks update
Rebuilds the client against the newest RuneLite hooks on the build PC, then verifies by launching a test client to the login screen (no account, no ban risk). "Publish" only appears once it verifies. The fleet stays on the current build until you publish.
Downloads
Installer = new PC (bundles Java). launcher.jar = drop-in replacement of the launcher on a PC that already has Crimson (e.g. to fix a bad update). Both are always the current build. Share the login link, not the files. Script SDK = the DreamBot API jar, reference, template script and publish.ps1 for script developers (the launcher also puts it in C:\DBCrimson\sdk).
Your Farm Manager
Your Farm Manager runs locally on your own PC — your accounts, proxies and sessions are stored only there (AES-encrypted) and never touch this server. Start it from the Crimson Launcher (Farm Manager button) on this PC, then open it:
It runs on localhost:9077 on this PC. If nothing opens, start it from the Crimson Launcher (Farm Manager button) first.
Export this Farm Manager
Downloads one file with everything another Farm Manager needs: every account (login, 2FA key, bank PIN, saved Jagex session, DreamBot profile, category, notes, stats), every proxy, account and proxy categories, and schedules. PCs are not carried over — they belong to this fleet. The file holds working credentials: keep it private.
Import into this Farm Manager
Pick an export from another Farm Manager (a raw fleet-server.json works too). Merge adds new accounts/proxies and updates ones already here (matched by id, then email / host:port:user). Replace wipes this manager's accounts, proxies, categories and schedules first. Preview first to see the counts; a real import saves a copy of the current data before changing anything.
Fleet overview
By script
Accounts grouped by the script they logged the most activity under, with combined playtime, average humanness, ban count, and XP/hour where captured.
| Script | Accounts | Running | Banned | Total played | Avg humanness | Avg XP/hr |
|---|
Most at risk
Live (not-banned) accounts with the lowest humanness scores — the ones worth checking first.
| Account | Script | Humanness | Unbroken play | Reflection clicks |
|---|
Profit / XP
XP-per-hour is captured from live XP snapshots (added this session). Historical accounts that ran before XP telemetry existed show no value. GP profit is not yet tracked — it needs per-account inventory/GE-value sampling, which can be added next.
| Account | Script | XP gained | XP/hr | Total played |
|---|
Live characters
Live in-game state reported by running fleet clients (~every 20s): what each character is doing, its levels, XP gained + XP/hour, GP, and an XP trend. Launch an account to see it here.
| Character | Script | Activity | World | Combat | Total lvl | XP gained | XP/hr | GP | Trend | Updated |
|---|
PCs
| Label | Status | Last seen |
|---|
Add a PC — agent enrollment keys
Generate a code for another PC (LAN or a remote server) to join THIS Farm Manager's fleet — no central hub needed. On that PC, set the agent's SERVER_URL to this manager's address and FLEET_TOKEN to the code. Revoke a code to cut that PC off.
SERVER_URL= and FLEET_TOKEN=the code above.PC settings — per-PC client loading overrides
Applied to EVERY client launched on the chosen PC, on top of whatever each account saved for itself in its own Client Settings. Leave a field on "No override" / blank to leave that account's own setting alone. Takes effect on that PC's next heartbeat (~5s) + next launch - no restart needed.
Revokes any existing enrollment key(s) for this PC's label and generates a fresh one (shown above, in the Add a PC box) - use when a key leaks or was lost. Has no effect on a PC enrolled with the shared FLEET_TOKEN instead of a key.
Bug reports
Automatic reports (a script failed to start or gave up after repeated errors) and reports sent from the client's Report bug button. The same crash from many accounts is merged into one row with a count. A crash that returns after being marked fixed reopens itself.
| Last seen | Script | Type | Quest / skill / task | Summary | Kind | Count | Reported by | Status |
|---|
Discord Role Access
Access is driven by Discord server roles. The launcher signs testers in with Discord; a member with the Beta role can launch, the Admin role gets full access + this dashboard. Map each role to the SDN scripts & features it may use — a user gets the union of their roles' grants. Add a tester to a Discord role and they inherit its access.
Scripts — availability
The shared script store. Toggle a script off to hide it from every client's SDN (broken / not ready); the admin dashboard still shows it. Per-user script grants are set above.
SDN API keys
Per-machine API keys that let an agent push/update SDN scripts over the API without a browser login — e.g. a script-dev PC that recompiles and uploads jars while you work. Each key is labelled with the PC it belongs to and tracks its own usage. Keys can update the SDN only; they do not unlock accounts, proxies or client launching.
Pulling the most recent script source — how another agent/PC downloads it
This is a different credential from the API keys above — those are for pushing script updates
(see below). To read the SDN catalog and pull the newest compiled jar, use whatever this PC's agent
already has: its shared fleet token (FLEET_TOKEN in its config.bat /
launcher.properties), a per-agent enrollment key from PCs → Add a PC, or a scoped
Discord-login token. Any of those three work in the same X-Fleet-Token header — no SDN API
key needed just to read.
# 1. List everything currently in the SDN - name, size, and last-modified time for each script.
# Compare lastModifiedMillis against what you have locally to know if a newer build is waiting.
curl "/api/sdn/scripts" \
-H "X-Fleet-Token: <FLEET_TOKEN_OR_ENROLLMENT_KEY>"
# 2. Download the current compiled jar for one script by name (always the latest - there is only
# ever one live jar per script name, whatever the most recent push left there).
curl -o "<ScriptName>.jar" \
"/api/sdn/scripts/<ScriptName>/download" \
-H "X-Fleet-Token: <FLEET_TOKEN_OR_ENROLLMENT_KEY>"
# Optional: add ?profileId=<clientProfileId> to #1 to see exactly what that one account is
# allowed to run (per-account script grants), instead of the full catalog.
A running client's own Script Manager does this automatically on every poll - this is only for a separate agent/script-dev machine that wants the latest source/jar without running a full client.
Pushing an update — how to use an API key from an agent / script
Send the key in the X-Fleet-Token header. Upload a compiled jar (recommended — no server-side compile):
curl -X POST "/api/sdn-admin/upload?name=<ScriptName>" -H "X-Fleet-Token: <YOUR_API_KEY>" -H "X-Change-Author: <agent / PC name>" -H "X-Change-Note-B64: $(printf '%s' "$NOTES" | base64 -w0)" --data-binary @<ScriptName>.jar
# FULL CHANGE NOTES ARE REQUIRED on every upload / compile / source push (60+ chars, any caller):
# what was broken, the cause, what you changed (classes/methods), how it was tested, what is left.
# Plain one-line notes can go in X-Change-Note; use X-Change-Note-B64 (base64 UTF-8) for multi-line.
# BEFORE editing a script read what the other agents already did:
curl "/api/sdn-admin/changelog?name=<ScriptName>" -H "X-Fleet-Token: <YOUR_API_KEY>"
# Every push also returns "recentChanges" (the last 5 before yours). History button per script in the panel.
# toggle a script on/off for every client's SDN
curl -X POST "/api/sdn-admin/set-enabled" -H "X-Fleet-Token: <YOUR_API_KEY>" -H "Content-Type: application/json" -d '{"name":"<ScriptName>","enabled":true}'
# compile from a source folder on the server, or delete a script
# POST /api/sdn-admin/compile {"name":"...","src":"C:\path\to\src"}
# POST /api/sdn-admin/delete {"name":"..."}
After a push, restart the running script (Stop/Start) so it reloads the new jar — no client relaunch needed. A push here is exactly what the pull commands above will see as the new "most recent" jar.
Share source with other agents / PCs
Use the central SDN hub at https://dbcrimson.com and an SDN API key allowed to edit the script. Publishing a JAR does not upload its source. Source revisions are separate from Git commits and never run on the server.
Publish the COMPLETE current source for <ScriptName> to the central SDN using your existing SDN API key. Do not substitute an older source version just because it compiles. 0. Read the script's change history first: GET https://dbcrimson.com/api/sdn-admin/changelog?name=<ScriptName> with X-Fleet-Token. It lists every push with the full change notes of whoever made it - build on those fixes, do not undo them. 1. Download GET https://dbcrimson.com/api/sdn-admin/source?name=<ScriptName> with X-Fleet-Token. Check matchesPublishedJar. A 404 means no source has been shared yet: locate the source used for the live build before editing. 2. Download its source ZIP from GET /api/sdn-admin/source/download?name=<ScriptName>. Use &revision=<revision> to retrieve an older revision. GET /api/sdn-admin/source/versions?name=<ScriptName> lists history. 3. Include all Java files, resources and build instructions in the source ZIP. Exclude .git, compiled classes, JARs, caches and credentials. Build the JAR from exactly this source. Preserve other agents' changes and push the source Git commit too when that repository is available. 4. Upload the source ZIP with POST /api/sdn-admin/source?name=<ScriptName>. Headers: X-Fleet-Token: your key; X-Change-Note (or X-Change-Note-B64 for multi-line): FULL change notes - symptom, cause, fix, files, testing, open issues (required, 60+ chars); X-Jar-SHA256: SHA-256 of the matching JAR. Body: raw ZIP bytes. Save the returned revision and sourceSha256. 5. Upload that JAR with POST /api/sdn-admin/upload?name=<ScriptName>, X-Fleet-Token and X-Change-Note, body = raw JAR bytes. Uploads apply to the SDN immediately; do this only after the build and checks pass. 6. Read the source metadata again and verify matchesPublishedJar=true. Download the source ZIP and JAR and compare their hashes to your local files. Report the script version, source revision, Git commit when available, checks run and JAR hash. The user can then Stop/Start the script to load the published build. For CrimsonRedFarm: upload the newest source matching the live CrimsonRedFarm build. The old cCRedFarm 0.2 source is not the newer CrimsonRedFarm 1.1 implementation.
PowerShell example (set SDN_API_KEY privately in your environment):
$hub = 'https://dbcrimson.com'
$name = 'CrimsonRedFarm'
$headers = @{
'X-Fleet-Token' = $env:SDN_API_KEY
# FULL change notes are required (60+ chars): symptom, cause, fix, files, testing, open issues
'X-Change-Note-B64' = [Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes((Get-Content .\CHANGES.txt -Raw)))
'X-Change-Author' = $env:COMPUTERNAME
'X-Jar-SHA256' = (Get-FileHash "$name.jar" -Algorithm SHA256).Hash.ToLowerInvariant()
}
Invoke-RestMethod "$hub/api/sdn-admin/source?name=$name" -Method Post -Headers $headers -ContentType 'application/zip' -InFile "$name-source.zip"
Invoke-RestMethod "$hub/api/sdn-admin/upload?name=$name" -Method Post -Headers $headers -ContentType 'application/java-archive' -InFile "$name.jar"
Invoke-RestMethod "$hub/api/sdn-admin/source?name=$name" -Headers $headers
Detuks bridge
The Detuks P2P bridge is a RuneLite plugin compiled into the client (not an SDN script jar), disabled by default per account. This shows its staged artifact / hash-verification state only — readiness here means the bridge will load correctly, not that anyone has observed its original task loop actually run. Nothing on this tab is uploaded to the public SDN.
Run on an account
Picks an account and launches it with the Detuks bridge instead of its
normal script. Needs a separate JDK 23+ on whichever PC runs it (see the launcher's
detuks.javaHome config) — this will fail clearly if that PC isn't set up for it
yet, rather than silently falling back to a JDK that can't load the bridge.
Import / export accounts
One text file, any of: email:password:otp:bankpin lines (the export format below; otp and bankpin optional), a CSV with an Email column (Password / 2FA_Key / Bank_Pin / Proxy_IP / Proxy_Port optional), or an account creator accounts.json. Logins already on file are not duplicated; a missing password / 2FA key / bank PIN is filled in.
Jagex accounts
One row per account. Click a column heading to sort - combat, total level and XP come
from the last time each account was seen in game. Tick accounts and use the batch bar above to move or launch them.
Click the Login column to copy that account's email:pass:otp.
| Character / login | Login (click to copy) | Category | Cmb | Total | XP | PC | Proxy | Script | Status | Last active | Actions |
|---|
Advanced: create a character using raw credentials
Use this for a login that isn't imported yet. Same browser-driven flow as above.
Legacy accounts
Old-style Dreambot username/password profiles (RuneLite ConfigProfile), not a real Jagex OAuth/TOTP login.
| Label | PC | Proxy | Category | Script | Data folder | Status |
|---|
Other / pending login
CSV imports awaiting a manual first login, quick-launch test profiles, or anything not yet linked to a Jagex session or Dreambot profile.
| Label | PC | Proxy | Category | Script | Data folder | Status |
|---|
Manage categories
Categories are dashboard-only grouping - they never change how an account launches or which proxy it uses. Deleting a category keeps its accounts and moves them to Uncategorized.
| Category | Accounts | With proxy | No proxy |
|---|
Add / edit account profile
Optional — paste a real credentials.properties to make this a genuine Jagex-account profile (TOTP/2FA satisfied). Obtain one by launching through the official Jagex Launcher once with --insecure-write-credentials and logging in there. Do NOT use the in-client "Log in new Jagex account" button for this.
New job
Run one script (with parameters) across a set of accounts, staggered. Each launch uses the same path as the Launch button — session mint + character import for a stored-creds login — and the script is assigned to the account so it auto-starts once logged in. "Run now" fires immediately; a daily time auto-runs it once a day.
Jobs
| Job | Script | Params | Accounts | Stagger | Daily | On |
|---|
Proxy checker
Tests each proxy THROUGH the proxy: alive + latency, Jagex-compatible (reaches OSRS game world :43594 + Jagex auth), Enhanced (also reaches account.jagex.com + secure.runescape.com, not Cloudflare-blocked). Hover a result for per-endpoint detail.
| Proxy | Host | Scheme | Status & Jagex compat |
|---|
Account / ban checker
Checks each named character against the OSRS hiscores (routed through its proxy). "On hiscores" = present/active. "Not ranked" = UNKNOWN (could be banned, or just a new/low account that never ranked) — the definitive ban check is a launch/login (login-screen index 14), shown live as a BANNED pill on the Fleet tab.
| Character | Login (email) | Proxy | Hiscores / ban status |
|---|
Account analytics
| Account | Script | Status | Humanness | Last activity | Played before ban | Total played | XP/hr | First seen | Reflection clicks | Click interval |
|---|
Proxies shared pool — assign one per account
| Label | Scheme | Host | Port | User | Pass | Category | In use | Status & Jagex compat |
|---|
Paste-friendly: you can also type a whole proxy as host:port:user:pass in the Host field. Assign a proxy to an account from the dropdown in its row, or use "Auto-assign proxies" on the Accounts tab.
Bulk add proxies
One proxy per line as ip:port:user:pass (also accepts ip:port or a full scheme://user:pass@host:port URL). Blank lines and # comments are skipped; duplicates already in the pool are ignored. Pick the scheme below for lines that don't include one.
Manage proxy categories
Organisation only - a category never changes how a proxy is used or assigned. Deleting a category keeps its proxies and moves them to Uncategorized.
| Category | Proxies | Burned |
|---|