A New Network Edge for Customer-Owned Hardware

On September 18, 2024, we placed a new network edge into service at the Elizabeth facility. The project added dedicated 1 Gbps upstream transit, Helixrack-operated BGP, provider-independent IPv6, and remote peering to DE-CIX New York through an upstream New Jersey access point.

For customers, the immediate benefit was a network foundation we could operate and document more deliberately. The standard server handoff remained a shared 1 Gbps port, while addressing and routing options could be reviewed against the needs of each deployment.

What changed at the facility edge

Our first room used 500/500 Mbps business fiber and a provider-assigned IPv4 block. That circuit gave the early operation a workable starting point, but addressing and routing remained closely tied to the access provider.

The September project separated those functions. A dedicated 1 Gbps transit circuit became the production upstream, and we began operating BGP at the facility edge. Provider-independent IPv6 gave us an address plan that could move with the network rather than being defined by one access circuit.

The change was at the facility edge. A standard customer plan still used a shared 1 Gbps handoff, and each server kept the network configuration confirmed for its service. Dedicated throughput, custom routing, and routed IPv4 remained configuration-specific options rather than implied features of every rack position.

Remote peering, accurately described

The new edge also reached DE-CIX New York remotely through our upstream’s New Jersey access point. The upstream provided the path to the exchange; Helixrack did not install a direct exchange cross-connect in Elizabeth.

That distinction matters because “peering in New York” can sound like physical equipment or a dedicated port at the exchange. Our operating record separates the Elizabeth edge, the upstream transport in New Jersey, and the remote exchange relationship. It lets us describe what was active without overstating where the connection lived.

Prefixes, neighbor addresses, credentials, routing policy, communities, and management design stayed inside the network record. Customers received the addressing, gateway, handoff, and support details needed for their own approved configuration.

Turn-up was separate from customer migration

Bringing the edge online did not force an address or routing change onto an installed server. We treated infrastructure turn-up, internal validation, and any customer migration as three separate decisions.

The facility work established the new circuit and routing sessions. Validation checked the intended upstream path, route visibility, monitoring, and rollback conditions. A customer change happened only after the affected configuration, timing, success checks, and way back had been agreed.

Keeping those stages separate reduced unnecessary change for existing customers. It also made later troubleshooting clearer: the record showed whether an observation belonged to the new edge, the customer handoff, or the workload beyond it.

What stayed the same

Customers continued to control their operating systems, firewalls, applications, credentials, and data. We continued to own the approved facility-side network handoff and the work performed at the edge.

The project expanded our routing options; it did not create a committed-throughput or uptime guarantee. Each accepted quote still identified the port, address assignment, optional network service, and customer responsibilities for that machine.

The September turn-up gave Helixrack a stronger network foundation without making the service harder to understand. For current port and addressing options, review pricing and send the exact network requirements with your pre-ship request.