SoftActivity Monitor deployment architecture: Admin Guide

This guide explains how to design a SoftActivity Monitor deployment that fits your environment and is easy to operate later. It is written for IT architects, DevOps and endpoint admins, MSP teams, and IT managers who need a clear deployment model before they start installing anything.

SoftActivity Monitor is best understood as a central monitoring platform plus a Client App installed on each monitored Windows computer. The main design task is deciding how those clients will connect to the central platform, where the server roles should live, and when to keep everything on one machine versus split roles for scale or policy reasons.

Table of contents

1. What this guide covers
2. SoftActivity Monitor in one minute
3. Respecting user privacy
4. The architecture decision that matters most
5. Reference architecture
6. Common deployment patterns
   • 6.1 Small office or single-site LAN
   • 6.2 Hybrid work and Microsoft 365 or Entra environments
   • 6.3 Remote-first or cloud-hosted deployment
   • 6.4 Multi-site and larger organizations
   • 6.5 Air-gapped or isolated networks
   • 6.6 VDI or VDM environments
7. Core components and what each one does
8. Data flow by connectivity model
9. Design and operational guidance
10. Quick selection matrix
11. Related guides

1. What this guide covers

Use this guide when you need to answer practical design questions such as:

• Can we run SoftActivity Monitor on one Windows machine, or should we place roles on separate servers?
• Should we use Local network mode or External Agent mode for a given group of devices?
• Can one deployment support office desktops, VPN laptops, and fully remote users at the same time?
• How should we think about branch offices, cloud-managed devices, VDI, and isolated networks?
• Where should delegated manager access happen: in the infrastructure, or in the application?

This is an architecture guide. It explains the deployment choices and the reasoning behind them. It does not replace the step-by-step installation guides linked at the end.

2. SoftActivity Monitor in one minute

If you are new to the product, start here.

At a high level, SoftActivity Monitor consists of these parts:

• Client App or Agent on each monitored Windows computer
• SoftActivity Monitor Server and Admin Console – Windows app and services for administration, live monitoring, and client management
• SoftActivity Webapp Server for browser-based reports and delegated access through the Web Console
• PostgreSQL database for logs, screenshots, and application data

From a deployment perspective, SoftActivity Monitor supports two connectivity models:

• Local network mode: the Monitor server reaches the Client App directly over the office LAN, or over a company VPN when the server can still reach the device by DNS name
• External Agent mode: the client initiates a secure connection to a central endpoint, which is the better fit when the server cannot reliably reach the device first

That choice matters more than company size. A 20-user remote-first company may need External Agent mode everywhere, while a 300-user campus with dependable LAN reachability, or VPN reachability by DNS name from the server, may stay mostly in Local network mode.

3. Respecting user privacy

Before deploying SoftActivity Monitor, ensure that your organization owns the monitored computers or is authorized to monitor them, and that you have a valid legal basis to collect user activity data in your jurisdiction.

Your company computer-use policy should clearly explain:

• what information is collected
• how it is used
• where it is stored
• who can access it

SoftActivity provides settings that help align the deployment with that policy. In practical terms:

• Visible mode can notify users that monitoring is active
• the Web Console can limit what supervisors and managers are allowed to see
• retention settings control how long logs and screenshots stay in storage
• group and user assignments help scope access by team or department

This is worth deciding early, not after rollout. The architecture you choose does not remove these responsibilities. External Agent mode changes how a device connects. It does not change the need for authorization, notification, retention, and access control.

4. The architecture decision that matters most

The most important question is simple:

Can the SoftActivity Monitor server reach the monitored computer directly by DNS name or IP address?

If the answer is yes, use Local network mode.

If the answer is no, but the monitored computer can reliably reach a central endpoint hosted on your server or in cloud infrastructure, use External Agent mode.

If those devices cannot reliably reach a customer-managed Monitor server, either place the deployment in that network boundary, use External Agent mode if supported, or consider SoftActivity Work, where Client Apps connect outbound to the SoftActivity-hosted cloud service.

As a rule of thumb:

• office desktops on the same LAN usually belong in Local network mode
• remote laptops on a stable company VPN can also stay in Local network mode when the server can reach them by DNS name
• home or travel laptops without VPN usually belong in External Agent mode
• Microsoft 365 / Entra ID cloud-managed devices usually fit External Agent mode better
• isolated networks may need their own local deployment if they cannot route back to the central platform

5. Reference architecture

In most environments, the cleanest starting point is one central SoftActivity deployment that can support more than one connectivity model at the same time.

That means:

• office devices, and VPN-connected devices that the server can reach by DNS name, use Local network mode
• fully remote or Microsoft 365 / Entra ID cloud-managed devices use External Agent mode
• both groups still write into the same central platform and the same reporting workflow
• supervisors and managers use the Web Console instead of needing separate infrastructure per department

