Settings

Settings is where an administrator configures the instance end to end. A rail on the left switches between sections; each one has its own Save control, so you change one area at a time.

Settings, organized into sections you configure one at a time

The sections

Section	What you configure
Network / VPN	The overlay network the fleet runs on, including status and the key used to mint cloud-burst access
Cloud GPU	Your vast.ai connection, default rental limits, allowed regions, and a list of hosts to avoid
Object storage	An S3 or Cloudflare R2 bucket for wordlists, with a one-click R2 preset and a read/write test
Cracking policy	The gates and cost model that govern which jobs run automatically, which need confirmation, and which are rejected
Cluster benchmark	Measure the fleet’s speed so job estimates are accurate
Hashcat engine	The hashcat version on each rig, with per-rig install or update to the validated build or the latest release
Notifications	Webhook and Slack destinations, which events fire, and whether they go to the in-app bell or email
Email / SMTP	The mail server used for invitations and notifications, with a test send
TLS / Let’s Encrypt	An automatic HTTPS certificate for the console, by DNS provider
Portal uplink	An outbound status feed to ARROW Portal, and the public URL used to launch this console
Onboard a node	Generate the one-line command to add a rig or a vote-only witness
License	View license status and install or replace a license
Updates	See the running version, pick the stable or beta channel, and install updates
Appearance	Switch between light and dark mode
Audit log	Review recent activity and export it

Cracking policy

The policy section is worth understanding because it shapes what happens when anyone queues a job. You set feasibility gates (for example, run jobs under a certain estimated length automatically, and reject ones over another), a cost and value gate (a cap on GPU-hours, a confirmation threshold, and minimum expected value), the cost model used for estimates (electricity and hardware amortization), and a default GPU-hour budget per operator over a day, week, or month. These gates are what produce the auto, confirm, and reject verdicts you see on the Jobs queue.

Cluster benchmark

Until the cluster is benchmarked, job time estimates fall back to a slow live probe and are only rough. Run Common types to benchmark the frequently used hash modes in a minute or two, or Full hashcat suite to measure every type on every rig in the background. The dashboard prompts you to benchmark when it has never been done or when your hardware has changed.

Hashcat engine

Each rig runs hashcat, and the whole fleet is standardized on one validated version so estimates and scheduling stay reliable. This section shows the recommended (validated) version alongside the latest release available upstream, then lists each rig with the version it is running now. Use Install (or Reinstall) to put the recommended build on a rig, or Latest to move it to the newest release. Moving a rig to the latest release can change how hashcat reports progress, so do it deliberately; the recommended build is the safe default. A rig cannot be updated while it has a job running.

Audit log

The audit log lists recent activity with the time, event, actor, source address, and details. You can export it for a SIEM in NDJSON or CEF format using the controls above the table. Viewing the audit log requires the audit permission.

Cloud GPUs - Uses the vast.ai and storage settings
Wordlists - Uses the object storage settings
GPU Nodes & Cluster - Onboard nodes and benchmark the fleet