Our products and our project work run on a deliberately small set of technologies. Not the longest list we could write, but the tools we actually build on and can stand behind. Most are open source, and all are chosen to run inside a customer's own perimeter when that is what the network needs.
How we pick them
This is a map of where our expertise sits, not a logo wall. Each technology below earns its place because we use it in real network and security work, and because it fits three things we care about.
Open by default
Open-source tools we can read, extend and run without a licence gate. Several of them we contribute back to.
Vendor-independent
We build the design, not a single vendor's box. The output is an architecture you own and can move.
A selection, not a catalogue
We work with far more than this in the field. What you see here is the core we build on ourselves and know inside out, the tools we reach for first.
The stack, by layer
From the languages we write, through the platform we run things on, to the data and AI layer on top. Each item carries a line on what we actually do with it.
Automation & tooling
How we standardise at scale
-
Ansible
How we automate provisioning, firmware and compliance across multi-vendor fleets, so a small team can run a large, consistent network. We maintain the open ansible-mikrotik collection.
-
Python
Our default for network automation, config parsing and the data tooling around the products. Most of our glue is Python.
Languages & UI
What we write in
-
Go
Performance-critical services and network daemons, shipped as a single static binary that is easy to run on constrained hardware.
-
TypeScript
Typed from the product UIs down to the Node tooling behind them, so the frontend and its build stay consistent.
-
React
The operator-facing interfaces for Explorer, IPAM and the segmentation toolbox.
Containers & orchestration
How we package and run it
-
Docker
Packaging for the products and the lab, reproducible from one environment to the next.
-
Kubernetes
Where those containers run when a deployment needs to scale or heal itself.
-
ContainerLab
Virtualised IT and OT topologies for validating designs, rehearsing failures and running the hands-on courses.
Virtualization & cloud
Where it runs
On-prem first, public cloud where a customer is already there.
-
Proxmox
On-prem virtualisation for labs and customer deployments that have to stay inside the perimeter.
-
Apache CloudStack
Self-hosted IaaS: cloud-style self-service and provisioning, run on a customer's own hardware.
-
AWS
Public-cloud delivery where a customer already runs there and wants us to build with them on it.
Data & observability
How we see and move data
Besides our own log-analytics product, we work with the open logging and streaming stacks customers already run.
-
Elastic
Log and event analytics for network and security data, the engine behind our log-analytics work.
-
Graylog
Centralised log management and alerting: a focused, lean SIEM for when Elastic is more than a customer needs.
-
ntop
Traffic visibility and flow analysis, ntopng for seeing what is actually moving across a network in real time.
-
Apache Kafka
The streaming backbone for moving telemetry and events between systems at volume.
On-prem AI
Intelligence that stays inside
Open models on your own hardware, no data leaving the perimeter.
-
MCP
The open tool layer that lets a local model act on your own systems, with no vendor lock-in.
-
Ollama
Serving open models on local hardware for smaller workloads and fast prototyping.
-
vLLM
High-throughput model serving when on-prem inference has to scale.