EDI Processing — Bare-Metal Datacenter
A supply chain client had five racked servers in Neptuno's Puerto Rico datacenter and nothing on them. We built the entire EDI platform from the operating system upward — a MongoDB replica set, OpenAS2 and a Node.js processing application in an active/hot-standby pair, and a Prometheus, Loki, and Grafana stack sharing the fifth node with the bastion — with every management port closed to the internet and reachable only through FortiClient VPN. No cloud fallback: the platform has to run and recover inside the datacenter perimeter.
The situation
This was a greenfield build in the literal sense — the client had colocation space, five racked servers, and no environment at all. Nothing existed to migrate from and nothing existed to fall back to, so every layer had to be designed before it was installed: operating system baseline, storage layout, network segmentation, database replication, application failover, monitoring, and remote access. The cost ceiling was the binding constraint. Five servers is not enough to give each role its own node, so the design question was not which components to run but which ones could safely share a machine without a single failure taking two responsibilities with it. EDI made the stakes concrete: a missed or delayed transaction is a trading partner SLA breach, not an internal inconvenience, and there was no managed control plane to lean on for any of it.
A full production EDI platform live within the five-server budget, with tested failover, end-to-end observability, and no SSH port exposed to the internet.
How we worked
Stabilise delivery early, then build the foundation that keeps it stable once we hand it back.
Mapped every workload against the five available servers before any software was installed, then allocated to maximize redundancy inside the budget: two for MongoDB, two for the application layer, and one multi-role node carrying the bastion, VPN termination, and the monitoring stack. Roles were paired only where their failure modes are independent — nothing that had to survive a single node loss shares a machine with something else that does.
Installed and hardened a common {{TODO: distro and version}} baseline across all five nodes: partitioning and storage layout sized for EDI message retention, NTP so transaction timestamps agree across hosts, kernel and sysctl tuning, unattended security updates, and a locked-down SSH configuration with key-only authentication. Every node came up from the same baseline so a rebuild is a repeatable procedure rather than an archaeology exercise.
Configured a MongoDB replica set across the two database nodes — a primary and one read replica — with replication lag monitoring and alert thresholds tuned to catch divergence before the application notices it. {{TODO: confirm whether an arbiter runs on the fifth node to give the set an odd voting count for automatic elections, or whether promotion is manual}}. Authentication, role-scoped users, and an on-node backup schedule with restores tested against {{TODO: restore target / cadence}} were part of the same build.
Deployed OpenAS2 and the Node.js EDI processing application on the active node, with a fully synchronized hot-standby holding the same configuration, certificates, and partner profiles, ready to take over. AS2 identities and trading partner keys are kept in sync between the pair so a promotion does not require re-onboarding partners. Wrote and tested a failover runbook that promotes the standby with a single command.
Wired the AS2 receive path through to the Node.js processing layer and MongoDB, with {{TODO: how documents are picked up and acknowledged — e.g. MDN handling, retry policy, dead-letter queue for unparseable documents}}. Documented the partner onboarding procedure — certificate exchange, endpoint configuration, and a test transaction — so the client's team can bring on a new trading partner without us.
Consolidated Prometheus, Loki, and Grafana on the fifth server alongside the bastion role. All five nodes ship metrics and logs to this host, with dashboards covering EDI transaction rates, MongoDB replication lag, application health, and bare-metal fundamentals — disk headroom, memory pressure, and hardware health, which have no autoscaler to hide behind on owned hardware. Alerts route to {{TODO: alert destination and on-call arrangement}}.
Locked all SSH access behind FortiClient VPN so no management port is reachable from the public internet, leaving the bastion as the single entry point into the estate. Worked with the datacenter's firewall team to harden ingress rules down to the AS2 listener and the partner IP ranges that need it, and documented the resulting access policy.
Exercised the platform before it carried live traffic: promoted the standby application node, failed the MongoDB primary, and confirmed transactions resumed without loss. Handed over runbooks for failover, restore, partner onboarding, and routine maintenance, plus a rebuild procedure for any single node. {{TODO: describe the support arrangement after handover, if any}}.
Handover
Stack
Afterwards
Measured after handover, once the client's own team was running the system without us.
Tell us what you are trying to move, migrate or automate and we will reply within one business day with an honest read on the work — including the parts we think you should not do.
More engagements
Production-ready Azure platform live in 9 weeks with zero manual click-ops and a sub-15-minute release pipeline.
Read the case study GCP Production InfrastructureFully automated, production-ready GCP platform delivered in under 8 weeks with 100% IaC coverage.
Read the case study