StockoutRadar — How it works & Security

The model

Self-hosted, not cloud SaaS.

The big visibility platforms work by having you upload your commercial data to their cloud. StockoutRadar works the opposite way: the software is installed and runs inside your own environment, reading your stock data from your own databases. The only thing that comes in from outside is public vessel and port tracking data. Your supplier relationships, pricing, and stock positions never go out.

▢ External · read-only

Public tracking feeds

Live maritime & port data pulled in by the engine.

Vessel position / AIS
Port arrival schedules
ETA updates

DATA IN

one direction

▣ Your environment

StockoutRadar engine + dashboard

Installed on your server. Reads your stock data locally, joins it to the tracking feeds, calculates runway, and renders your dashboard & alerts — all in-house.

Runs on your infrastructure
Connects to your existing database
Your stock & supplier data stays put
Nothing sensitive is sent out

Data flows in from public feeds. Your commercial data does not flow out. There is no StockoutRadar cloud holding your information.

Security principles

Designed so the sensitive data never moves.

🔒

Your data stays local

Stock levels, pricing and supplier detail are read from your own database and stay within your environment. We don't host, copy, or transmit them.

↓

Inbound feeds only

The only external data is public vessel and port tracking, pulled in read-only. No outbound channel for your commercial data exists in the design.

⚙

You control the box

It runs on infrastructure you own and administer. You hold the access, the credentials, and the off switch.

◷

Transparent on third-party data

Tracking feeds come from third-party sources whose accuracy is outside our control. Alerts are decision-support estimates — clearly flagged as such, never presented as guarantees.

What an install needs

What your team provides.

Deliberately lightweight — no rip-and-replace of your existing systems.

Where it runs

A server or VM in your environment [confirm spec once build is finalised — e.g. Docker host, RAM/CPU]

Data access

Read access to your stock/inventory data — via a simple export template or a read-only connection to your existing database (e.g. SQL Server, PostgreSQL).

Outbound network

Ability to reach the public tracking feeds (read-only). No inbound ports need opening to the outside.

From you, at setup

A mapping of which shipments carry which SKUs, and rough consumption rates — so runway can be calculated against your real stock.

Tech stack

[Fill in once locked: containerised app, dashboard layer, etc. Keep this honest and specific.]

Common questions

What IT and operations usually ask.

Does our stock or pricing data leave our network?

No. The engine reads your data locally and keeps it within your environment. The only data crossing your boundary is inbound public vessel/port tracking. There is no cloud account holding your commercial information.

Do we have to replace our current systems?

No. It sits alongside what you already run. It reads from your existing stock data — either a periodic export or a read-only database connection — and doesn't change your ERP or warehouse system.

What happens if a tracking feed is wrong or goes down?

Alerts are decision-support estimates, not guarantees, and are labelled that way. If a feed degrades, the dashboard shows it. You always remain responsible for the operational call — the tool surfaces risk earlier, it doesn't make decisions for you.

Who can access the system?

It runs on infrastructure you control, so access is governed by your own administration. [Add specifics once build is locked: user logins, roles, etc.]

What support do we get after install?

For foundation clients, hands-on: we keep working it until it runs correctly on your data, at no extra charge. Ongoing, an optional maintenance package keeps it running as third-party feeds change over time.

It runs inside your environment. Your data never leaves it.