Procuros Bridge is a lightweight background service installed on the host or server that runs your on-premise ERP. It connects that ERP to the Procuros network without you having to write code, deploy middleware, or stand up an integration platform. You drop files into a local folder and the Bridge ships them to Procuros over SFTP; documents coming back from Procuros arrive in a local folder the same way. Install it once — it keeps itself up to date automatically.

​

What it does

The Bridge automates secure, bidirectional file exchange between your local folders and the Procuros network:

• Outbound: the Bridge watches a local folder your ERP writes into and uploads the files to Procuros.
• Inbound: the Bridge downloads documents from Procuros into a local folder your ERP reads from.

It runs unattended on a schedule, so once it is configured there is nothing for your team to operate day to day.

​

Use cases

The migration case is where the Bridge is most valuable. Migrations are awkward because not every trading partner can be moved on the same day, and not every document type can move at the same time as its partner. The Bridge handles both: it inspects each outgoing file and routes it per-file, so you can cut partners and document types over to Procuros gradually instead of all at once.

​

Why teams choose it

• No middleware to build or host. No integration platform, no servers, no custom code.
• Outbound-only networking. The Bridge initiates every connection itself, so there are no inbound firewall ports to open.
• Runs next to your ERP. It works against ordinary local folders on the machine that already runs your system.
• Low-risk, gradual migration. Per-file routing lets you phase a cutover instead of taking a big-bang risk.
• Self-updating. New versions install themselves; there is nothing to patch manually.

​

How it fits together

​

Supported platforms

• Windows (x64) — installed via an MSI; registers a background Windows service.
• Linux (x64) — installed via a .deb or .rpm package; registers a systemd service.

---

​

Technical details

The sections below are intended for infrastructure and security teams reviewing the Bridge for security, reliability, and maintainability.

​

Architecture

The Bridge is a single, self-contained executable — one static binary with no external runtime dependencies — that runs as a background operating-system service. On Windows it installs as a Windows service (ProcurosBridge) that starts automatically at boot; on Linux it installs as a systemd service. Configuration and monitoring happen through a local web UI the service serves on the loopback interface (127.0.0.1); the Bridge holds no open inbound network listener. It is local-first. Configuration and operational logs are stored on the host in a machine-wide, OS-protected data directory (C:\ProgramData\ProcurosBridge on Windows, /var/lib/procuros-bridge on Linux) — configuration as files, logs in a local SQLite database.

​

Connectivity and network egress

Every connection the Bridge makes is outbound-initiated — it never opens an inbound port. Outbound destinations: Test and Production are not separate servers — they are a parallel pair of folders on the same SFTP host.

​

Security

• Transport encryption. File transfer runs over SFTP (SSH). All platform API, telemetry, and update traffic runs over HTTPS, validated against the system root certificate store.
• Credential handling. SFTP credentials are stored locally on the host in the Bridge’s machine-wide, OS-protected data directory. Credentials are never included in telemetry or transmitted to Procuros logging.
• Signed, verified updates. Releases are cryptographically signed (Ed25519). The updater verifies the signature before installing; an unsigned or tampered update is rejected.
• Local-only control surface. The configuration UI and control API are bound to the loopback interface (127.0.0.1) and reachable only from the host itself — the Bridge never exposes an inbound network port. Installing the service requires administrator/root rights; thereafter it runs unattended under the operating system’s service manager.

The Bridge handles transport (SFTP / HTTPS). It does not perform EDI message-level signing or encryption such as AS2 — that layer, where required, is handled by the Procuros platform.

​

Reliability

• Scheduled sync. Files are exchanged on a configurable interval (5, 15, 30, or 60 minutes; default 5).
• Crash recovery. The operating system’s service manager restarts the Bridge automatically if it stops unexpectedly — Windows Service Control Manager recovery on Windows, systemd on Linux.
• Offline resilience. Operations and logs persist locally and retry. If the network or a downstream service is unavailable, the Bridge retries on the next cycle. Telemetry failures never block file transfer or the user interface.
• Safe transfers. The Bridge will not overwrite an existing file at a destination; on a conflict it leaves the source in place and retries, so files are not silently clobbered.

​

Observability and telemetry

The Bridge ships operational logs to Axiom in roughly 15-second batches so Procuros can support your integration. The telemetry is metadata only:

• Included: sync outcomes (success / skipped / failure), error types, timestamps, a per-installation identifier, platform, and Bridge version.
• Never included: file contents, file paths, or credentials.

The same operational logs are also available locally in the in-app log viewer, filterable by category (System / Import / Export) and free text.

​

Maintainability and updates

• Automatic updates. The Bridge checks for new, signed releases on an interval and installs them in the background. Stable and beta channels are available.
• Versioned configuration. Configuration is versioned with forward- and backward-compatible migrations, so upgrades and rollbacks are safe and do not discard settings.

​

Data handling summary

• Stored locally: configuration and operational logs, retained on the host until cleared.
• Transmitted to Procuros: business documents (via SFTP) and the metadata needed to route them.
• Transmitted as telemetry: operational metadata only, as described above.

​

Frequently asked questions