Frequently asked questions
The questions you are asking yourself
What comes up most often before deciding. If yours is not here, write to us with your situation - the kind of equipment, the network, where you can host, who needs access - and we will answer on that.
Deployment
What it takes to run it on your premises, and what it does not.
Is PipeLinker a gateway or a bastion?
Both, and they are two distinct functions rather than two products. The gateway gathers: the agent placed on an IT, OT or IoT machine calls the hub outbound, reports its state and makes reachable whatever lives behind it. The bastion controls: who enters, on which target, with which rights, and what is left of it in the log. The hub carries both, and that is why there is no port to open: what connects and what controls are in the same place. The word the industry uses today for the second half is ZTNA, Zero Trust Network Access; the question « Is this ZTNA? » says what it covers here, and where it stops.
Do we need to open a port on the remote site?
No. The agent itself establishes an outbound, encrypted connection to the hub, and everything goes through it: telemetry, commands, updates, remote access. No inbound port to open, no firewall rule to obtain, no fixed address to ask the carrier for.
Where is the data stored?
On your premises. PipeLinker Hub is self-hosted: one binary and a PostgreSQL database, on the machine of your choice. Your PostgreSQL backup and monitoring procedures apply as they are.
Does the product work without internet access?
Yes. Nothing calls an outside service to work: a fully isolated network is fine, which is the common case in industry. The agent and application binaries are then dropped onto the hub by hand.
How long does the installation take?
One public address, two names pointing at it - the console and the agents' door -, a certificate covering them, a PostgreSQL database, and the hub's Debian package, which sets the rest up in seven questions. A team that already runs a server does it alone, with the documentation; the onboarding we offer is bought to go fast and sleep well, not because it is indispensable.
How do the hub and the agents update?
The agents update from the hub, through a progressive rollout you trigger: a canary, a test group, then the rest, and every binary is signed before being accepted. The hub itself can fetch versions from our portal if you enable it - a setting, off by default, four checks a day that you can adjust - or receive the files you drop yourself.
Why PostgreSQL alone, and not TimescaleDB?
Because the TimescaleDB features that would justify adopting it are not under a free licence, and a product delivered on your premises would then impose its terms of use on you. We stayed on plain PostgreSQL, with our own aggregation tables.
Compatibility
The machines, the systems, and what lives behind the agent.
Which systems does the agent run on?
Linux and Windows, on x64 as on ARM64, with the same native binary and the same protocol - embedded systems included. And Android, on ARM 32 and 64, x86 and x64, for purpose-built devices: kiosks, rugged terminals, production tablets.
What does the Android agent do, and what does it not do?
It carries telemetry, application inventory, commands, signed updates, a terminal, files and tunnels to equipment on the local network - within the limits Android leaves to a non-rooted application: the terminal runs under the agent's identity, in its sandbox, and the files are the folders the device has granted. It does not serve its own screen - that is a permission the agent does not ask for - but the screen of equipment behind it is reached through the tunnel, as from any other agent. The table on the agents page says it box by box.
Can we reach the web interface of equipment behind the agent?
Yes. The hub opens the equipment's web HMI in your browser, through the agent's connection, with no VPN and no client to install. The access is authenticated by the hub and traced like the rest.
What about PLCs that cannot carry an agent?
An agent on a machine of the same network acts as their gateway. You declare the service in the console - its address, its port, its protocol - and it becomes reachable through the agent: web interface, SSH, SFTP, VNC, RDP, or a raw port. Nothing to install on the PLC, and nothing open on the site.
Can we keep our usual tools, PLC client or remote desktop?
Yes, with PipeLinker Desktop on the workstation. It opens a local proxy for your browser and forwards a local port to a declared service: your PLC client, your database client or the vendor's utility reach the equipment by name, with no address to rewrite. A remote desktop opens in the workstation's own client, in one click.
Is there a mobile application?
Yes, PipeLinker Mobile, on Android: the fleet, the map and the trips, the alerts. And on a machine, a terminal, the files, a VNC screen, an RDP desktop, the internal web pages. It enrols through a one-time code obtained in the console; the hub's password never goes in. Android only, for now.
Security
Who gets in, with what, and what is left of it.
How does a device authenticate?
By a client certificate of its own, never by an API key shared across the fleet. The private key is generated on the device and does not leave it. Revocation is individual and immediate.
Where does the private key live?
In the best shelter the machine offers. On the workstation, in the TPM - through the key store on Windows, through /dev/tpmrm0 on Linux -, then failing that the software store and a file sealed by DPAPI, or a file readable by the account alone. On Android, in the Keystore, tied to unlocking. On the agent, a file created with restricted permissions from the moment it is written. A backup restored elsewhere carries no identity.
What happens if a machine is compromised?
You revoke its certificate from the console, and the hub refuses it at the TLS handshake, before a byte is read. The other machines have nothing in common with it: each has its own identity, and each fleet its own certificate authority, which makes an identity from one fleet fail on another.
Where are the machines' credentials kept?
In the hub, and sealed. A declared service - SSH, RDP, VNC, a web interface - carries its login and its password, which the hub encrypts with a key that lives in its configuration and never in the database. The seal is bound to its row: the table, the column and the primary key go into the computation, so copying a sealed secret from one fleet onto another does not open it. The person intervening receives the right to open the session, not the password of the machine. What this protects: a stolen database, a replica, a backup taken by a third party, a managed database. What it does not protect, and it is better said: root on the hub, or code running under its identity, read the configuration just as it does.
Are sessions recorded?
Terminal and screen sessions are recorded and replayed, with a time cursor. A remote desktop decoded by the hub can be recorded or handed over in supervised mode, read-only. The rest - files, commands, web access - goes into the audit log: who, what, on which machine, when, for how long.
Is this ZTNA, Zero Trust Network Access?
In principle yes, in its full extent no, and the distinction is worth stating rather than leaving to the acronym. What is there: nobody reaches the network, only a declared service, target by target; the agent calls outbound, nothing listens on the site; every machine and every device carries its own certificate, the private key never leaves the hardware store it was born in, and the hub refuses an otherwise valid chain whose authority is not the one of the fleet the agent belongs to; rights are granted by role, by fleet and by target, with a second factor required by role, and withdrawn in one gesture. What is not there: the hub does not judge the state of the workstation someone connects from. Not its encryption, not its patch level, not its antivirus, and it re-evaluates nothing during the session. It does know where the workstation's key lives - security chip or plain file -, whether biometric unlocking is active on it and which version runs there: it records those facts, it does not make them a condition of entry. A ZTNA that judges posture demands an agent on the contractor's own workstation, which you do not administer. We chose identity and compartmentalisation over posture.
Who is allowed to do what?
Rights are granted by role and by fleet, to named people: view, open a session, send a command, deploy an update, administer. A second factor can be required by role. An access is limited to one destination and one duration, and is withdrawn in one gesture.
Can a contractor be given access for the length of the job?
Yes. The account carries an end date: once it passes, the account opens nothing, and a session already open is closed within the hour - without that sweep, an expiry at noon would really mean at noon, or whenever the browser is reopened. Expired is not deactivated: moving the date back is enough to let the account in, with nothing else to undo. Operations are warned before the deadline, seven days by default and adjustable, and the message goes to those who can extend it rather than to the person losing the access. An administrator cannot carry a date: that is a database rule and not a console one, so a hub is never left with nobody able to enter it.
Does the product help answer the Cyber Resilience Act?
On the part the fleet must be able to say, yes: inventory of installed packages with a normalised identifier, CycloneDX export per machine, search for a package across the whole fleet, signed updates and an audit log. It does not produce the SBOM of your own software and does not itself match against vulnerability databases.
Licence
What is counted, what is not, and what happens at expiry.
What does the licence count?
Devices - a machine where the agent is installed -, accounts, isolated fleets and declared services. Never sessions, connections or minutes: open ten terminals or two hundred, the bill does not move. The whole hub is in every offer; what varies is the size, and the two applications, Desktop and Mobile.
Do we need a licence per site, or per customer?
No. One instance, one licence, and one fleet per site or per customer inside it: each has its managers, its rights, its agents, and does not see the others. The number of fleets is a licence ceiling, like devices and accounts - two, three or ten depending on the offer, as many as there are customers on the custom one. It is generous at every step because a fleet is a logical partition the hub carries anyway: what makes the price is the machines and the accounts, not the partitions between them.
What happens when the licence expires?
The hub keeps running, and it never refuses to start. The agents stay connected, telemetry comes in, alerts work, the console opens and the fleet can be consulted. What stops is what touches a machine: opening a session, sending a command, enrolling a device. The console warns you thirty days ahead.
A question that is not here? Ask us