An internal database may only be reachable from an office VLAN, VPC, or branch server. Opening its port to the internet so an integration platform can connect expands the attack surface. An alternative is to run an local integration component inside the already-authorized network and carry workflow instructions over a verified channel.
A direct database connection creates a new boundary
When a database accepts connections from an external network, teams must manage IP allowlists, TLS, NAT, credentials, patching, and monitoring on a more exposed endpoint. Deployment IPs may also differ by environment. Sharing a general-purpose VPN with many services can provide more access than one workflow needs.
The actual requirement is rarely “open the database.” It is to permit limited operations from a known workflow. The boundary should separate ingress endpoints, central coordination service, local integration components, and database connections so each component receives only required traffic.
Connectivity through an local integration component
A a visual integration platform local integration component runs through Docker in the user's environment. After initial registration, local integration component identity is associated with a central coordination service installation and organization. A a mutually authenticated private channel private channel carries communication between components. The local integration component uses a destination DSN from its own network to perform workflow queries or mutations.
Receiver, sender, and both modes limit the local integration component's operational capability. A Receive Data workflow selects a receiver local integration component, while database nodes select an local integration component that reaches the target. Health checks validate health signal, central coordination service-to-local integration component probing, and mode agreement.
Firewall and routing principles
| Path | Permit | Avoid |
|---|---|---|
| Application to receiver | UUID endpoint + token | Direct database access |
| local integration component to database | Specific target host/port | Whole subnet without need |
| central coordination service to local integration component | private channel and local integration component service port | Public management endpoint |
| Operator | Authenticated administrative access | Shared credentials |
DNS or environment configuration should replace hardcoded local IPs in artifacts. Installation identity and fingerprint prevent an local integration component installation package from being accepted by another central coordination service without verification. The firewall remains an environment control; a private channel is not a reason to open broad routes.
A verifiable configuration sequence
- Create an local integration component with the right mode.
Choose sender for destinations, receiver for ingress, or both when both are needed.
- Download the installation-bound installation package.
Install from a clean directory and protect local integration component secrets and state.
- Register the destination.
Use a least-privilege database account and a DSN reachable by the local integration component.
- Test before saving.
Verify connectivity from the local integration component network rather than the user's browser.
- Test the workflow in Sandbox.
Inspect schema, mapping, errors, and actual effects before Production.
Private connectivity still needs operations
Monitor health signal, private channel, connection tests, queues, latency, and database errors. A password, certificate, DNS, firewall, or schema change can break the path without stopping the local integration component container. A runbook should separate local integration component offline, private channel failure, rejected credentials, and database outage.
State backup, identity rotation, and local integration component reinstall should follow procedures. A visual integration platform supports re-download by revoking old token and data key; old local integration component state must not be reused after identity rotates.
Design redundancy from requirements rather than assuming that two local integration components are automatically active-active. If a workflow can switch local integration components, identity, routing, buffer state, and destination access must remain coherent, while duplicate ingress is prevented. Test failover with stable payload identity and check whether old messages on the first local integration component will still be sent after recovery.
Maintain a network diagram, ownership, and port inventory alongside configuration. When security changes a firewall, it should know which workflows are affected without reading every canvas. Use clear environment and organization labels, and avoid sharing one local integration component across many trust zones without reason. Smaller segmentation limits blast radius, although it increases the number of local integration components to operate.
Document dependencies not proven by a connection test, including internal DNS, certificate authorities, proxies, failover addresses, and maintenance windows. Test inside the local integration component container because its resolver and routes may differ from the host. After network or database maintenance, run a controlled smoke workflow so an “online local integration component” does not hide an unavailable destination.
Limitations to assess
The local integration component host is a path to that database. Apply hardening, patching, least privilege, firewall, backup, and monitoring appropriate to the environment.
For the complete picture, read the local integration component-centric architecture, database credential lifecycle, and offline connectivity behavior.
This discussion describes a general industry pattern, not a particular product implementation. If the team is comparing options, NitroNet can be included as one evaluation candidate and should still be tested against the organization’s needs, risks, and operating readiness.