Can RTLS Stay On-Premises? A Network and Data-Ownership Checklist for IT Teams

An on-premises RTLS design needs more than a local MQTT broker. The review must establish where position data travels, where it is stored, which services depend on external access and who operates each component. A local data path may be feasible while configuration, licensing, updates or support still have separate dependencies.

Use the checklist below to define the architecture you need and the evidence a vendor or integrator should provide. It is a proposed review method, not a claim that every component is included in a turnkey Q1 package.

Ask which part must remain local

“On-premises” can describe several different requirements. Some teams want location records stored only inside a site. Others need collection to continue through an internet outage. A more restrictive environment may prohibit external connections throughout installation and operation.

Write the requirement in concrete terms:

• Which location, identity and diagnostic data must stay within the site?
• May administrators access an external configuration service?
• Is temporary external access allowed during installation or maintenance?
• Must the system start from a powered-off state without internet access?
• Which functions must remain available during an outage?
• Who may access historical data, and through which approved route?

Do not settle these questions by treating “local,” “private cloud,” “self-hosted” and “offline” as interchangeable. Give each required function its own acceptance condition.

Draw the intended path and mark the unknowns

A candidate design to discuss is: Q1 Gateway, then a customer-operated MQTT broker, then a subscriber application and local storage. The broker, subscriber and database are distinct responsibilities even when they run on one server.

The Q1 FAQ, checked on 6 October 2026, documents configurable broker address, port and topic settings and Gateway transport over LAN or Wi-Fi. That supports reviewing a customer-selected broker path. It does not settle the deployment, security or offline behavior of the complete solution.

For each arrow in your architecture, request the actual direction, endpoint, purpose and operator. Include management and support traffic, not only the position stream.

If a component has no assigned operator, mark it unresolved. A box drawn inside a site boundary does not make it maintained.

Review security against the actual implementation

Ask for the exact supported authentication and encryption options on the proposed device and firmware. Do not infer a TLS version, certificate workflow or access-control capability from the fact that a product uses MQTT.

Your IT team should review how broker permissions, device identity, administrative access and network segmentation are implemented in the selected architecture. Any compensating controls need their own review; they should not be represented as a capability built into the gateway.

Keep production credentials out of a requirements document. Reference the approved secret-management process and describe who provisions, rotates and revokes access. Agree how diagnostic data will be redacted before it leaves the site.

For worker-location uses, the review should also address access, purpose, retention and applicable privacy requirements with the organization’s responsible specialists. Hosting data locally does not by itself establish legal compliance.

Test the dependency you actually care about

A successful demonstration on a local network does not establish fully offline operation if an unnoticed external service remains reachable. Ask the IT owner to design an approved test in an isolated test environment, with the required connectivity conditions documented.

Useful scenarios to agree include:

1. Normal operation: Confirm position delivery, storage and the user function on the intended path.
2. Internet unavailable: Identify which required functions continue, degrade or stop.
3. Fresh start: Determine whether the necessary components can start under the required access restrictions.
4. Broker or subscriber restart: Observe data gaps, reconnection and application staleness behavior.
5. Recovery: Check whether history contains a gap, duplicate or replay and how the application represents it.

Do not assume buffering or automatic replay. Record observed behavior and compare it with the requirement. These are proposed tests for an authorized test environment, not instructions to interrupt a production network or disable security controls.

Assign the operating responsibilities in writing

The names matter more than the example job titles. A small site may assign several duties to one team, but the responsibilities still need to be explicit.

Confirm what the commercial scope includes: hardware configuration, broker deployment, application development, monitoring, updates and recovery support. A developer kit purchase and an operated site solution can leave very different responsibilities with the buyer.

Make the approval conditional on evidence

The useful output of this review is a short list of verified paths, accepted dependencies and unresolved requirements. If external access is prohibited and a required step still depends on it, resolve that before procurement rather than assuming it can be removed later.

Reviewing an on-premises RTLS deployment? Share your network and operating requirements with GrowSpace. Include the local-only functions, permitted external dependencies, proposed server ownership and the evidence your IT review requires.