How UpLink is built

Architecture

scroll sideways for the whole diagram →

Components

Enrollment: installer to day-one report

Running the installer does not make a machine managed; the server has to admit it, bind a credential to it and read its baseline first.

scroll sideways for the whole diagram →

Two ways in, one door. The signed UpLink-Setup.exe carries no key, so a PC installed from it presents only a public placeholder: the server records it as pending with its hostname, source address and hardware fingerprint, dispatches it nothing, raises an alert, and admits it only when an admin approves it in the console, which binds the secret the device presented and assigns its client and tier; a reject revokes the id, and both decisions are audited. The one-time install link minted in the console writes the fleet key and its token into the agent's config, so that PC is admitted at first contact and its secret is bound then; a wrong key is refused at the door and never queued. On either path the per-device secret is required every time the agent reconnects its live connection, so a leaked fleet key cannot take over an enrolled machine's connection. Until the per-device-secret cutover is switched on, the watchdog check-in, shutdown notice, portal-link and help-request calls still accept the fleet key alone. The baseline that follows is the as-found record the day-one report and every later review are measured against: 15 scans, plus 3 more on agents from 1.0.161 onward (a PC installed today gets all 18), a day-0 posture snapshot that the nightly retention sweep never deletes, and one disk-map walk plus one full folder-tree map of the drive (agents from 1.0.165). Removing a device from management deletes those rows along with the rest of its per-device history; what is deliberately kept is listed under offboarding below. The client ladder's 13 steps are answered once per client, not per machine; the day-one report generates when the initial machines complete and every day-0 finding is fixed, verified or on a named clock, and sign-off seals the record.

Network

• Agents open an outbound encrypted WebSocket to the server on port 443 and keep it up; the server never connects into your network and no inbound port needs opening. The same channel carries the agent's heartbeat (about every 30 seconds (the agent's default; configurable per device)) and the operator's requests.
• The server exposes 443, 80 (only to redirect to HTTPS and renew certificates) and 22 (SSH, used by the operator for administration and deploys; agents and browsers never use it). The application itself listens on localhost behind Caddy.
• Certificates come from Let's Encrypt and renew automatically.

Data, movement and retention

Security controls, as they stand

Agent updates: build to confirmed

This is the route an agent update takes from the build machine to a client PC; every hop either verifies something or refuses.

scroll sideways for the whole diagram →

Today the agent verifies the download's sha256 against the server's manifest, both fetched over HTTPS with the certificate checked, from the server named in its configuration file, which the agent locks to SYSTEM and Administrators. Agents on 1.0.227 or later also refuse to launch a new build unless it is validly signed by our publisher (Jamie Wiebrand); older agents, and the watchdog's reinstall of a dead agent, still rely on the sha256 check alone. The build is signed under a Microsoft-issued publisher certificate (Azure Trusted Signing), the signature Windows Smart App Control accepts where it is turned on. The verified bytes are extracted into a staging folder the agent creates already locked to SYSTEM and Administrators, and the helper that swaps them is re-launched through Task Scheduler so stopping the service cannot kill it. There is no saved copy of the old build: if the copy still fails after twenty attempts the helper logs it and tries to start the service; the separate watchdog task, which runs every ten minutes, reinstalls a dead agent from the same manifest with the same sha256 check, at most three times in six hours, after which it stops and raises a danger alert instead. An update can be dispatched from the AGENT UPDATE tab or the Action Center FIX button; both require the admin role or above, a dashboard push is audit-logged with the operator's name, and an agent update is never a zero-click fix. A fleet still on mixed versions after three days raises a warning on the operator's dashboard, re-checked every 30 minutes.

Automation and its switches

UpLink does not have one master switch. Automated action is gated by named switches, and the operator can read the live state of all of them in one call. For a new business client the recommended posture is alert on everything, act on nothing until each switch is agreed.

The gate map

The automation table above, drawn as wiring, with policy enforcement split into its two gates and the restart prompt on its own row: left, the server-side switch each surface hangs off; middle, what else must be true on that row before anything runs; right, the eight surfaces exactly as GET /fleet/automation-posture lists them.

