Bestfunc · Argus · Product Overview · Rev. A
Argus is a remote ops platform installed on your own server — one server, one Agent per machine, pulling terminals, remote desktop, files, databases and intranet endpoints into a single console; letting AI investigate and watch on your behalf under the authorization gates you define, asking you first before it touches anything; and even at a site with no internet at all, leaving a read-only troubleshooting bypass that connects directly on a ticket, never passes through the server, and keeps a hash chain audited on both ends.
Author
Argus Product Team
Organization
BESTFUNC bestfunc
Status
Public Release
Revision
REV. A · 2026.08
The ops problem for a small team is never "too many machines to manage." The real problem is that no second person can do this job — a full-time ops hire costs as much per year as a developer, and this work doesn't come up every day.
There are only a handful of people in your company. The ones writing code, the ones selling, the ones doing implementations — plus you. The machines you look after add up to anywhere from a few to a few dozen: the appliances running your software inside customer intranets, the database and build machines in your own server room, the one with the GPU, the test box in the office, and the one in the lab wired to an acquisition card that nobody dares reboot.
That isn't many. But they sit in places you can't reach, and every single one of them matters. One machine goes down and a customer grinds to a halt — and you are the only person who can deal with it.
1.1 A Day in Your Life
09:00
You sit down to write code. Today you want to close out that feature you've been putting off for two weeks.
11:20
A customer group chat pops up: "The system won't open," plus a phone photo of the screen, so glare-blown you can't read the error. Pinpointing the actual problem took six minutes. Getting "connected" took fifty — first asking whether their IT person is around, whether remote access can be switched on, whether the machine is locked, whether there's an approval process.
14:00
Your implementation colleague is at another customer site, voice-calling you to "read out what command to type." You read, he types, he mistypes, you read again.
23:40
You're on a high-speed train. The customer starts work at 8 a.m. tomorrow and is reporting right now that "the service won't start." On your phone, there is nothing you can do.
1.2 The Five Workarounds You Have Now
METHOD 01
Remote-control software
Seeing the desktop is enough. But someone has to be on the other side, and the machine can't be locked; you can't see last week's memory curve, can't query the database, can't dig up who changed a config three months ago, and you certainly can't hand that screen to an AI.
METHOD 02
Manual SSH + a jump host
It works. But nobody maintains that jump host; port mapping needs customer IT to cooperate; the connection dies the moment a machine changes IP; and granting a colleague access means "I'll send you my private key."
METHOD 03
Hard-coded scheduled scripts
Writing it felt great that day. Three months later, nobody knows whether it still runs, when it last succeeded, or whether anyone got a message when it failed.
METHOD 04
The network is already opened up
You paved the way long ago with NAT traversal or a mesh-networking tool. But once it's open: you build the monitoring yourself, issue the accounts yourself, keep the audit trail yourself, and if you want an AI to use it you write another interface layer yourself — and none of that is getting done either.
METHOD 05
Drive over there
The fallback when everything above fails. The actual config edit takes three minutes; to get those three minutes you drive four hours. You know it's absurd, and you have no other option.
1.3 Exactly Where Each One Breaks Down
| What you do now | Where exactly it breaks | What Argus does instead |
|---|---|---|
| Remote-control software | Someone has to be on the other side; the picture dies the moment the machine locks; there's only a screen — no historical metrics, no database, no record of actions you can archive; and it can't be handed to an AI. | When the screen locks it switches to the sign-in desktop and restarts capture, with nobody needed on the other side; desktop, terminal, files and database live in one tab bar, sharing one set of accounts, one set of permissions, one audit trail. |
| SSH + a jump host | The jump host itself goes unmaintained; port mapping needs customer IT to cooperate; a machine changing IP breaks it; granting a colleague access means handing out a private key you can never claw back. | The managed machine dials out on a single connection — no port mapping of any kind; change its IP and it reconnects on its own; every machine has its own certificate, revoking one leaves the others untouched, and permissions are issued to workgroups, not private keys. |
| Scheduled scripts | Three months later nobody knows whether it still runs, or which day that "all fine" it last reported was actually from. | Every inspection run leaves a record, a downloadable archival report and the actual cost of that run — and alerts you when it fails. |
| The network is open | The path is open, but not one of "the ten things you have to do once it is" got done: monitoring, accounts, permissions, audit, AI interface, file channel, database window. | Argus solves exactly the "after you can reach it" part: those ten things all happen under one set of accounts, one set of permissions and one audit trail (see the end of Chapter 02). |
"No second person can do this job" — that is your real ops problem.
What you're missing isn't a better remote desktop. It's someone who looks in every morning, wakes you the moment something breaks, and writes what they saw into a report you can archive — plus a channel that lets them (and you) actually reach those machines.
The managed machine needs no public IP, no inbound port, no VPN. It dials one encrypted long-lived connection outward, and every capability from then on rides on it.
Argus turns the direction around: the managed machine dials a WebSocket long-lived connection outward on its own initiative, and commands, terminal, files, database, intranet HTTP, object storage, intranet web and tunnels all reuse that single connection. So "one more capability" does not mean "one more open port, one more set of credentials."
2.2 Four Links, Each With Its Own Path
| Link | Path | What it solves | Through the server? | Status |
|---|---|---|---|---|
| Primary control link | Browser / desktop client ↔ Server ↔ Agent | Commands, terminal, files, database, intranet endpoints, config delivery, metric reporting — everything routine goes this way. | Yes | Live |
| Media link | Agent → media relay service → browser / desktop client | The live remote-desktop picture. Relaying does not re-encode it, and the media uses a single UDP port. | No (relay service only; signaling still goes through ①) | Live |
| AI link | External AI client → POST /api/mcp → Server → Agent | Gives an AI the same surface you have in the browser, executed under the server-side gate (Chapter 04). | Yes | Live |
| Offline field bypass | Engineer's laptop ↔ one inbound port on the Agent | At a site with no internet at all, a ticket-authorized direct connection for read-only troubleshooting, reconciled back at the office (Chapter 06). | No — never touches the server | Live |
2.3 Certificates Stay in Your Hands, End to End
CA · A self-built, self-managed private CA
If there is no CA when the Server first starts, it builds one automatically — no internet required, with the entire device trust chain living on your own server and depending on no external authority. If the CA fails to load, the service refuses to start rather than run with half a trust chain.
What this means for you ▸ When you deliver an appliance to a customer, "can the certificates and data stay inside their machine room" is often the line between a deal that gets signed and one that does not.
1:1 · One certificate per machine — revocable, rotatable
Installation token → one-time registration code → exchange for a machine-specific certificate. Every machine gets a certificate of its own, and revoking one leaves the rest alone; the revocation list loads into memory at startup, so handshakes need zero database lookups; you can also rotate certificates across the whole fleet remotely in one go. In strict mode, new machines land in a "pending approval" queue.
What this means for you ▸ When an implementation colleague leaves, you revoke a certificate instead of chasing down a private key you already handed out.
OFF · The offline installation package
No internet at all on that machine at the customer site? Generate an offline installation package from the console: the Server signs that machine's certificate on the spot and it travels with the package. The managed machine joins your management pool without ever touching the internet.
What this means for you ▸ The production-line PC's network cable was never plugged in anyway — bring a USB stick.
2.4 What It Does After It Drops Out — More Important Than How Stable It Usually Is
Heartbeat and dead detection
The primary connection heartbeats every 20 seconds; 90 seconds with no response marks the connection dead; reconnect backoff caps at 30 seconds.
Tier one: rebuild the connection
If more than 120 seconds have passed since the moment it dropped — note the clock runs from the drop, not from the retry count, otherwise a connection that comes up and immediately drops would never reach the threshold — the whole connection is rebuilt once.
Tier two: restart the whole process
After 600 cumulative seconds offline with three soft rebuilds already tried, the process exits entirely and lets the system service manager start it again. This tier only applies on Windows; on Linux it is deliberately downgraded to alerting only, because with nothing to start it again, exiting means going permanently offline.
Tier three: circuit breaker
Three full-process restarts within an hour and it trips its own breaker, stops restarting, only alerts, and writes a ledger to disk that accumulates across restarts. If the ledger cannot be read, it is treated as already tripped — when in doubt, always default to "not permitted."
Two Agents watching each other
On Windows, the Agent running as a system service and the Agent running in the signed-in user session watch each other: if one drops, the other brings it back. The console also has a button to "bring the offline one back up."
What We Won't Say · No Availability Percentage of Any Kind
The self-healing mechanism can be spelled out line by line, but we will not give any uptime or availability percentage whatsoever — that needs measured production data behind it, and this document only states what can be traced to code.
At a scale of a few dozen machines, what you need is not orchestration that configures ten thousand at once, but a clear view of each one. So Argus puts all its effort into "once you open a machine, how much can you actually do."
01 · Monitoring · METRICS
CPU, memory, disk I/O, network, multi-GPU, latency to the server, plus Top processes ranked along several dimensions. The collection interval is adjustable from 10–300 seconds (30 seconds by default; GPU and Top processes once every 90 seconds). Historical curves can be queried, with a window capped at 168 hours.
What you used to have to do ▸ Stand up a monitoring system for a few machines, then maintain it.
02 · Terminal · TERMINAL
A real interactive terminal, not "send a command, get text back": run programs that need interaction, use arrow keys, open multiple terminal sub-tabs. Input prefers a direct LAN connection and falls back to server relay automatically when that fails.
What you used to have to do ▸ A jump host plus private-key distribution — a path that simply does not exist on a Windows industrial PC.
03 · Remote Desktop · REMOTE DESKTOP
A live video stream encoded in hardware on the GPU, with three bitrate tiers (2000 / 4000 / 8000 kbps constant bitrate, peaking at 1.5×); on a poor network it degrades in three steps — frame rate → image quality → resolution — and climbs back automatically when the network recovers. Several people can watch at once, control is exclusive, has to be requested, and leaves a record; two-way clipboard is supported. When the machine locks, it switches to the sign-in desktop and restarts capture.
What you used to have to do ▸ Phone the customer and ask them to "unlock the screen" — the most common failure mode of remote-control software, handled here.
04 · Files · FILES
Browse, chunked reads, regex grep, search by name, edit text in place; pack into zip or tar.gz (split volumes supported) and unpack with automatic format detection. Large files skip the long-lived connection and go through server-side object storage with a concurrency queue and rate limiting, decoupling both ends. Text preview is capped at 1 MiB by default and can be raised remotely.
What you used to have to do ▸ Set up FTP or a shared drive, then manage a whole separate set of accounts.
05 · Database · SQL
Three database drivers are supported (PostgreSQL / MySQL / SQLite). Connection strings exist only as presets on the Agent side; the front end can select them and nothing more — you decide which database a person can reach, and they cannot even change it. The gate is read-only by default; per-table visual editing runs on a separate channel; and "export the whole result set" is its own permission switch.
What you used to have to do ▸ Send the database credentials to your implementation colleague and pray.
06 · Intranet Endpoints · HTTP PROXY
Call intranet HTTP endpoints reachable from that machine, using the Agent as the egress — no tunnel to build first, no network changes. Inline responses are capped at 10 MB, 100 MB in total.
What you used to have to do ▸ Request a port mapping and wait for customer IT to schedule it.
07 · Object Storage · S3-COMPATIBLE
Six kinds of operation against S3-compatible object storage, with the signing implemented in-house and no extra client required. This one needs the s3 capability switch enabled on the Agent side (activated by config pushed from the server) and is off by default.
What you used to have to do ▸ Install yet another client on that machine and configure yet another key.
08 · Intranet Web · INTRANET WEB
Embed an intranet admin panel that only that machine can reach into the console. The two links must be read separately: the browser side goes through a server-side HTTP reverse proxy with a session; the desktop client side uses local port forwarding — a native child window, first-party cookies, a fixed local port that reconnects on its own, so the page is never interrupted by a reload.
What you used to have to do ▸ Connect a VPN, then type an intranet address only you remember into a browser.
3.1 Between These Machines
Two machines that both sit behind an intranet and cannot see each other can still get a tunnel. Three kinds of path: relay through the server, direct after both sides hole-punch, and direct when one end has a public address (this one opens 16 parallel TCP connections per peer to raise throughput). The list shows whether each tunnel really runs direct or through a relay — no guessing.
3.2 A Dozen Machines Open at Once
The workspace is Chrome-style tabs: with a dozen machines open at once, switching over still finds your terminal there, your curves there, no "reconnecting." The overview page aggregates devices into cards — two Agents on one physical machine merge into a single card, and each card shows live mini-metrics, so you can tell which one is smoking without clicking in.
You can't afford to hire that person. But you already have a candidate who draws no salary — the only question is whether you dare hand it the key. This chapter first covers what it can finish for you, then why it's safe to let it.
4.1 First, One Thing It Can Finish for You
STEP 01 · You say one sentence
"The production box is throwing disk alerts — take a look at what's going on"
You say this in your own AI client. No switching windows, no logging into a console first, no trying to recall that machine's IP.
STEP 02 · It investigates on its own
It goes through the machine, read-only the whole way
Reading metric curves, listing directories, comparing sizes, grepping logs, querying the relevant database tables — all read-only actions, executed directly, without bothering you. What it gives back is "which directory is growing, since when, and with what."
STEP 03 · When it actually needs to act
The verification code goes to your own inbox
Now it wants to delete something, change a config, click a mouse. Argus sends the justification it wrote, the full parameters and the target device to your own inbox. Until you hand it the 6-digit verification code, that action never reaches the machine.
That is the whole product claim: AI with hands, the key still in your inbox.
4.2 Three Tiers of Gate: Read-Only Runs Free, Actions Need Your Nod
| Tier | Tools | Call protocol | Typical actions |
|---|---|---|---|
| L1 Read-only / reversible | 45 (26 operating remote devices + 19 that only change Argus's own configuration) | Executed directly. But it still passes permission checks, device-visibility checks and parameter constraints — "direct" does not mean "unchecked." | List directories, read files, grep, full-text search, read-only SQL, read-only HTTP probes, view metrics, view tunnel status, take screenshots, read screen elements |
| L2 Semi-reversible | 8 | The first time it must carry a justification → Argus sends the justification, the full parameters and the target device to your own inbox with a 6-digit verification code → the AI replays the call with that code. After one success, the same caller × the same tool × the same device won't bother you again for 15 minutes by default (a system-level setting an administrator can adjust between 5 and 240 minutes). | Upload to the sandbox directory, pack and unpack, create/modify/delete tunnels, write operations against intranet endpoints |
| L3 Irreversible | 9 | Every single time needs a new verification code, valid for 5 minutes, with no fast path. | Run arbitrary commands, execute writing SQL, upload files to arbitrary paths, and desktop actions that change machine state such as click / type / drag |
The verification code goes to you, not to an administrator. The recipient is the very person who initiated the call — whoever holds the permission owns the outcome, with no second person getting @-mentioned in a group chat.
4.3 The Highlight: Once the AI Has the Code, It Still Can't Change the Parameters
This is the nastiest hole in AI approval flows. Most implementations do it this way: AI submits → human confirms → AI submits again. That second submission is assembled entirely by the AI — the dialog you saw said "drop the test database," and what actually runs can be something else.
Argus does the opposite: what gets authorized is the request already persisted in the database, not the tool. On replay, the server uses the exact parameters stored at the moment of the request. Apart from typing the verification code, any field the AI changes has no effect.
What you see in the email is what ultimately runs on the machine.
01 · By Default It Can Only Look · DENY BY DEFAULT
Of all the tools, only 11 are on by default — mostly inventory actions like listing which machines and groups exist. Everything else needs your explicit authorization.
02 · Even One Tool Can Be Fenced · PARAMETER CONSTRAINTS
Most products stop at "tool on / off." Argus adds another layer: a single tool's parameters can also be fenced, across 5 kinds of constraint, configurable for 8 tools directly in the UI.
03 · Thicken the Read-Only Surface · READ-ONLY SURFACE
Diagnostic actions make up the vast majority of daily work, so Argus built a separate read-only command channel: 94 commands + 73 subcommand entries + 5 dedicated checkers, held separately on both the server and the Agent, identical entry by entry.
It is a read-only command allowlist, not a sandbox — we never call it that
This chapter answers "I can't afford the person who looks in every morning": quantified alerting handles "tell me when it breaks," multi-role AI inspection handles "go look even when nothing broke," and the two close the loop on the same page.
5.1 Tell You When It Breaks: Alerts Have a Lifecycle
An alert is not "CPU over threshold, fire." A rule in Argus is "some aggregation of some metric, for this long, above this much," paired with a cooldown window and automatic recovery — an alert moves from firing to sustained to notified to cooled down to recovered as a complete state machine, not a stream of repeated messages.
What it covers
Thresholds can be set on system metrics — CPU, memory, disk, network, GPU, latency to the server; on process-level conditions (whether a given process is still there, how much it is consuming); and on state events such as a machine coming online or dropping off.
How you write a condition
In the UI you assemble the condition into a natural-language-style sentence: "when the average of X over N seconds is greater than the threshold." Not a pile of unrelated fields to fill in.
Planned maintenance stays quiet
Maintenance silence windows support cron schedules. When you are upgrading at 2 a.m. on a Tuesday, it does not flood you with alerts.
Identity conflicts, reported proactively
After cloning a VM, swapping hardware or reinstalling an OS, two machines fight over the same device identity — the kind of thing nobody notices until something breaks and all you feel is "this machine works, then it doesn't." Argus simply tells you the identities conflict.
No screen-flooding
Notifications of the same type and target have a cooldown window and emit only once per period; online users get them as real-time pushes, offline users find them in the bell on their next login. Highly similar AI alerts are merged automatically, so the same thing never shows up over and over.
An alert can trigger an inspection by itself
After a numeric anomaly, it can automatically pull up an AI inspection to analyze itself — alerting finds that the numbers are off, AI inspection answers why.
5.2 Go Look Even When Nothing's Wrong: Three AI Roles That Undercut Each Other
This is not "have an AI run some commands and write a summary." Argus runs three rounds with three roles that keep their duties separate and undercut each other:
01 · Inspector · EVIDENCE COLLECTOR
02 · Verifier · FALSIFIER
03 · Reviewer · ADJUDICATOR
5.3 Four Layers of Guardrail: What Keeps the AI Boxed In
GUARD 01
The tool surface narrowed twice
A hard limit of 17 read-only tools, intersected again with the tool switches of the workgroup the service account sits in. Anything outside the allowlist is refused outright, with not even a second chance to ask.
GUARD 02
The identity cannot be an administrator
The inspection executor hard-rejects keys belonging to administrator accounts. We eat our own dog food, and we do not leave ourselves a back door.
GUARD 03
Anti-stale-knowledge guardrail
Every run injects the real date, forbids the AI from judging from training memory "whether a given version is a preview build or end-of-life," and only allows time-sensitive conclusions drawn from direct evidence on the machine.
GUARD 04
No flooding · no runaway
Each machine has an hourly cap on AI alerts; highly similar ones are merged automatically. Layered inspection: the cheap quick sweep runs frequently, escalating to a deep sweep only once it crosses a threshold, and anything escalated never escalates again (loop prevention).
5.4 Written Into a Report You Can Archive
A Report · A File, Not a Chat Screenshot
The AI emits structured data only; HTML comes from a server-side template. Reports are self-contained, downloadable and archivable offline, carrying a traceable report number; when several machines are involved they are sectioned per machine, and wherever a device ID appears you also see the alias you gave it.
Cost · What This Run Cost Is Calculated
Recomputed from real token usage times unit price, with no credit given to the figures a tool reports about itself; a budget cap can be set per run. AI providers can be swapped, though switching one means supplying its price list. For a small team with no AI budget, "knowing exactly what you spent" matters more than "how many providers you support."
Experience · Your Field Knowledge Settles Into the System
Write down "where this machine's logs are, what the health criteria are, which false positives are known" as a Skill injected into a given role, carried on every inspection and snapshotted into that run's report as the authoritative list. Knowledge moves out of your head and into the library — instead of vanishing the moment you leave your desk.
When did the disk fill up? The right answer to that question should not be "the customer told me."
Production-line PCs are simply never connected to the internet for security reasons, and some customer machine rooms occupy whole floors that are physically isolated. Every cloud-dependent approach drops to zero beyond that line — Argus leaves a bypass here: claim a capability ticket online before you leave, connect your laptop straight to the machine on site, and reconcile when you get back.
6.1 Three Stages End to End
STEP 01 · Before you leave, at the office
Claim a capability ticket
Three stages: claim (nothing is issued and no secret is generated at this point) → approve (an administrator can approve, or narrow the scope while approving, but never widen it) → activate (only here are the certificate and ticket actually signed). Validity runs from activation, not from approval — approved on Monday and travelling on Thursday, you do not lose three days for nothing.
STEP 02 · On site, with no network
Your laptop connects straight to the machine
The engineer's laptop uses mutual certificates to connect directly to one inbound port on the managed machine, never passing through our servers. Commands, file transfer and terminal sessions all run over that one encrypted connection — so only that single port needs to be open on site, and the managed machine needs no outbound permission at all.
STEP 03 · Back at the office, back online
Import both chains and reconcile
One chain on the laptop, one on the managed machine, both imported together afterwards. The server verifies two things: whether each chain is internally consistent from end to end, and whether the two sets of records match. A mismatch is an anomaly.
6.2 Seven Layers of Deny by Default
1 · Strictly verified mutual certificates
Both sides present certificates during the handshake, and both verify the other — not "having one is enough."
2 · Ticket signature-chain verification
The ticket carries its own issuance chain, verified up to the root shipped with it; a signature mismatch drops the connection immediately.
3 · Trusted clock
The managed machine takes the larger of the system clock and the last trusted time, then adds an in-process monotonic floor. Winding the system clock backwards while it runs does nothing.
4 · Five-step decision
Double-check the capability switch → does the ticket permit this tool → parameter constraints → risk-tier quota → release. The decision is made on the managed machine, not on the laptop.
5 · Read-only allowlist replicated independently
That read-only allowlist of 94 commands + 73 subcommand entries is stored separately on the Agent side and never delivered with the ticket — nothing written in a ticket can change it. The two copies are identical entry by entry, locked down by regression tests.
6 · Revocation list: when unsure, refuse
The revocation list is delivered in full. If rate limits are exceeded it skips this round rather than sending an empty list — an empty list would be read as "there are no restrictions right now." When in doubt, always default to "not permitted."
7 · Handshake rate limiting and blocking
Five failed handshakes within 60 seconds and that source is blocked for 600 seconds. Connections that fail before the handshake are audit-logged only, with no session row created, and shown on a dedicated console page as suspected-scan evidence.
Connecting to the Wrong Machine
No "ignore and continue" button anywhere
When the laptop connects, it checks the machine's certificate fingerprint and disconnects immediately on a mismatch — and there is no "continue anyway" option in the UI. It tells the engineer plainly: "this is not the machine you meant to reach; most likely the IP is wrong."
An engineer never makes a wasted trip
"This link cannot do it" and "this ticket is not authorized" are stated separately
The UI draws a hard line between the two kinds of unavailability: the latter can be fixed by claiming a new ticket back at the office, while the former is hopeless no matter how many tickets you claim. Conflating them costs a wasted trip.
Ticket-authorized read-only troubleshooting
Read-only commands, listing directories and reading files, grep, full-text search, read-only SQL queries, read-only HTTP probes — every step leaves a tamper-proof audit chain. For "get to site and find out what actually happened," that is already enough.
Write operations cannot be done on site
Write operations run over a different protocol: before you leave, claim a pre-authorized quota online (for example, "this tool can be used 3 times on site, valid for 8 hours"), decremented per use on site and reconciled back at the office. The server side of that protocol is fully implemented, but the current ticketing flow carries no quota and none of the three clients has a request entry point — it is queued for the next batch. Until then, the offline site is read-only.
Being offline does not mean losing control. The ticket you claim before leaving decides what you can touch on site — and you still reconcile when you return.
The configuration described in Chapter 04 governs more than AI. The same workgroup configuration fences both people and AI — the most valuable thing about the Argus permission model: you maintain one set of boundaries.
7.1 Three Workgroup Examples You Can Build Yourself
| Workgroup example | Which devices it can see | Which features it can use | The AI side |
|---|---|---|---|
| EX-1 Delivery team | They see only the customer machines assigned to them. Device IDs are filtered out in the backend query, not hidden in the front end. | Terminal, remote desktop, files and database queries on; "export all results" off. | All read-only tools on; writing tools off. |
| EX-2 Intern | Sees only the test-environment host type. | Monitoring and terminal only; no file writes, no database editing, no tunnel management. | Read-only file tools on, with a path blocklist attached: configuration files are out of reach. |
| EX-3 Customer read-only | They see only their own one or two machines. | Monitoring only. Features you have no permission for do not exist in the UI rather than appearing greyed out. | No AI credentials. |
7.2 Four Dimensions, One Place to Configure
DIM 01 · Menu visibility
Switches for 6 major modules. A module that is off does not exist in the UI rather than being a greyed-out button.
DIM 02 · Feature permissions
38 fine-grained feature switches. For example, "can query SQL" and "can export a whole table" are two separate switches.
DIM 03 · Data isolation
4 data-isolation dimensions. Not front-end hiding — device IDs you should not see are filtered out when the backend runs the query.
DIM 04 · Host-type allowlist
Which kinds of machines this group can see. Visible devices = host-type set ∩ workgroup assignment set.
7.3 Three Kinds of Key, Split at One Entry Point
KEY 01 · People
A login session
Credentials obtained by logging in through a browser, constrained by the four workgroup dimensions. Email two-factor authentication can be enabled, and single sign-on is supported — tokens issued by a third-party system match existing accounts by email and never auto-create an account.
KEY 02 · Systems
API keys for scripts and third-party systems
These keys are forcibly downgraded to non-administrator on the server — even if the person who issued them is an administrator. The point: if this key leaks, the blast radius is fenced in by the workgroup, and it can never escalate on its own.
KEY 03 · AI
Keys for AI clients
Goes through the gate from Chapter 04. Revocable from the backend at any time; an authorization window already granted can also be cut manually — the reason this revocation entry point exists is stated bluntly in a code comment: to disconnect fast if the AI runs away.
7.4 What Was Touched: Three Links, Each With Its Own Trail
01 · Human Actions · HUMAN AUDIT
02 · AI Calls · MCP AUDIT
03 · Offline Field Work · FIELD CHAIN
You trust your colleagues. But you should not let trust be the only line of defense.
Argus is not a cloud service you log into. It installs on your own machines, with data and certificates that never leave the building — and there is no underlying stack you have to stand up first.
8.1 Deployment Shape
The deployment shape is single-node: one server container plus one object storage service, your existing PostgreSQL for the database, and a pure static site for the front end that any web server you already have can host. The whole stack's production dependencies come to 16 Python packages. The media relay behind low-latency remote desktop is a separate small binary that runs on its own.
On first start it builds the private CA, migrates the database tables, clears the dirty data left by the last process crash, loads the certificate revocation list into memory and brings up the alert rules. All you have to do is change the default password once. There is no underlying stack you have to stand up first.
What You Need · One server and one mailbox that can receive mail
A Docker environment, a PostgreSQL, an SMTP account that can send mail (the verification codes for dangerous actions go out from here), and an address the managed machines can reach. That is all.
Where Your Data Is · Never Leaves Your Door
The private CA is generated on your own server and the device trust chain depends on no external authority; the whole onboarding process can be completed without internet access. AI provider addresses and keys are configured by you, so which one you use and what you spend stay in your hands.
8.2 What Ships on the Managed Side
| Platform | Form | Release package |
|---|---|---|
| Windows | The full form: remote desktop, desktop automation, process-level self-healing, two Agents watching each other. | About 8.1 MB as a single executable; remote desktop uses NVIDIA GPU hardware encoding |
| Linux | The server form: no desktop automation. Terminal, files, database, intranet endpoints, tunnels, metrics and self-update all complete. | About 8.4 MB |
| macOS | Can be cross-compiled, but there is no release package, no remote desktop and no desktop automation. | Not a delivery platform |
| Desktop client | Low-latency remote desktop, intranet web browsing, the offline field console. | macOS (Apple silicon / Intel) + Windows |
8.3 Four Things to Know Before You Install
Configuration advice 01
Create a separate account for AI — don't use an administrator account
An administrator account skips every check on tool permissions, device visibility, parameter constraints and approval — that is the capability the administrator identity is supposed to have, but it means the key you give the AI should not be that one.
Configuration advice 02
Change the default password after installing
First start creates a default administrator account automatically so you can log in right away. That is to make the first deployment smooth, not a selling point — please change it immediately after your first login.
Straight talk 01
Key storage: only one kind is encrypted
Today only AI provider keys are stored encrypted; the SMTP password and MCP keys sit in the database in plaintext, masked on read. That is a gap, not a design. So the phrase "all sensitive information is stored encrypted" will not appear in this document.
Straight talk 02
Device-side mTLS is currently optional
The server supports mTLS mutual authentication, currently configured as optional to stay compatible with the Token authentication used by older Agents. We do not write "mTLS enforced, no certificate no connection" — that would not match the current configuration. The certificate system itself (issuance, one certificate per machine, revocation, bulk rotation) is complete and usable.
These six scenarios share no industry. What they share is this: the machines are not within reach, and you are the only one who can fix them.
SCENE 01
Private deployments delivered into customer intranets
The hardest part: your software runs in someone else's house and you cannot see it. The customer gives you no public entry point, so when something breaks all you can do is ask for logs — and the logs they send are always incomplete, always stale.
What Argus does here: one outbound connection is enough, with no firewall changes on the customer side; you pull logs, metrics, databases and intranet endpoints yourself instead of waiting for someone to send them.
SCENE 02
Appliances and industrial PCs at customer sites
The hardest part: machines are scattered across different plants with no internet egress, and a visit costs a fortune; the other side usually has no IT, only machine operators.
What Argus does here: desktop, terminal and files sit in one tab bar; nobody on the other side has to click "allow," and nobody has to unlock a screen first.
SCENE 03
A small team's own servers
The hardest part: there are only a few — the database, the build machine, the one with the GPU running models. Nobody watches them full time, so a full disk or a dropped GPU is usually discovered only after something breaks.
What Argus does here: no monitoring system to stand up for a handful of machines; alerting wakes you, AI inspection goes and looks even when nothing is wrong.
SCENE 04
Store, front-desk and classroom terminals
The hardest part: there is no IT on the other side, only a store manager or a teacher. What you need is a look without disturbing anyone.
What Argus does here: nobody has to be present on the other side; giving them an account that sees only their own machine is a matter of cloning one workgroup.
SCENE 05
Labs and data-acquisition equipment
The hardest part: it is wired to dedicated hardware and must not be rebooted casually; you need eyes on the GPU and on that one process that absolutely must not die.
What Argus does here: process-level alerting; and after the machine goes down, you can still replay its metric curves from the 168 hours before it did.
SCENE 06
Production-line PCs with no internet at all
The hardest part: beyond this line every cloud-dependent approach drops to zero, and all you can do is carry a laptop to the site.
What Argus does here: connect straight to the machine with the capability ticket claimed before you left and troubleshoot read-only, never passing through the server, with hash chains on both ends reconciled back at the office (Chapter 07).
They share exactly one thing: the machines are not within reach, and you are the only one who can fix them.
In the table below we list what is not finished yet — because you will find out sooner or later anyway. A vendor willing to write that column is a vendor you can believe when it writes "live."
10.1 What Exists Today
| Capabilities | Status | Preconditions · limitations (this column may not be left empty) |
|---|---|---|
| Zero-inbound access · private CA · one certificate per machine | Live | The server supports mutual certificate authentication, currently configured as optional to stay compatible with the Token authentication used by older Agents. |
| Terminal / files / database / intranet endpoints / intranet web | Live | Each one is controlled by a capability switch on the managed machine; turn it off and the tab disappears; the object storage panel needs the s3 switch enabled in the runtime configuration first. |
| Hardware-encoded remote desktop · multi-viewer · control negotiation | Live | The managed side is Windows / Linux; desktop automation is Windows only. The virtual display used in headless scenarios involves third-party proprietary licensing and is not a standard capability shipped with the package. |
| AI access and the three-tier authorization gate | Live | All 43 tools that operate remote devices go through the gate; the 19 platform-management tools use sentinel permissions and send no verification code; the large-file channel carries the same rights as web upload; administrator accounts skip every check. |
| Quantified alerting + multi-role AI inspection | Live | The inspection role is hard-limited to 17 read-only tools and intersected with the workgroup switches. We provide no production runtime, hit-rate or stability percentage — that needs empirical evidence from real operations, and we do not have it. |
| Three-tier self-healing at the connection level | Live | The three self-healing tiers are complete on Windows; on Linux the second tier (full process restart) is deliberately downgraded to alerting only. No availability percentage is given. |
| Offline field console | Live · limited | Shipped but off by default; an administrator must push a passive-listener configuration from the server to enable it; what it can do today is ticket-authorized read-only troubleshooting; its external form is a desktop client. |
| Four workgroup permission dimensions + three audit links | Live | There are no built-in roles, only workgroups you configure yourself. There are three separate audits with three entry points, and we do not package them as a "unified audit platform." |
| Software discovery and safe takeover (ASC) | Partially live | The path "discover → handshake → take over → persist → see the list of taken-over software in the console" is already working. The number of callable capabilities in the post-takeover runtime is currently 0, and the remote-call channel is under construction. |
10.3 And What We Do Not Do
What we do not do
The cost of buying the wrong thing is high for a small team. Rather than let you spend three months discovering it does not fit, we draw the boundary clearly now.
What we do
Scenarios with a few dozen machines at most, where every one matters. Depth, not breadth.
DEPTH OVER BREADTH
Designed around "how much you can do on one machine," not "how many you can manage." A few dozen at most, and every one of them is the important one.
AI WITH A LOCK
AI with hands, the key left in your inbox. What you see in the email is what ultimately runs on the machine.
EVERY CLAIM IS CHECKABLE
There is not a single customer name, case study or runtime figure in this document. Every capability you see comes with its preconditions and limitations.
