Unified dashboard for artifacts and background services.
ENV
THEME
Deploy
Download artifacts
Setup folders
Install tasks
Manage services
Custom actions
Output
⚙️ running…
Metrics
File explorer
Select an environment to browse...
Services
no services selected
—RUNNING
—STOPPED
API client
Database
Load tests
No suites yet — add one under Settings → Load tests.
Blank fields use the suite's own load profile. A duration overrides loops.
Live output
Past runs
Disk cleanup
—nothing measured yet
Nothing measured yet
—Analyze to measure
Nothing selected.
Measures what is actually using the disk, whether or not it belongs to a
cleanup category. Analyze reads sizes only and deletes
nothing; files are removed one at a time, and only the ones you tick.
Nothing measured yet
—Pick a location
No location chosen.
Runs the categories you pick on a timer and records what each run reclaimed.
Start with measure only to watch what a schedule would free before
letting it delete anything. Schedules fire only while the panel is running —
a window that passes while it is off is reported as missed, never run late.
No schedules.
Finds files with identical contents, whatever they are called.
Searching compares files and deletes nothing. Nothing is selected for you:
each set has one copy marked to keep, and one always stays.
No location chosen.
Import from phone
Copies photos and documents off a phone plugged into this machine
over USB. Nothing is changed or removed on the phone — this only reads.
Connected devices
On the phone, open Developer options → Wireless debugging and leave that
screen on. Phones that are advertising themselves appear below — the panel listens for them
and never scans the network.
Contacts
Include
Choose a device to begin.
Local processes (Java / Node)
Console
⚙️ running…● live
CPU--
RAM--
Disk--
🕒loading...
Starting up...
$
Editing File
Compare Config File Across Environments
vs
Settings
Profile picture
No picture set
Two-factor authentication
—
Passkeys
Logo
"Last used" reopens whatever you had selected last; pick a specific environment to always start there.
Desktop app
The installer already starts the server quietly when you sign in. This also opens the panel window — the setting the browser otherwise buries under its three-dot menu, App info, Settings. Applies immediately; no need to Save.
Custom colors (hex, e.g. #1e293b). Changes preview live.
Typography
Shape
Presets — save the current colors/typography/shape under a name, or apply one saved earlier.
Panels — hide dashboard sections you rarely use. Hidden panels also skip their background work (e.g. the local process scan). Metrics panels live on the Metrics tab.
These are the shared defaults. While a dashboard template is active it decides what you see instead — see the Templates tab.
A template decides which panels you see and where they sit. It is yours alone — kept in this browser, never written to the shared config — and it changes nothing about what you are allowed to do: your role still decides that, and the server enforces it either way.
Panels in the active template. Every template is editable — changes stay on the one you are editing, and a built-in can be put back with Reset on its card.
Default template per role — where a user lands before choosing their own. Saved with Settings, shared by everyone.
Default template per persona — checked before the per-role default above, so a user with both a role and a persona follows the persona's mapping. Saved with Settings, shared by everyone.
Feedback when an operation finishes — a service starts, a file saves, a request comes back, a deploy fails. Results are already written to the console; these settings decide what else happens on screen.
With this on and reduce-motion set in the OS, movement is dropped but the notifications themselves stay — you still find out whether it worked.
Notifications — the cards that appear when an operation reports a result.
Which results to announce. Repeats of the same message inside a few seconds collapse into one card with a count, so a bulk action over twelve services does not stack twelve notifications.
On-screen effects.
The progress line ignores the background metrics and status polls — it appears for work you started.
Purely for enjoyment. Nothing here changes what an operation does or what gets written to the console — and it all switches off on a machine set to reduce motion.
One shower at most every few seconds, so a bulk action over twelve services stays watchable.
Try it — these fire the real thing, with the settings above as they currently stand.
What the panel measures and how it is displayed. The console header readout and the Metrics Dashboard card are toggled independently.
Environments shown on the dashboard.
Tiles — which readings each environment card shows. Unchecking a metric also stops it being requested.
Extra readings — context alongside the percentages. These carry no colour: a load of 4 is idle on 16 cores and desperate on one, and the panel does not know the core count.
Layout & triage — how the cards are arranged. Cards can only be dragged in manual order.
Trend & freshness. Trend lines are kept in the browser only, so they start empty after a reload — persisting them would grow the metrics log without bound at one sample per refresh.
Auto-refresh — each cycle runs one metrics command per visible environment, so keep the interval comfortably long on large fleets.
Thresholds — the percentage at which a reading turns orange, then red. Applies to the dashboard and the console header alike.
Leave a field blank to inherit the value above. A full disk is normal where a pegged CPU is not, so these rarely want the same numbers.
Status colours. The bar length and the number always carry the same information, so a reading is never signalled by colour alone.
No environments match your search.
Custom actions are named commands that run on the control panel host. Each action gets a button on the dashboard; actions marked for snapshots also run on the health-check schedule with their output captured under Snapshots. Editing actions requires the admin role.
No actions match your search.
Uptime Monitoring
The health-check URLs below are checked continuously; history, incidents and alerts appear in the 📡 Monitoring dashboard. Advanced targets (TCP checks, expected status codes, extra alert channels) can be defined under monitoring in config/config.json.
Unreachable targets
A check that never reached the service — a dial timeout, no route, a hostname that would not resolve — says nothing about whether that service is healthy. Rather than record it as down, the panel corroborates across targets in the same cycle: when everything sharing a route goes silent together while localhost keeps answering, the fault is this host’s connectivity (a disconnected VPN, most often), so no incident opens, no outage alert is sent, and the checks are left out of the uptime figure instead of counted against it. Per-target gate and requiresVpn settings live under monitoring.targets in config/config.json.
Health Checks & Snapshots
One schedule drives both: each run checks the URLs below and captures the output of any custom action marked for snapshots.
Cron Schedule
Down & Recovery Alerts
SMTP Configuration
Email Template
What an alert mail looks like. Pick a ready-made template, or write your own — starting, if you like, from any of the ready-made ones.
A first line starting with Subject: becomes the mail subject; the rest is the body. Placeholders:
Webhook Configuration
Alert Triggers
Self-Healing Mappings
Automatically trigger a Custom Action when a Healthcheck target goes down.
SIEM / Log Forwarding
Forward every audit log entry (logins, deploys, config changes, denied requests) to an external destination in real time.
Backup & restore
Export bundles every settings document — general settings,
environments, services, custom actions, saved credentials, API
collections, config templates and load-test suites — into one
JSON file. Every module is ticked to start with; open one with
“Choose items” to pick the individual environments,
actions or requests that travel, or use Select all / Unselect all
to sweep the lot. Import loads that file back, overwriting the
matching documents here. Works the same way whether this panel is
self-hosted or a workspace in SaaS mode: it always backs up (and
restores) your own settings, never anyone else's.
Importing replaces these documents outright — it does not merge
with what is here now. Restoring after a crashed or reset database
is the main use; the same file also moves a configuration between
two installs of the panel that share a credential key, so saved
environment passwords keep working after the move.
Reset to a clean state
Puts the settings you pick back to what a fresh install has —
an empty list of API collections, the starting set of environments,
and so on. Nothing else is touched. This is the way back to a clean
panel without stopping it and deleting files by hand, and it takes
effect immediately rather than on the next restart.
Export a backup first if there is any chance you want this back.
Clone settings from another workspace
Ask another workspace's owner for a copy of their settings. They
decide whether to share, and which documents — you get exactly
what they tick, as it was at the moment they approved. Saved
environment passwords are never shared, so cloned environments
arrive needing their credentials entered again.
Waiting for your decision
Your requests
A config template renders a file for one destination path with {{VAR}} placeholders filled in from the values you give it, checked for valid JSON/YAML before anything is written. Preview and Deploy always act on the environment currently selected in the header — switch it there first. Deploying writes the file through the same mechanism as the File Explorer, so it requires the deployer role and is audit-logged. Editing the template list itself requires admin.
Suites built-in engine
Multi-step HTTP load tests run by the panel's own
engine — no JMeter and no JVM required. Each step can carry headers, a body, assertions
and extractions that feed later steps (a login handing a token to everything after it). Suites are
edited as JSON so they can be pasted between environments and kept in version control; the panel
validates on save and tells you what is wrong. Run them from the Load tests card
on the dashboard.
Load templates JMeter
Named JMeter test profiles (e.g. Heavy Spike, Soak Test)
with pre-configured thread counts, ramp-up times and loop counts. Apply one to any saved API
request using the Dynamic API test mode on the dashboard. These do not apply to
suites — a suite carries its own load profile.