scroll sideways for the whole diagram →

In motion, a packet fades where its row's gate stops it. Every switch in the left column ships off (database default 0), so out of the box nothing reaches a surface except the restart prompt, which answers to no master switch and only asks; its day count is the device's Care Policy restart-reminder setting (a cleared box means no prompt), else the site preference, else 5 days. The two amber rows answer to no master: a new custom monitor is created enabled, and applying a Care Policy with patching on writes that device's maintenance schedule enabled, so both arm as a side effect of another action. The go-live posture the API checks against keeps the guardrail, every workflow trigger and every custom monitor off, and expects the automation master on. With no trigger enabled, the master then lets through only the zero-click fixes, and those act nowhere until the operator picks a scope and fix types. Armed Care Policies are no longer part of that posture; the consent check (an armed policy on a device whose client has not approved enforcement) guards them instead. Patch auto_enabled is the one switch it leaves to the operator's judgement.

What this is not

• Not a 24-hour help line. Up Technology is a local service with stated response targets, not guarantees.
• Not a file backup service. We check whether a backup method (File History or OneDrive) is switched on; we cannot yet see when it last ran, and same-disk restore points do not count. We do not store copies of your files.
• No HIPAA business associate agreement is offered at this time. not offered Regulated data should not be placed in scope without that conversation.
• The product's built-in AI is switched off. built · off An optional alert-triage assistant exists in the product and is switched off; it would see alert text only, and this page and the privacy notice would change first.
• No custody of your encryption keys today. set up · no client keys We report whether a drive is encrypted. The optional key-safekeeping service is set up on our server but holds no client's recovery key, and collects one automatically only for a client who has approved it.

Providers involved

Hetzner (hosting, Virginia), Let's Encrypt (certificates), Brevo (outbound email), Namecheap (our domain, and the forwarding of mail sent to support@), Google (the Gmail mailbox that receives our alerts and summaries), Verizon (the text-message gateway that carries urgent alerts to Jamie's phone), GitHub (our private source code and the encrypted off-server backup copy, which it cannot read), Intuit QuickBooks (invoices and payments), Microsoft (code-signing certificate). What each one can and cannot see of your information is available on request at support@upcollectivemn.com.

Questions your IT advisor will ask

Twelve questions a business's IT advisor usually sends back after reading the sections above, answered against the code and configuration as deployed. Where the honest answer is "not stated" or "untested", it says so; those are the ones to ask Jamie about directly.

What do we allow on the firewall or proxy?

One destination for the agent itself: manage.upcollectivemn.com, TCP 443, outbound only. The agent holds a WebSocket over TLS (wss) to that host and uses plain HTTPS to the same host for the update manifest and bundle, the watchdog's 10-minute check-in, the shutdown notice and tray help requests. Nothing inbound; port 80 is not used by the agent. There is no proxy setting: the agent needs a direct route on 443, or a transparent proxy that passes a long-lived WebSocket upgrade. TLS inspection that re-signs certificates has not been tested — treat it as unsupported until tried on one machine. Beyond our server, the functions you enable reach: Windows Update and the winget sources (Microsoft CDNs and each publisher's download host) for patching and driver updates; *.nvidia.com, *.geforce.com, *.amd.com and *.intel.com only when a technician runs a GPU driver install (the download host is allow-listed in the agent); github.com once, to fetch the signature-verified osquery tool if that scan is used; winget's restic source if managed backup is set up; the PowerShell Gallery (www.powershellgallery.com and the Microsoft download hosts it and the NuGet provider bootstrap use) the first time Windows Update management runs on a PC, and again for HP's firmware tools; HP's download servers when a technician flashes an HP BIOS; and, for catalog apps installed straight from the publisher, that publisher's HTTPS host from a fixed allow-list in the agent. All outbound, 443 (80 for some Windows Update content).

What exactly leaves each machine, and can you reach our files?