In smaller environments, the central deployment can run on one Windows machine. In larger environments, the same logical design can be split across multiple servers. The important point is that you do not need separate SoftActivity platforms just because connectivity differs across user groups.

The External Agent endpoint is often the same host as the central Monitor server, as long as remote devices can reach it reliably. In remote-first environments, a cloud-hosted Windows VM is often a cleaner endpoint than an office PC or an internal-only server name.

6. Common deployment patterns

6.1 Small office or single-site LAN

For a small office where monitored computers sit on the same LAN, Local network mode is usually the simplest and most supportable option.

A typical design looks like this:

• SoftActivity Monitor Server, Admin Console, Webapp Server, and PostgreSQL run on one Windows machine
• monitored computers run the Client App
• the central machine downloads logs and screenshots and stores them locally
• administrators use Admin Console for setup and live monitoring, and Web Console for reports

This design works well when:

• the monitored computers are directly reachable over the LAN
• the central Windows machine can stay available during business hours or longer
• you want the fewest moving parts
• the environment is small enough that one host is operationally acceptable

This is also the easiest place to use the built-in remote install workflow from SoftActivity Monitor. Add from AD, direct remote install, and local install are all valid here. Active Directory helps, but it is not required. Workgroup deployments are also supported if name resolution, administrative access, and network reachability are in place.

One practical note: when the machine hosting the server is offline, clients can cache recorded data locally and upload it later. That is acceptable in a small office or pilot, but it is a good reason to move the server role to a more stable machine as the deployment becomes business-critical. As the environment grows past a small deployment, hosting the core roles on a Windows Server becomes the safer default.

6.2 Hybrid work and Microsoft 365 or Entra environments

This is the scenario where teams often overcomplicate the design. They do not need to.

If some users work in the office and others work remotely, keep one central deployment and mix the two connectivity models:

• use Local network mode for office devices and VPN-connected laptops that the server can reach by DNS name
• use External Agent mode for devices that are off-premise and not reliably reachable from the server
• keep the same Web Console, retention policy, and delegated access model for both groups

This is especially useful in Microsoft 365 or Entra ID environments where devices are cloud-managed and the classic server-to-client LAN path is weak or nonexistent.

The important operational difference is deployment method. The built-in Install Agent flow is for Local network deployments. For External Agent mode, think in terms of managed rollout through Microsoft Intune, an RMM platform, or your own software delivery tooling.

6.3 Remote-first or cloud-hosted deployment

If most of the monitored computers are remote and there is little or no always-on office infrastructure, a cloud-hosted Windows VM is often the cleanest home for the SoftActivity core services.

In that design:

• SoftActivity Monitor Server runs on a cloud Windows VM with a stable DNS name
• the same host, or another reachable host, acts as the External Agent endpoint
• remote Windows devices enroll through External Agent mode
• administrators and managers continue to use the same Admin Console and Web Console model

This avoids a common failure point: depending on an office PC or internal server name that remote devices cannot consistently reach.

6.4 Multi-site and larger organizations

For a larger environment, the default answer is still not “one server per site”. The better starting point is one centralized deployment, then split roles or add site-local infrastructure only when you have a concrete reason.

Start centralized when:

• WAN connectivity between sites is reliable enough
• your policy allows a shared central database and Web Console
• central administration is preferred
• branch sites can be handled through a mix of Local network and External Agent connectivity

In this model:

• branch-office devices on a dependable site-to-site VPN can use Local network mode when the server can reach them by DNS name
• users without dependable server reachability can use External Agent mode
• supervisors and managers can receive scoped Web Console access without separate infrastructure per department

Split roles when you have a real driver such as:

• scale and performance
• data residency or policy boundaries
• security segmentation
• a requirement to make Web Console, database, and server roles independently managed

In that case, it is reasonable to place:

• SoftActivity Monitor Server on one Windows server
• Webapp Server on another server
• PostgreSQL on a dedicated database host or managed PostgreSQL platform

Separate site-by-site deployments are still valid, but they should be a deliberate isolation choice, not the default enterprise pattern.

6.5 Air-gapped or isolated networks

Air-gapped and isolated networks follow the same architecture logic, just inside a smaller trust boundary.

A practical design is:

• place SoftActivity Monitor Server, Webapp Server, and PostgreSQL inside the isolated network
• use Local network mode if the server can reach clients directly inside that network
• use External Agent mode only if the internal design intentionally uses client-initiated connectivity
• keep deployment, management, and storage local to that environment

If you have multiple isolated zones that do not route to one another, treat each zone as its own deployment boundary.

6.6 VDI or VDM environments

VDI does not require a separate SoftActivity architecture by itself. The same reachability rule still applies.

Use Local network mode when virtual desktops behave like normal Windows endpoints that the server can reach directly. Use External Agent mode when the virtual desktop platform is designed so that clients initiate connectivity instead.

The main design difference in VDI is operational, not conceptual:

