On-Premise Guard Tour System

On-Premise Guard Tour System Server Sizing, Licensing, and Deployment Requirements

What an on-premise guard tour deployment actually requires — sizing the server from daily volume, storage math for your retention period, perpetual licensing, and who does what after go-live.

Gyula Györfi Former Police Commander · Founder of Trinity Guard® · 26 years of security operations experience

Discuss an On-Premise Deployment See the sizing requirements

Most on-premise quotes start from the wrong number. The buyer asks how many sites the system will cover, the vendor answers in sites, and the specification gets written around a figure that has almost nothing to do with what the server will actually have to handle.

What follows is the set of questions worth resolving before an on-premise guard tour deployment goes to contract — drawn from enterprise specification discussions rather than from a product sheet.

What "on-premise" actually means in a guard tour deployment

On-premise means a dedicated server inside the customer's own IT environment, administered by the customer's own team. Operational data stays in that environment rather than in the vendor's shared SaaS infrastructure, and the customer controls who reaches it.

It does not mean rented hosting, a VPS, a "private cloud" tenant, or a dedicated instance that the vendor still operates. Those are all reasonable models, but they answer a different question.

The distinction matters for three reasons. Data sovereignty: the record stays in a jurisdiction and a network the customer controls. Isolation: the core server environment stays under customer control, on a network the customer designs. Vendor lock-in: if the relationship ends, the server and the data remain where they are.

Three models, three risk profiles: SaaS, vendor-hosted dedicated, and true on-premise. Only the third puts the customer's IT department in control of the environment.

Size the server from daily volume, not from site count

This is the single most common specification error.

Eighty sites with two officers each and twenty sites with forty officers each produce completely different loads. Site count describes the contract. It says nothing about how much data will land on the server every day.

Four numbers actually drive the sizing:

Patrols completed per day
Checkpoint scans per day
Incident reports with photos per day
Vehicle entry and exit photos per day

And of those four, the photos are what consume the machine. Database records for patrols, scans, GPS coordinates, and timestamps are small. Images are not. A deployment logging a thousand photos a day has a fundamentally different storage curve than one logging fifty, regardless of how many sites appear on the contract.

Most buyers do not have these figures when they issue an RFP. Collecting them is the first real step in writing the specification.

Storage: the retention period is the real cost driver

Take an illustrative deployment profile — roughly three hundred patrols a day across a large multi-site operation:

Daily activity	Volume
Patrols	~300
Checkpoint scans	~1,200
Incident reports with photos	~300 reports = ~900 photos
Vehicle entry/exit photos	~800 photos
Total photos	~1,700/day

At 2–3 MB per image, that is roughly 3.4–5.1 GB of photo data per day. Add database records, GPS traces, and system logs — call it another 0.5 GB — and the conservative worst case is about 5.6 GB per day.

Now apply the retention period:

Retention	Storage required
30 days	~168 GB
90 days	~504 GB
365 days	~2.0 TB

One-year retention needs twelve times the storage of thirty-day retention. The retention period, not the site count, is what determines the storage budget — and retention is rarely an IT decision. It comes from the client contract, an insurance requirement, or a regulator.

Resolve retention before specifying the disk.

Minimum viable spec vs. headroom spec

A deployment at this scale should not be specified against a fixed minimum. As a starting point, 8 CPU cores and 16 GB of RAM is a reasonable baseline for an enterprise deployment, but storage has to be sized from actual daily volume and the agreed retention period. At 90-day retention, the profile above already needs roughly 504 GB before headroom, backups, or growth.

What is worth actually specifying is 8 or more cores, 16–32 GB of RAM with room to expand, and storage sized to the agreed retention period, on Debian Linux or an equivalent distribution. For a one-year retention target on the illustrative workload above, 2 × 4 TB SSD in RAID 1 provides safer headroom than 2 × 2 TB. Validate the final hardware profile against the actual deployment rather than treating it as a universal product minimum.

RAID 1 is not about performance here. It is about availability: patrol records are evidence, and losing them is not a service interruption but a loss of proof. The mirrored pair is the cheapest insurance in the entire specification.

The argument for headroom is equally simple. Expanding storage or memory after go-live is a server migration, not a configuration change — downtime, planning, and a maintenance window. Specifying the minimum saves money once and costs it repeatedly. Systems grow.

Perpetual license vs. subscription

For an enterprise on-premise deployment, the licensing question is usually a finance question before it is a technical one. A subscription is an operating expense that recurs indefinitely. A one-time perpetual license is a capital expense that is amortized and then done.

