About
Infrastructure answers should not require a mystery platform
Most teams do not lack tools. They lack working integration and useful context.
The asset data lives in Terraform. Runtime truth lives in metrics, logs, traces, and packets. Security findings arrive from five scanners with five ideas of urgency. Identity and certificates become urgent only after they fail. The database platform is somehow still “temporary” three years later.
In a Box Tools packages those recurring capabilities into inspectable, self-hosted blueprints. Each project starts with a real operational question and wires together proven open-source components, explicit configuration, health checks, dashboards, examples, and operating commands.
The goal is not to pretend infrastructure has zero complexity. It is to make that complexity visible, understandable, and quicker to operate.
The operating principles
1. Outcomes before components
Start with “what breaks if I change this?”, “what is being exploited?”, or “why is the service slow?” The container list comes second.
2. Opinionated, not opaque
Defaults should get you to a useful system quickly, but every file and trade-off remains available for inspection. A blueprint you cannot understand is just a smaller vendor lock-in problem.
3. Local by default
Telemetry, asset graphs, identities, vulnerability findings, certificates, and compliance evidence remain on infrastructure you control. Cloud integrations are optional, never the price of entry.
4. Honest boundaries
These projects reduce integration toil. They do not replace capacity planning, backups, threat modeling, incident responders, or knowing your environment. When a project is an IDS rather than an inline IPS, the documentation says so.
5. Independently useful
Run one focused project or combine several. XIB provides a unified security-posture view, but VIB, TIB, CIB, IIB, and PIB remain separately deployable and understandable.
The thirteen projects
| Question | Projects | Answer |
|---|---|---|
| What exists and what breaks? | AIB | Asset relationships, impact, drift, and infrastructure audit |
| What is the system doing? | OIB | Metrics, logs, traces, profiles, and operational health |
| Where can developers work with data? | DIB | Five database engines, UIs, monitoring, backups, and automation |
| What happened across cloud control planes? | CAIB | Normalized audit evidence, detections, search, ingest health, and retention |
| Is workload, cluster, or network behavior hostile? | SIB, SIB-K8s, NIB | Runtime, Kubernetes, and network detection |
| Which risk gets fixed first? | VIB, TIB, CIB | Vulnerability history, exploit likelihood, and policy evidence |
| Who and what is trusted? | IIB, PIB | Identity, SSO, internal PKI, and certificate lifecycle |
| How do I see security posture together? | XIB | Unified Grafana across five focused security tools |
About Matija
I’m Matija Žeželj, an independent infrastructure and security engineer with more than twenty years of hands-on experience designing, scaling, and defending systems.
My work spans SecOps, Linux, cloud, CI/CD, vulnerability management, compliance, observability, and Kubernetes. I have operated environments ranging from homelabs to thousands of servers, hundreds of engineering repositories, large bare-metal clusters, and services handling serious traffic and data volumes.
The In a Box family exists because smaller teams should be able to learn from and operate the same class of open-source tools without buying an opaque platform or spending weeks wiring the first useful dashboard together.
I build and test these projects in the open. If you need architecture review, hardened deployment, integration with an existing environment, or ongoing operational help, review the engagement options.
If it cannot be understood when it fails at 3 AM, it is not finished.