• persistent desktops behave more like physical PCs
• non-persistent desktops need careful packaging and image management
• rollout and updates may be tied to image pipelines rather than ad hoc install methods

Keep this separate from TS Monitor, RDS, or shared session monitoring guidance. This guide is about SoftActivity Monitor deployments for workstation-style endpoints, including virtual desktops.

7. Core components and what each one does

Component	What it does	Typical placement	Notes
SoftActivity Monitor Server and Admin Console	Central administration, live monitoring, device management, and server-side data collection	One central Windows host in small or mid-size deployments	This is the operational control plane
SoftActivity Webapp Server	Browser-based reports, screenshots, alerts, and delegated access	Same host as the server by default, or separate in larger deployments	Web Console is the right place for manager or supervisor access, and it uses port 8081 by default
PostgreSQL database	Stores logs, screenshots metadata, settings, and reporting data	Same host in simple deployments, separate host for scale or policy	Retention planning matters here
Client App	Runs on monitored Windows endpoints and records activity	Every monitored device	Installed differently depending on connectivity model
External Agent endpoint	Reachable network endpoint for off-premise clients using External Agent mode	Often the same machine as the server, sometimes separate	Remote devices must be able to reach it reliably

A helpful mental model is this:

• Admin Console is for administrators doing setup, agent management, and live monitoring
• Web Console is for reviewing historical data and giving scoped access to managers or supervisors
• background collection continues on the server even when Admin Console is closed
• PostgreSQL is the long-term system of record
• Client App is the endpoint component that actually records activity

8. Data flow by connectivity model

Local network mode

1. The Client App is deployed to a reachable Windows computer.
2. SoftActivity Monitor Server connects to that computer directly over LAN, or over a company VPN when the server can reach the computer by DNS name.
3. The server downloads logs and screenshots and stores them centrally in PostgreSQL and the configured storage location.
4. Administrators work in Admin Console, while supervisors and managers review results in the Web Console.

This is the best fit when the server has dependable line-of-sight to the endpoint.

External Agent mode

1. The administrator creates the External Agent configuration and enrollment token.
2. The Client App is deployed to the remote device using manual installation, Intune, RMM, or another delivery method.
3. The remote device initiates a secure connection to the central endpoint.
4. Data is written into the same central deployment and becomes visible in the same reporting workflows.

This is the best fit when direct server-to-client connectivity is not dependable.

9. Design and operational guidance

A few design rules make most deployments simpler and easier to support:

• Start centralized first. Split roles only when scale, performance, policy, or isolation gives you a real reason.
• Choose connectivity mode by reachability, not by company size or org chart.
• Do not assume Active Directory is required. It helps with discovery and remote install, but SoftActivity can also work in supported workgroup environments.
• Do not assume VPN is mandatory for remote users. If a device is not reliably reachable from the server, External Agent mode is usually the better answer.
• Do not use the built-in local-network install path for External Agent rollouts. Treat remote deployment as a managed software distribution task.
• Use Web Console roles and group assignments for delegated access. Department separation usually belongs in the application, not in separate infrastructure stacks.
• Plan data retention from day one. Logs and screenshots will grow over time, and the default posture of keeping data indefinitely is rarely what you want in production.
• Keep client and server versions aligned so that upgrades and troubleshooting stay predictable.

10. Quick selection matrix

Scenario	Recommended approach	Why it fits	Typical rollout method
Office desktops on the same LAN	Local network mode	Direct server-to-client reachability exists	Built-in remote install, local install, GPO
Remote laptops on a reliable company VPN and reachable by DNS name from the server	Local network mode	VPN restores the same direct path the server expects	Built-in remote install, GPO, local install
Home or travel laptops without VPN	External Agent mode	The client can reach the endpoint, but the server cannot reach the client first	Local manual install, Intune, RMM
Microsoft 365 or Entra ID cloud-managed devices	External Agent mode by default	Cloud-managed endpoints often lack dependable LAN-style reachability	Local manual install, Intune, RMM
Hybrid workforce	Mixed model in one central deployment	Lets each device use the right connectivity mode without splitting the platform	Mixed rollout
Remote-first company	Cloud-hosted central deployment plus External Agent mode	Gives remote devices a stable endpoint	Local manual install, Intune, RMM
Multi-site enterprise	Start centralized, then split only if required	Keeps operations simpler and reporting unified	Mixed by site
Air-gapped network	Local deployment inside the isolated boundary	No dependable route to a central shared deployment	Local manual install, local admin tools
VDI or VDM	Depends on reachability pattern	Virtual desktops follow the same connectivity rule as physical endpoints	Image-based rollout plus chosen mode

11. Related guides

• SoftActivity Monitor installation guide for administrators
• How to install SoftActivity Monitor Client App: Admin Guide
• How to monitor remote off-premise computers with SoftActivity Monitor External Agent mode: Admin Guide
• How to install SoftActivity Monitor Client App using Microsoft Intune
• SoftActivity Webapp instructions for Admins