Service
Network Engineering & BGP
Routing, peering and address space — designed on paper, built as code, proven by withdrawal tests.
- /24
- We own and announce our own IPv4 block
- BIRD
- eBGP sessions we built and operate ourselves
- RPKI
- Signed ROAs and IRR objects on every prefix
Networking is the layer where small mistakes have large blast radii. A bad prefix-list leaks half the internet. A missing ROA gets your traffic dropped by validating networks. A single-homed transit link turns a maintenance window into an outage.
We have built this for ourselves — our own address space, our own ASN, our own eBGP sessions on BIRD across AWS and Vultr footprints — which means we have made the mistakes on our own infrastructure first.
Address space and routing policy
Owning portable address space changes what is possible: you can move providers without renumbering, announce the same prefix from many locations, and keep reputation attached to you rather than to a shared cloud range.
We handle the RIR application and justification, IRR objects, RPKI ROAs, and the routing policy that decides what you accept and what you originate.
# bird.conf — accept only RPKI-valid routes from transit, originate our /24
roa4 table r4;
protocol rpki rpki_rtr {
roa4 { table r4; };
remote "rtr.rpki.example" port 8282;
retry keep 90;
}
filter transit_in {
if roa_check(r4, net, bgp_path.last) = ROA_INVALID then reject;
if net.len > 24 then reject;
accept;
}
protocol bgp transit_blr1 {
local as OURASN;
neighbor 198.51.100.1 as 64500;
ipv4 {
import filter transit_in;
export filter { if net = 203.0.113.0/24 then accept; reject; };
};
}
Prefix-length filters, RPKI validation, explicit originate lists and max-prefix limits are not optional extras. They are the difference between a routing mistake that affects one session and one that makes the NANOG mailing list.
Multi-site and hybrid
Most of our network work is connecting things that were not designed to be connected: an on-prem rack to three cloud regions, a GPU cluster to a product running in Kubernetes, offices to a private backbone.
- Underlay. Transit mix, IX presence, cross-connects, and where a second provider genuinely buys you independence rather than the same upstream twice.
- Overlay. VXLAN fabrics for L2 adjacency where it is unavoidable, WireGuard or IPsec meshes where it is not, and routed-first designs wherever we can get away with them.
- Addressing. A plan that survives growth — IPv6 from the start, deterministic allocation, and no overlapping RFC 1918 space between acquired networks.
Proving it works
Design reviews catch intent errors. Only tests catch reality errors.
Before handover we withdraw prefixes one POP at a time and measure where traffic lands. We pull a transit link during business hours, under supervision, with a rollback ready. We verify that your monitoring actually noticed. A failover path that has never been exercised is a hypothesis, not a feature.
Who this is for
Platforms where latency, egress cost or sovereignty matter enough to justify running your own edge: media and streaming, gaming, fintech with regional obligations, AI inference with large response payloads, and anyone whose cloud egress bill has started to look like a headcount.
Questions
Asked often enough to answer here.
Do we need our own ASN and IP space?
Only if you need portability or anycast. If you want to move providers without renumbering, run anycast, or announce from multiple sites, you need both. If you are a single-region SaaS on one cloud, you almost certainly do not — and we will tell you that.
How long does getting an ASN and a /24 take?
The engineering is days. The paperwork is the slow part — RIR membership, justification and transfer or allocation typically run several weeks to a few months depending on region. We handle the applications and the IRR and RPKI records that follow.
Can you work with our existing network vendor?
Yes. We design and document; your vendor or your team can implement. We are equally happy reviewing a design we did not write — a second pair of eyes before a migration window is cheap insurance.
What happens if a BGP session flaps at 3am?
On a managed-run retainer, our on-call gets the page, not you. Sessions are monitored for state, prefix count and route-origin validity, with automatic suppression of a misbehaving peer where the design allows it.
Also
The rest of the estate.
- InfrastructureWe take the estate you already have and make it legible, automated and boring.
- CDN & EdgeYour own content network on your own address space — or a sane configuration of someone else's.
- SecurityReduce the number of ways in, then prove what happened on the ones that remain.
- On-PremA private cloud that behaves like a public one — self-service, API-driven, and yours.
- AI InferenceRun your models on hardware you control — for cost, for latency, or because the data cannot leave.
- Device & MDMEvery laptop and phone enrolled, encrypted, patched and accounted for — from unboxing to offboarding.
- ObservabilityKnow it broke before the customer does — and know which layer, in one click.
- All servicesOverview, delivery method and the things we will tell you not to buy.
Next step
Tell us what breaks at 3am.
A 30-minute call with the engineers who would do the work — not a sales desk. We will tell you whether this is a bolt.sh problem or something you can fix in-house.