Edge Compute

Compute at the global edge

Dedicated hardware in our PoPs, and an edge runtime for code that belongs at the point of ingress. Both sit on the same fabric, with the same mitigation available as on your transit, and both are scoped with an engineer rather than picked off a shelf.

Behind the filterMitigation on the same port
Up to N×400GEPort capacity on bare metal
Global presenceEdge PoPs, more coming online
LocalPart of the fabric

Two ways to run

Hardware beside the filter, or code inside the datapath

One is a place for your own stack. The other is a place for your own logic. Both are reached through a conversation, not a form.

Bare metal

Dedicated hardware

Bare metal reserved for you inside our PoP, on our fabric, with the same mitigation available on its port as on a transit port. For the part of your stack that is better off where the traffic enters than a hop away from it.

  • Bare metal in a Wirescope PoP, reserved for you
  • High bandwidth: ports up to N×400GE, straight onto the fabric
  • Redundant ports, 10GE to 400GE
  • Native IPv4 and IPv6; your own prefixes and ASN welcome
  • Mitigation on the same port: managed, partial, custom or off
  • Dropped attack traffic never billed, with mitigation on
  • Cross-connects within interconnection facilities, e.g. Equinix
  • Point-to-point Ethernet and waves to Wirescope-connected sites
  • Real-time traffic analytics and the API, same as a port
  • Sized, placed, quoted and supported by the same engineers

Available on its own, or alongside the transit and mitigation you already have with us.

Talk to us about capacity

Code at the PoP

Edge runtime

Code that runs at the ingress PoP, in the datapath that delivers your traffic. The same place we already let you run filtering and steering logic, opened up to the rest of what you might want there.

  • Runs inline in the forwarding path, beside our stack
  • TCP, UDP and custom protocols, not only HTTP
  • Request routing, rewriting, validation and session handling
  • Small services, close to the traffic they serve
  • A parser for your protocol, or a classifier for your game
  • Runs beside our filtering in custom mode
  • Deployed over the API; analytics and alerting in the panel
  • Scales with the datapath that absorbs floods, at every PoP
  • Pay as you go: billed on what runs, nothing reserved up front
  • Early access: scoped with you, no public SDK yet

Discussed case by case while it is in early access.

Ask about the runtime

Why here

Close to the traffic, behind the filter, on the contract you already have

The case for putting compute at the edge is the same as the case for filtering there: the ingress PoP is where the traffic already is.

Behind the filter

With mitigation on the port, traffic reaches your workload after filtering has done its work, on the same path. Nothing has to sit in front of the filter to be reachable.

Where the traffic enters

At the ingress PoP, not in a compute region across the country. The hop from the edge to your code is inside the building.

Your routing stays yours

Your prefixes, your ASN, your policy. Compute joins the session you already run with us rather than bringing a second network of its own.

On its own, or beside your port

Take dedicated hardware alongside the transit and mitigation you already have with us, or on its own. Either way it sits on the fabric, with mitigation available on the port, on one contract.

Scoped with an engineer

Nothing here is self-serve. We work out what you need from the PoP, whether it fits, and what it costs, and we tell you plainly if it does not.

The same people

The team that runs the datapath is the team that scopes and supports this. Same NOC, same escalation, same contract as the port it sits behind.

How it starts

Tell us what you would run

There is no order form and no rate card. Each deployment is scoped by hand, and that is how yours will be too.

Already a customer? Raise it with the engineer you already talk to, or use the same contact form and pick Edge Compute.

  1. 01

    Tell us what you would run

    The workload, where its traffic comes from, and whether you already have a port or a tunnel with us.

  2. 02

    We scope it

    An engineer works out which option fits, what it needs from the PoP, and quotes it. If it is not a fit, we say so.

  3. 03

    It goes live beside your traffic

    On our fabric, behind the same filtering, watched by the same NOC that watches your port.

FAQ

Common questions

Bring us what you would run

Tell us the workload and where its traffic comes from. An engineer will scope it, quote it, and tell you plainly if it is not a fit.