Never sent by monitoring: the contents of documents and photos, email, browsing history. What does leave: the computer name, LAN IP and MAC address at registration; Windows account names; installed programs and versions; browser extension IDs; health readings with every heartbeat, including the names of the five busiest processes (shown live on the console, not stored); a daily count-and-latest-example summary of significant Windows event-log entries; messages a user types into the tray chat or help request; and, on a technician's request or once at setup, a disk map: folder names, sizes and dates and the paths of the largest files. A daily malware check also sends the names and paths (never the contents) of programs and scripts in each user's Downloads, Desktop and Temp folders, and the daily inventory includes network details: IP and MAC addresses, gateway, DNS servers and the Wi-Fi network name. Technician tools can reach files. An approved remote session (screen, mouse and keyboard, like a technician at the desk). A file browser that can list, download, upload and run files without an on-screen prompt: admin-only, every use written to the audit log with the path, a 100 MB cap per file, running limited to a fixed set of folders, and credential stores (the SAM and SYSTEM hives, browser password and cookie databases, Windows Credential Manager, SSH keys) refused by both the server and the agent. And command tools with no on-screen prompt that run with full system rights and can read any file: a remote PowerShell terminal (technician accounts; opening a session is logged, the commands typed in it are not) and one-off scripts (admin-only, each run logged). Nothing is copied to the server as part of monitoring or backup checking.

What will we see in Task Manager and on disk?

Service: UpLinkAgent (display name "UpLink Agent"), hosted by nssm.exe, running C:\Program Files\UpLink\uplink-agent.exe as LocalSystem, start type Automatic. Per signed-in user: one uplink-agent.exe tray process. Scheduled tasks, as SYSTEM: UpLinkWatchdog every 10 minutes and UpLinkWatchdogEvent on a service-crash event — both run a PowerShell script that restarts the service if it is down and posts an independent check-in to our server. Transient: uplink-agent.exe _rc-capture in the user's session during a remote session; winpty-agent.exe / OpenConsole.exe during a technician terminal session; osqueryi.exe during that scan; restic.exe only where managed backup is set up. Folders: C:\Program Files\UpLink (~83 MB) and C:\ProgramData\UpLink (config, logs, tools, remote-session frames). Memory, measured 2026-10-09 on one machine: ~55 MB service, ~38 MB tray, ~7 MB nssm — about 100 MB per signed-in machine. Each self-update downloads ~37 MB. Service logs rotate at 10 MB; rotated logs are deleted after 14 days.

Which Windows versions and editions?

Windows 11 and Windows 10, 64-bit, workstation editions. Windows 10 reached end of support on Oct 14, 2025: only 22H2 still receives security updates, and only while the PC is enrolled in Microsoft's Extended Security Updates (the consumer program runs to Oct 12, 2027; the program for organizations is bought by the year) — UpLink reports each Windows 10 PC's enrollment from the updates it is actually offered. Windows 11 Home is in the fleet today; the exact editions and builds tested are not recorded — ask before enrolling anything unusual. The installer requires an administrator, installs for all users and accepts any x64-compatible processor; it does not check the Windows build, so nothing stops it on an older release — untested, unsupported. Windows Server: the agent detects server roles, but no server has ever been enrolled; treat servers as unsupported. Not supported: macOS, Linux, ARM64. Not managed: Active Directory, your Microsoft 365 tenant, network equipment.

Will it fight our antivirus, EDR or backup software?

Antivirus: the agent reads Windows Security Center to find the active product and treats a third-party scanner as the protector, with Defender passive; it does not turn off your AV and adds no Defender exclusions. Optional hardening policies can switch Defender protections on — real-time protection, potentially-unwanted-app blocking, Attack Surface Reduction rules — and none is applied by default. Because it captures screens and injects input, some scanners flag it: the installer names the detected product and asks that C:\Program Files\UpLink and C:\ProgramData\UpLink be allow-listed if the service dies after install, and the console shows a red badge when an AV blocks the agent. Every build is signed (Azure Trusted Signing); Smart App Control accepts it, and SmartScreen reputation is still accruing. Managed EDR (CrowdStrike, SentinelOne, Huntress and similar) has not been tested alongside the agent. Backup: we read the state of File History, OneDrive and Volume Shadow Copies; the Windows Backup (wbadmin) read does not yet return a usable result. A third-party product (Backblaze, Carbonite, Acronis, Veeam, Macrium…) is detected as installed only — we cannot see whether it runs or succeeds. The product also contains an optional managed backup (restic) to a drive or network share you attach, set up per device by the operator, with nightly runs and restore tests; it never writes to our server. It can only be set up once the recovery-key safekeeping service on our server is initialized, which it now is; so far it is set up on one of our own test machines and on no client machine, so ask Jamie before counting on it.

