Technical
One binary, one database, nothing more to run
What your team will have to keep running: one binary and a PostgreSQL. No extension to compile, no message broker, no cluster. You keep control of where the hub lives, of its availability and of your fleet's data: no outside platform is needed to open an access. And an agent that refuses what it must not do, even when the order comes from the server.
The agents come with it, and it is the hub that distributes them to your fleet. Each one acts as a door onto its local network: a PLC, an HMI or a camera is reached through it, with nothing to install there and no port opened. The portal is on our side: your licence lives there, with the signed binaries. The hub only connects to it if you ask it to - a setting, off by default - and it then proves it carries a valid licence without ever transmitting it. On a network cut off from the internet, that link does not exist and the binaries are dropped by hand.
The hub, the agents, the portal
A server you install, agents placed on your machines, and a portal we run for your licences and your binaries - that is all. None of your data passes through ours, and an agent also reaches what lives behind it: the equipment on its local network, which has nothing installed on it.
One binary and a database, nothing else
That is all PipeLinker Hub is on the server side: a native executable carrying the server and its web console, and a PostgreSQL database. No cluster to size, no message queue, no distributed cache, no engine to install around it.
That makes it deployable just about anywhere: a virtual machine, a physical server in your room, a systemd service, your usual orchestrator, or a network entirely cut off from the internet. One instance keeps your fleets apart from one another, without installing one per customer or per site.
The hub serves its own TLS: it reads a certificate and a key in a folder, and what puts them there is none of its business - certbot, an enterprise PKI, or a reverse proxy in front of it if you already have one.
What the diagram shows
The portal is on our side: it carries your licence and the signed binaries. The hub only connects to it if you ask it to - the setting starts off - and it then proves it carries a valid licence without ever transmitting it. On a network cut off from the internet, that link does not exist and the updates are dropped by hand.
The server orchestrates; the agent executes. Both share the same code, and therefore the same validation rules: the two ends of the chain do not drift apart when a version changes.
A database your team already knows
PipeLinker Hub installs on your premises. Your fleet inventory, your metrics, your positions and your session recordings pass through no third-party service - and above all, they are stored in PostgreSQL, not in a proprietary technology you would have to learn to operate.
What your operations team gains
Your existing procedures apply
Backup, restore, monitoring, replication: your team uses the same tools as for its other databases. No specific runbook to write, no training, no on-call duty on a technology nobody knows in-house.
One component to run
PipeLinker Hub is a service and a database. No cluster to size, no message queue, no distributed cache to watch. A deployment of 1,000 devices fits on a modest machine.
Your data really is yours
PostgreSQL is under a permissive licence, and we use no extension that would restrict what you can do with it. You query your database directly with your BI tools, you create your own views, you export what you want, when you want. Some solutions on the market rely on components whose licence forces them to forbid you from changing your own schema - that is not our case, and it was a design criterion.
No legal surprise
No licence for your procurement department to vet, no clause to pass on, no component with an ambiguous status in your software inventory.
Why not TimescaleDB
The question comes up often, since we store time series. The extension is technically solid, but what would justify adopting it is not under a free licence: the Timescale License restricts redistribution and commercial use.
For a product delivered on your premises, that would mean imposing those terms on you - and an extension to install, absent from a good share of managed PostgreSQL offerings.
So we handle the aggregation and purging of time series ourselves, on plain PostgreSQL. A little more work on our side, no legal constraint on yours.
Tell us what equipment, behind which networks. We show you the console on it.
What it consumes, on your premises
PipeLinker Hub handles from 1,000 to 40,000 devices per deployment. The collection interval is adjustable per agent: a few minutes for fleet monitoring, closer together for critical equipment. The connection to the devices stays open continuously: commands and remote access do not depend on the collection interval, and remain possible even on a fleet polled every ten minutes.
Raw data is aggregated and then purged according to the retention you choose: a long history without a database growing indefinitely.
We provide a sizing table (processor, memory, storage) by device volume and by retention period, so that you can provision before committing.
And no implicit trust, including towards our own components
What precedes describes what runs and where. What follows describes what each link refuses to take on trust: that is where the difference lies between an administration tool and a product you let touch a machine in production.
One identity per device, never a shared key
Every agent carries its own client certificate. Not an API key shared by ten thousand devices, whose leak from a single one would compromise the whole fleet. Revocation is individual and immediate.
The private key is generated on the device and does not leave it; the certificate is short-lived and renews itself. No durable token to steal from a configuration file.
A consequence to know before deploying
A client certificate only exists in the TLS handshake. A reverse proxy that terminates TLS erases it, and no agent connects any more. The console's name, for its part, goes behind a proxy like any other site. That is the main thing to know when placing the hub in an existing infrastructure.
Your hub signs these certificates itself, through an authority of its own per fleet, or hooks into the trust chain your organisation already runs. In both cases the authority is yours: the hub runs on your premises, and what it generates leaves no more than what you give it. One identity per device, compatible with your PKI
A binary does not install unless it is signed
A remote update is, literally, arbitrary code execution across a whole fleet. What protects you is therefore not the channel - it is already authenticated and encrypted - but the proof that the binary really comes from whoever claims to have produced it.
Two checks, and they do not serve the same purpose. The hash protects against accident: a truncated download, a lying disk, a stale mirror. It protects against nothing else, since it travels the same path as the binary - whoever holds that path holds both.
The signature protects against malice. It can only be produced by the holder of the private key, which is neither on the portal, nor on the hub, nor on the agent. A compromised hub can lie about everything, it cannot sign.
The verification key is in the binary, not in a setting
The public key is compiled into the agent, and into the hub for its own update. A key placed in a configuration file would be replaced by that of whoever wants to sign whatever they like, and the verification would prove nothing any more: going around it then requires rebuilding the binary, which is the level at which we decided to stop.
Without a compiled key, every update is refused. The default is closed: a binary that cannot be verified is a binary that is not installed. Neither an agent nor a hub updates itself on a binary whose signature does not match.
Three checks, and only one that decides
The portal refuses an upload whose signature it does not recognise, and the hub does the same with the binary handed to it: the mistake is caught in front of whoever makes it, not weeks later on a distant machine.
But neither of them is the authority: they hold no signing key. The only one that decides is the check made at the end, on the machine, with a key nothing above can influence.
How a person signs in
A password, then a second factor by one-time code - the one the usual authenticator applications produce. Ten backup codes come with enrolment: enough to last until a phone is replaced.
The order matters, and it is checked. The code is asked for before the session is opened: the other way round would leave a session open to someone who only knows the password.
The agents are not concerned: they authenticate by certificate, with nobody in front of the screen. One identity per device, compatible with your PKI
Least privilege
Rights are set by fleet, by group and by action, and handing out rights is itself a right - that is what makes it possible to entrust a fleet to an administrator without entrusting them with the rest of the installation. The initial administration account is exempt from it: without that exception, inadvertently removing the last permission would close the door for good.
The interactive shell is treated as what it is, a powerful capability, and stays reserved for the roles that warrant it.
Partitioning between organisations is strict, with session expiry, key rotation, rate limiting and controlled storage of secrets.
Rust, for what it removes
The server and the agents handle networking, cryptography and data coming from outside - exactly the ground of memory overflows and corruption. Rust eliminates that family of flaws by construction, without imposing the overhead of a garbage collector: the footprint stays small and predictable, including on a modest ARM unit.
The hub defends itself, and says so
A hub is a door onto a fleet, and a door gets probed. The hub keeps two distinct logs: the access log - who signed in to the console, when, from where, and who failed - and the security log, which counts refusals by origin, keeps host-key changes and an administrator's decisions, and survives the purge of operational data. An overview on a sliding window gives the totals by nature and the origins that insist.
Prise 10
Brute force is counted, and cut off. Everything that takes a code typed by hand - a password, an enrolment code, a second factor - is limited to five attempts per address per minute. Beyond that, fifty refusals in five minutes from the same origin are no longer noise: the severity rises, and the address is blocked by itself, for a period that lengthens if it starts again. An administrator can also block an address by decision, or put one on a whitelist the threshold will never touch; private networks are on it by default, and the hub refuses to block the address it is being spoken to from - you do not lock yourself out.
Prise 11
What is critical comes up. A host-key change that makes a session fail, an origin that insists, a critical security event: each produces a notification, sent by e-mail if a relay is configured, and the log line stays even if the notification is lost. What someone typed into a password field is never written down: it is often somebody else's real password.
What the fleet's security lets you demonstrate
Knowing what runs, being able to fix it fast and to prove it, is no longer merely good practice: it is what the Cyber Resilience Act will require of manufacturers. What the regulation asks
Page last updated on 22 September 2026. Technical page, maintained by the PipeLinker team at LOOTUS SECURITY, publisher of the product. The date comes from the repository, not from a hand edit.