A perpetual license grants the right to run the installed version indefinitely. What it does not automatically grant is entitlement to every future major release — that is a separate commercial question, and it should be settled in writing at contract stage rather than discovered two years later.

One point that regularly causes confusion: the number of web users in a quote usually describes the role structure being built at go-live, not a licensing ceiling. Administrators, supervisors, dispatchers, and viewers are configured as the operation requires. Clarify explicitly whether the figure in your quote is a build-out scope or a hard limit.

And on lock-in: with a perpetual license on your own server, ending the vendor relationship does not end access to your data. The system keeps running, and the records stay where they already are.

Rollout scope is not a license cap

Related, and worth stating plainly because few vendors put it in writing.

The site count in an on-premise quote describes the initial build-out — the sites, checkpoints, shifts, and users configured before go-live. It is not a ceiling on what the system can hold afterward.

Once the deployment is live, the customer's administrators can add sites, users, checkpoints, shifts, and patrol tasks themselves. That is normal operation, not a change request.

What does become vendor work is scale. Significant growth may require additional CPU, RAM, or storage; a performance review; or a restructuring of the permission model. The operating principle is straightforward: nothing happens on the customer's server without prior consultation and written approval. It is their environment.

Updates, migrations, and who does what after go-live

Update policy is the most common source of post-contract dispute in on-premise deployments, and it takes ten minutes to settle beforehand. Four categories, four different answers:

Type of change	Handled how
Mobile application updates	Distributed through the official Apple App Store and Google Play channels
Server-side work, database migration, custom configuration	By prior arrangement
New modules, major versions, custom development	Separate technical and commercial agreement

The line that matters is between updates that reach the field without touching the server and changes that require someone to work on the customer's machine. Everything in the second category should require a scheduled window and an approval — no exceptions, including for the vendor.

Access control, backup, and network isolation

Three items that belong in every on-premise specification.

Firewall and network rules are set by the customer. The vendor states what the application needs; the customer's security team decides how to grant it.

RAID is not a backup. A mirrored pair survives a failed disk. It does not survive deletion, corruption, ransomware, or a mistake. A separate backup environment, with its own retention schedule and a restore that has actually been tested, is a distinct line item.

Administrative remote access needs a defined route. In regulated environments this typically runs through a privileged access management platform, or another mutually agreed secure method with session logging. "The vendor has SSH access" is not an access control policy.

On isolation: a deployment can run on a segregated, customer-controlled network. Validate fully offline operation before designing around it. Confirm during specification which functions require outbound connectivity so the network design accounts for them from the start rather than after installation.

The Bottom Line

On-premise is not a more expensive version of SaaS. It is a different division of responsibility. The vendor supplies and configures the software; the customer owns the environment, the data, the network, and the backup.

Answer these questions in the specification — daily volume, retention period, server headroom, licensing model, rollout scope, update policy, and access control — and the deployment becomes predictable. Skip them, and they resurface later, usually at the least convenient moment.

Frequently Asked Questions

Does the number of sites in the quote limit what we can deploy later?

No. The site count describes the initial build-out. Administrators can add sites, checkpoints, shifts, and users after go-live. Substantial growth may call for a hardware review, but it is not a licensing restriction.

Is the web user count a license limit?

Usually it describes the role structure configured at go-live rather than a ceiling. Confirm explicitly in your contract which of the two applies.

How much storage does an on-premise guard tour system actually need?

It depends on daily photo volume and retention period, not site count. A deployment generating around 1,700 photos a day produces roughly 5.6 GB — about 168 GB at 30-day retention, or 2.0 TB at one year.

Is this a subscription or a one-time perpetual license?

Enterprise on-premise deployments are typically licensed once, as a capital expense. Entitlement to future major versions is a separate commercial question that should be settled in writing.

Who is responsible for updates after go-live?

Mobile application updates are distributed through the official Apple App Store and Google Play channels. Server-side work, database migrations, and custom configuration happen by prior arrangement, with scheduled windows and written approval.

Can the system run fully isolated from the internet?

The server environment can run on a segregated, customer-controlled network. Validate fully offline operation during specification, and confirm which functions require outbound connectivity so the network design accounts for them.

What happens to our data if we stop working with the vendor?

It stays on your server. That is the practical meaning of on-premise, and the reason data sovereignty and vendor lock-in usually appear in the same conversation.

Customer-controlled infrastructure

Plan the Deployment Before You Size the Server

Bring the daily patrol volume, photo volume, retention period, rollout scope, and network requirements. We can review the deployment assumptions before they turn into a hardware or contract problem.

Discuss an On-Premise Deployment Review Guard Patrol System Pricing

For enterprise deployment questions, write to support@trinity-guard.com.