What is the remote-control tool, and are sessions recorded?

Our own, built into the agent — not RDP, VNC or a third-party remote-access product. A helper in the signed-in user's session captures the screen and streams JPEG delta frames; mouse and keyboard are injected with the Windows SendInput API. Three access levels: view only (input refused in the agent), view and control, and take over (the user's display is covered). Before a session a prompt names the technician and the level and declines itself after 90 seconds; one yes covers one session, and once it ends, including a dropped connection, the next session asks again (a yes given before the session starts is honored for up to 5 minutes). A strip stays on screen with a Stop button, checked every 0.4 seconds, that cuts the session on the device. Yes, sessions are recorded: the server keeps the frame stream for 30 days (capped at 500 MB per session) and a receipt — who, when, access level, consent verdict, including declined requests — for about 13 months. Recordings are deleted when the device is removed from management. Nobody signed in: a session does not start. The operator can record a per-device unattended authorization (admin-only, audited, off by default), but the shipped agent and server do not yet act on it end to end. Notify-only (no prompt; strip and Stop button stay) can be set for a business machine only after the client's authorization is on record; the default everywhere is ask.

What happens when our internet, or your server, is down?

The agent keeps running and starts nothing new. It retries the connection on a randomized back-off — the first retry comes within 5 to 10 seconds, and the gap grows to at most about five minutes — and reconnects by itself. Scheduled work is dispatched by the server, not held on the agent: a maintenance run that fires while a machine is offline waits in the server's queue for up to 4 hours and runs if the machine reconnects inside that window, otherwise it expires with a recorded miss; the nightly managed backup skips offline machines; stale scans are re-dispatched within about 30 minutes of a machine coming back. Health readings are not taken or buffered while disconnected. On our side the device shows offline and, after its configured threshold, raises an offline alert. The local routines that keep running without the connection are the watchdog (keeps the service alive, every 10 minutes) and its hourly self-check, daily log pruning, the tray icon, decoy files that detect ransomware-style encryption (a trip is held and reported when the connection returns), and — on a machine we have network-isolated — an automatic release after 24 hours without contact with our server. Remote sessions, commands and uninstall need the connection. The user's work is unaffected: the agent monitors and maintains; nothing the user relies on runs through it.

Where is our data, is it separate from your other clients', and is it encrypted at rest?

On one server Up Technology operates at Hetzner in Ashburn, Virginia — not a third-party RMM vendor's cloud. All of our clients' device data sits in that one SQLite database, separated by client grouping, not by database; console accounts are not scoped per client either. The database file is not encrypted by the application, and we have no evidence of full-disk encryption on the host beyond whatever Hetzner applies — assume not. Secrets inside it are sealed: managed-backup passwords to a key file kept beside the database (mode 600, outside the database so a backup copy cannot unseal them), and any escrowed recovery key to an identity that needs a human passphrase. Database backup copies leave the server over SSH and are age-encrypted on the operator's workstation before being stored off-site; the sealed secrets inside stay sealed in every copy. Transport is TLS throughout. The operator's local staging copy of the backup is plaintext on a workstation without full-disk encryption — a known gap.

Does our data ever leave the United States?

