On-prem runtime security: what leaves your network

Before an integration runtime goes inside the network, a security review asks what it will send out and what it needs from the outside. Here is how the On-Prem Worker answers both: what it sends, what it listens on, and what it does when the internet drops.

How much memory, CPU and disk it uses is covered in On-prem integration runtime resource usage: memory, CPU and disk, measured.

Run status, diagnostics, record counts and integrity receipts. Record contents stay with the On-Prem Worker, unless a flow uses something that lives in the Neblex cloud: a Data Table, or a webhook answer, form page or App result shown to someone through it.

• The On-Prem Worker opens one outbound, encrypted WebSocket (wss) connection to the Neblex cloud on port 443, over TLS 1.3 with a post-quantum key exchange. It opens no port to the internet.
• It proves its identity inside that connection with two keys created on its own machine, which never leave it: the key for the certificate Neblex issues it, and a post-quantum key.
• Its only listener on a standalone install is a local console bound to 127.0.0.1, which other machines can't reach. Members of an On-Prem Worker cluster also accept a link from the other members of the same cluster.
• Every run on it is reported in local custody: the cloud gets a compact run report, and the records stay with the On-Prem Worker.

Whatever each flow is built to send, directly. The On-Prem Worker connects to every system a flow uses on that system's own port: HTTPS on port 443 for most SaaS APIs, 5432 for a hosted PostgreSQL database, and the usual ports for local databases, queues and file servers. A flow that writes contacts and deals to a CRM calls the CRM's API; a flow that loads rows into a cloud PostgreSQL database connects to it on port 5432.

Those records leave your network because you chose that destination, and they travel from the On-Prem Worker straight to it, never through the Neblex cloud. Plan outbound firewall rules around your flows' destinations as well as the one connection to the Neblex cloud.

On your machine. Records do pass through the On-Prem Worker, and a large batch is buffered in its local run journal on your disk until the run is settled. They don't go to the Neblex cloud.

The On-Prem Worker purges the journal once the run is settled, so batch data doesn't accumulate on disk. Apart from the Data Tables you choose to use, Neblex doesn't store your records; anything that must persist lives in your own database.

The run keeps going, and only the status reports wait. The flow executes on the On-Prem Worker, not in the Neblex cloud, so the connection to Neblex isn't in the data path.

• The On-Prem Worker keeps reading from and writing to every system it can still reach.
• It keeps its run reports in its local run journal and delivers them once it reconnects.
• The run's final status reaches the Neblex cloud with the rest of those reports.

A step that needs the Neblex cloud itself, such as a Data Table step or a form a person fills in, waits for the connection and then continues. No step fails because the Neblex cloud is out of reach.

Recovering from a failed step, rather than an outage, is covered in Replay from the failed step, not from record one.

The On-Prem Worker also keeps a local, encrypted copy of the scheduled, polling and streaming flows placed on it, so it starts them itself while the cloud is out of reach. Flows started by a webhook, a form or a person in the app come in through the Neblex cloud, so they start once it's reachable again.

Other local runtimes also keep running when their platform is out of reach. Ask any vendor to show you what theirs does.

Yes, the same way flows do. An AI agent runs on the On-Prem Worker as a step in a flow, and both models it depends on can run inside your network too: the large language model (LLM) that does the reasoning, such as an open-weight model behind an OpenAI-compatible or Ollama endpoint, and the embedding model that turns your documents and records into vectors for the agent's knowledge base. Those vectors are stored in your own PostgreSQL database with pgvector, and the agent's long-term memory is stored only in your own database.

Set up that way, an AI step sends no more out of your network than any other step: prompts, model responses, records, documents and embeddings stay on premises, and the Neblex cloud gets the same run status it gets for any other flow.

If an agent uses a hosted provider for either model instead, whatever is sent to that model goes to that provider. Pick one whose data residency fits your rules, or keep the model local.

• Does the integration run on your machine, or are records relayed to the vendor's cloud to be processed?
• Which ports does the runtime open, inbound and outbound?
• Which destinations and ports will your flows need opened outbound, and does any of that traffic pass through the vendor?
• What exactly is in its run reports?
• What happens to a running job when the internet drops, and to a scheduled one?
• Where is an in-flight batch held, and when is it deleted?
• Can AI agents, and both the reasoning and embedding models they use, run inside your network the same way flows do?

Ask to see the answers in the runtime's logs and network connections, not only in the documentation.

• On-Prem Workers, Neblex Integration Fabric docs
• Offline controls, Neblex Integration Fabric docs
• AI agents guide, Neblex Integration Fabric docs
• On-Prem Worker architecture and run reporting, as designed and documented by Neblex engineering.

Last checked: October 22, 2026.