ZeroKeep · On-premise
On-premise DDoS protection that never leaves your rack
ZeroKeep puts the zeroms.net filtering plane on hardware you already own, so hostile packets die in your own kernel instead of taking a detour to somebody else’s scrubbing centre. Always-on, protocol-aware, and 0 ms time-to-mitigate on the first packet.
- XDP / eBPF
- Kernel and application depth
- Prometheus and Grafana
Ingress
Your transit / peering
Mixed traffic arrives on your own interfaces.
ZeroKeep node
XDP, at the kernel
Hostile packets are dropped before they reach the stack.
Origin
Your game and app servers
Only legitimate traffic continues, on the local path.
0 ms
Time-to-mitigate, first packet
0 hops
Added to the path
XDP
Earliest drop point in Linux
Throughput depends on your NICs, your cores and what you are filtering, so we size the nodes with you on the quote call rather than quote a number here.
Why on-premise
The first drop should happen where you can see it
A remote scrubbing centre is a path you do not control
Sending traffic somewhere else to be cleaned means a detour, a dependency, and a set of routing decisions made outside your network. When it goes wrong you are reading someone else's status page.
On-demand appliances are asleep when it starts
Anything that has to detect first has a window where the attack is already in the room. By the time the sensor agrees with your players, the lobby has emptied.
Generic firewalls do not speak game
An ACL cannot tell a Source engine query flood from a busy server browser, or a Minecraft login flood from a launch night. Rate-limit it and you drop the players you were protecting.
You already own the rack
If the hardware, the prefixes and the transit are yours, the first drop should be yours too. That is the whole idea behind ZeroKeep.
Your prefixes. Your rack. Your first drop.
ZeroKeep does not ask you to hand anything over. No prefix moves, no tunnel comes up, and no traffic takes a detour through a network you do not run. The filter sits where your packets already are, and the decision plane stays yours.
- Protecting game servers since
2021
Protecting game servers since
Through Torchbyte, before zeroms.net existed
- Where we run it ourselves
AS215362
Where we run it ourselves
The same filtering philosophy, on our own network
- NOC, staffed by engineers
24/7
NOC, staffed by engineers
People with access, not a ticket queue
Where ZeroKeep sits
One filter plane, four layers deep
ZeroKeep is not a box in front of your rack. It is software on the hosts already carrying your traffic, positioned at the earliest point in Linux where a packet can be thrown away.
- Mixed
NIC and driver
Your hardware
Packets land on interfaces you own. Nothing has left the building yet, and nothing is going to.
- Flood dropped
XDP, in the kernel
Earliest drop point in Linux
Hostile packets are discarded before the kernel builds a socket buffer for them. This is where volumetric floods die, at line rate, without loading the rest of the stack.
- Abuse dropped
Protocol profiles
Kernel to application depth
What survives is checked against the profile for the service behind it — game handshakes, VPN control channels, query protocols — so abuse that looks like valid traffic is still caught.
- Clean
Origin servers
Your rack, local path
Clean traffic continues on the path it was already taking. No detour, no tunnel, no remote scrubbing centre in the middle.
Capabilities
What it actually does
Drops at line rate, on the local path
Filtering happens in XDP, the earliest point Linux will let you discard a packet. Volumetric floods are dropped before the kernel allocates anything for them, so a node absorbs millions of packets per second without the rest of the stack noticing. Clean traffic keeps moving with negligible added latency.
Scale sideways, behave like one filter
Add nodes as your edge grows. They share filtering state quickly enough that a cluster makes one decision rather than four inconsistent ones, which matters when an attack is spread across several interfaces.
Kernel depth and application depth
Reflection and amplification are handled low in the stack. Protocol abuse and application floods are handled by the profile for the service behind the port, so traffic that is technically well formed but obviously hostile still gets dropped.
Always on, 0 ms time-to-mitigate
There is no sensor to wake up and no threshold to cross. The filter is already running on the first packet, which is the same promise we make on our own transit network, moved onto your wire.
Metrics you already know how to read
A native Prometheus exporter publishes drop and pass rates, per-reason counters, CPU and interface saturation, and cluster sync state. Grafana dashboards ship with it. Nothing is hidden behind a vendor console you have to log into.
The same filtering philosophy we run ourselves
ZeroKeep comes out of the work behind AS215362 and Torchbyte, the game server provider this team has run since before zeroms.net existed. It is the protection we built because we needed it for our own players.
Profiles for what you actually run
The same protocol-aware inspection as our transit product, running locally. Game traffic is small, connectionless and bursty, which is also what an attack looks like to a generic filter. Profiles are how the two get told apart.
Running something not listed here? Ask for a custom profile, or see the full filter list.
Game profiles
- Source / A2S
- Minecraft Java
- RakNet
- FiveM
- AltV
- SA-MP
- DayZ
- ASA / ASE
- Palworld
- Hurtworld
- Path of Titans
- The Isle
- Arma Reforger
- SCP: Secret Laboratory
- Factorio
- Tibia
- TeamSpeak 3
Service and infrastructure profiles
- OpenVPN
- WireGuard
- SSH
- TLS
- RDP
- DNS
- NTP
- HTTP
- FTP
You watch it. We can watch it with you.
Your dashboards, your data
ZeroKeep publishes a Prometheus exporter and ships Grafana dashboards. Drop and pass rates, per-reason counters, CPU, interface saturation and cluster sync are all metrics on your own monitoring, not numbers behind a login we control.
Optional NOC watch
We staff a NOC around the clock. If you want a second set of eyes on your cluster, we will scope that with the quote. It is engineers on call, not a ticket queue.
Get QuoteDropped packets
Broken down by drop reason, so you can see what the attack actually is rather than only that one is happening.
Passed packets
Broken down by the profile that matched, so legitimate traffic is attributable to a service.
Drop reasons
Reflection, protocol abuse, profile miss, out-of-state, and the rest of the ruleset.
CPU per core
Headroom on every filter node, so you know when to add one.
Interface saturation
Per NIC, ingress and egress.
Cluster sync
Which nodes currently agree on filtering state.
All of it is scraped from your own monitoring. The Grafana dashboards we ship are a starting point, not the only way to look at it.
Getting it live
Deployment, as a runbook
- 01
Scope the wire
A call with an engineer, not a discovery deck. Interfaces, expected packet rates, which games and services sit behind them, whether you need HA, and what is already in front of the traffic.
- 02
Land the filter nodes
ZeroKeep goes onto Linux hosts you own or hardware we size with you. We are on the call while it happens. Node sizing is agreed on the quote call rather than guessed from a spec sheet.
- 03
Turn on profiles and exporters
Enable the protocol profiles for what you actually run, point Prometheus at the exporter, and bring the cluster into sync. Many deployments are live the same day; we confirm the timeline once we have seen your topology.
- 04
Stay on
Rule changes, new profiles as you add games, and an optional watch from our NOC. The filter does not need an operator standing over it, but there is one available.
Choosing between the two
Stay on your wire, or send us the wire
Two products, one filtering philosophy. The question is only which side of the handoff the filter should sit on. Plenty of operators run both.
ZeroKeep
On-premise, on your hardware
For operators with their own racks, their own transit and often their own ASN, who need packets, logs and the decision plane to stay inside the network they run.
- Traffic never leaves your network
- Filtering in your kernel, at your edge
- Your Prometheus, your dashboards
- Optional watch from our NOC
zeroms.net IP Transit
Protected transit on AS215362
For operators who would rather not run filtering hardware at all. Traffic is cleaned at our PoP before it reaches you, with no equipment to size and nothing to deploy.
- Filtering on our network, before your port
- No hardware for you to run
- GRE tunnel or direct cross-connect
- Routing and BGP handled by our engineers
Still deciding? How our filtering works, our network, and always-on versus on-demand all cover the reasoning. There is also a provider comparison for the transit side, and a Minecraft-specific guide.
FAQ
Questions we get asked
- What is ZeroKeep?
- On-premise DDoS protection software from zeroms.net. You deploy it on infrastructure you own, and it filters hostile traffic in the Linux kernel using XDP before that traffic reaches your origin servers.
- How is this different from zeroms.net IP Transit?
- IP Transit is filtering on our network. You buy protected transit from AS215362 and traffic is cleaned at our PoP before it ever reaches you. ZeroKeep is the filter running inside your network, on your hardware, on transit you already have. Same philosophy, different side of the handoff.
- Does my traffic leave my network?
- No. That is the point of the product. Packets are inspected and dropped on your own hosts, and clean traffic continues on the path it was already taking. There is no tunnel to us and no detour to a scrubbing centre.
- Do I need my own ASN?
- It helps, but it is not a hard requirement. What ZeroKeep needs is that the traffic passes through hardware you control. If you have your own racks and your own transit, you can run it. If you have neither, IP Transit is the better fit.
- What kinds of attack does it stop?
- Volumetric floods and reflection or amplification are dropped in the kernel at line rate. Protocol abuse and application-layer floods are handled by the profile for the service behind the port, including game handshakes, query protocols and VPN control channels.
- How fast can we be live?
- Many deployments are running the same day. We will not put a number on yours before seeing your interfaces and topology, so the timeline gets confirmed on the scoping call.
- Can you monitor it for us?
- Yes, as an option. Our NOC is staffed around the clock and can watch your ZeroKeep cluster alongside you. Scope it on the quote and we will tell you what that looks like for your setup.
- Is there public pricing?
- No. ZeroKeep is sized against your interfaces, packet rates and redundancy requirements, so a list price would be a guess. Send a quote request and an engineer will come back with a scoped answer.
- Can it run alongside existing transit, Flowspec or ACLs?
- Yes. ZeroKeep does not ask you to tear out what you have. It sits on the path as the filtering plane, and upstream Flowspec or ACLs stay useful for the traffic classes they are good at.
- Can I run ZeroKeep and zeroms.net transit together?
- That is a common shape. ZeroKeep handles the first drop locally, and zeroms.net transit sits upstream for the traffic classes you would rather absorb before they reach your ports. See the transit plans for that side.
Get a ZeroKeep quote
Tell us what the wire looks like and an engineer will come back with a scoped answer, not a brochure.
- 24/7 NOC, staffed by engineers
- SLAs available
- No public pricing, every deployment is sized
- A human replies