Not as a rule, and we do not promise "never". Device data lives on one server in Ashburn, Virginia, operated by Hetzner, a German company whose staff have physical and legal access to the host. Backup copies are on the operator's workstation in Austin, Minnesota (encrypted copies plus one plaintext staging copy) and in a private GitHub repository (a U.S. company; the region it stores a repository in is not contractually fixed), encrypted with a key GitHub does not hold. Report and alert emails go through Brevo, a French provider, and land in the operator's Google (Gmail) mailbox. Urgent alerts and unanswered help requests are also texted to the operator's phone through Verizon's email-to-text gateway. These messages carry device names, health summaries and the text of a help request, and the location of Brevo's relay servers has not been verified by us. Mail you send to support@ is forwarded by Namecheap, our domain registrar. Invoices are kept in Intuit QuickBooks. Code signing sends file digests to Microsoft's signing service, never your data.

How is a device offboarded, and what is deleted when?

Two states. Retire keeps the record (history, audit trail, status page) but mutes alerts and drops the machine from scoring and invoices; reversible. Delete removes the device — health history, scans, patch and policy history, alerts, chat, remote-session receipts and recording files, per-device schedules and monitors, in one transaction — and revokes the device's identity so a still-installed agent is refused. Kept: the audit-log entries about the machine (they age out at 90 days, except the deletion receipt); any escrowed recovery key or managed-backup password, which need a separate, confirmed purge because they may be the only way back into a drive; the machine's name on the revoked list, so a still-installed agent stays refused; its onboarding record and the client's day-one report; any update rules, decisions or policy assignments made for that one device, and its last applied care settings; its installed-programs list, which ages out within 30 days; and database backups taken before the delete, which still contain it. On the PC: uninstall from the console, from Add/Remove Programs ("Up Technology PC Support"), or with uplink-agent.exe uninstall; that removes the service, the watchdog tasks and the tray, but leaves C:\Program Files\UpLink and C:\ProgramData\UpLink on disk — delete those two folders for a clean machine. Delete refuses while the agent is still connected: uninstall first, then delete. Written confirmation of deletion is available on request. The draft agreements, under attorney review, commit to deletion within 30 days of the service ending; the business figure is still bracketed for counsel.

Who at Up Technology can get into the console, and can we see the audit trail or get a copy of our data?

Console accounts are named, one per person, with one of four roles. Up Technology is a one-person business (Jamie Wiebrand); the account list is in the console and can be confirmed to you in writing — this page cannot verify a live count. There is no client login to the console: accounts are not scoped to one client, so a read-only account would see every client's machines, and we do not issue them. What you can see yourselves: each device has a private status page with a 30-day activity feed drawn from the audit log (client-safe labels only), and the day-one and monthly reports are built from the same log. Copies, on request — there is no self-service export: per device, the patch and update history as CSV, an evidence pack (security posture, compliance, performance) as CSV, HTML or PDF, the monthly reports, and the current inventory and health picture. The draft privacy notice commits to telling you what we hold about a computer and deleting it when you ask.

If your server were compromised, how would you contain it?

Up Technology is one person, with no security operations center and no 24-hour monitoring. The agent trusts its server, so whoever controls the server can run commands as SYSTEM on every connected machine. The protections enforced on the device itself: the on-screen consent prompt and strip for screen capture, a blocklist that refuses to read credential stores (the SAM hive, browser password and cookie databases, Credential Manager, SSH keys), a fixed set of directories executables may be launched from, a vendor allow-list for GPU driver downloads, and an updater that only downloads from the server address baked into the build and, from agent 1.0.227, refuses a new build not signed by our publisher. The written plan: isolate the server at the hosting console, snapshot it for evidence, rotate the fleet key — which disconnects every agent until re-provisioned — then the console tokens, sessions and mail credentials; counsel decides on Minnesota breach notification before any client is told. What lowers the odds: TLS everywhere, per-device secrets required on every agent reconnect (the background check-ins still accept the fleet key until the cutover is switched on), SSH with key-based deploy access (password SSH login remains enabled as a fallback), login throttling, an audit log with actor and source address. Missing today: a restore drilled from the encrypted GitHub copy (a restore from the workstation copy was drilled and passed on 2026-10-10), a drilled rebuild of the server itself, a bound cyber-insurance policy, a second operator.