Phase 0 - Laying the Blueprint: How Project Jupiter Begins to Take Shape
I’m currently developing Project Jupiter, a self-hosted, multi-tenant SIEM + SOAR platform designed with OCSF-native architecture. The landing page (projectjupiter.in) serves as a showcase of the project’s ongoing research and development, highlighting how ML and AI—through embeddings, vector databases, and LLM-driven analysis—can enhance threat detection, power RAG-based investigations and automate response playbooks.
Every complex system starts with a question, not a commit.
Why This Phase Exists
Phase 0 of Project Jupiter is where everything slowed down on purpose.
Before writing production code, I wanted to understand how far a single person could go in building a self-hosted, AI-assisted security and monitoring platform one that could run anywhere, without depending on a single cloud, vendor, or budget.
This phase is less about configuration and more about philosophy, research, and structure.
It’s where ideas harden into architecture.
What I Set Out to Learn
When I began blueprinting, I had a few key questions written in my notebook:
Could one developer realistically design a vendor-neutral, OCSF-native SIEM?
How can AI actually reduce noise instead of creating more of it?
How do you stay flexible enough to work on-prem, in the cloud, or in a hybrid mesh without building parallel systems?
These questions became my compass.
Lessons from the Field
My background helped frame these questions.
Having worked in product support and later as a threat hunter, I saw both ends of the spectrum from the chaos of customer logs to the calm dashboards of analysts.
I learned that every SIEM pipeline eventually wrestles with the same three beasts: data volume, normalization, and fatigue.
The First Conviction
Very early, I made a decision that still defines the project:
Jupiter must run anywhere.
It shouldn’t matter whether it’s a GPU workstation, a cloud VM, or an old laptop in someone’s lab.
This principle shaped every later choice from storage (DuckDB) to orchestration (NiFi) to how AI inference could fall back to API calls when GPU resources aren’t available.
The Early Architecture
At this stage, the design looked simple on paper but ambitious in intent.
This was the first time I saw how all parts might speak the same language, data flowing in OCSF format, AI models helping to summarize and correlate, and dashboards surfacing clarity instead of chaos.
Since this is still in active planning and development, services and technologies might change.
What Changed My Mind
Originally, I believed I could keep everything local, run the AI fully on-prem.
That lasted until I tried inference without a GPU.
Now, Jupiter supports both: local inference for those with hardware, and API-based fallback for community setups.
Scalability starts with empathy for different users.
What’s Next
Phase 0 continues with documenting the research behind this blueprint, exploring how existing SIEM tools work, what they miss, and why Jupiter’s hybrid model matters.
The next article:
“Mapping the Landscape - What Existing SIEMs Teach (and Miss)”
Stay tuned, and if you’ve built or broken your own SIEM before, I’d love to hear what you learned.
