Scan History UI

After building Scan History v1 in the backend, I finally wired it to the frontend.

Before this, scans were saved in the database but the UI had no way to show them. The data existed, it was just sitting there unused.

Now the dashboard can load previous scans for a target instead of acting like every scan is brand new.

Fixes

• Fixed a bug where the current scan sometimes appeared in history
• Cleaned up username intel checks so results are more reliable
• Tweaked the results layout a bit

FluxOSINT now actually remembers scans and shows them.

Next up: improving domain and IP intel so scans return better signals.

Scan History v1

Okay so FluxOSINT finally has memory now.

Before this, every scan would run, return results, and that was it. If you refreshed the page or ran it again, the previous data was basically gone. It worked, but it felt temporary. Not very “OSINT platform”, more like “OSINT demo”.

So I changed how scans work under the hood.

Now when you run a scan:

• It calculates an overall risk score from all modules

• It saves the target into the database

• It creates a scan record with a timestamp

• It stores each module’s result separately

Which means scans are no longer just responses. They’re actual records.

This required rewriting the /targets/ endpoint and restructuring how data is inserted into the database. I broke it a couple times. Production yelled at me. SQL yelled at me. Variables were undefined. But after cleaning it up properly, it finally clicked.

On the frontend side:

• Added an Overall Risk card above everything

• Switched results layout to a grid so multiple cards sit side by side

• Tweaked spacing so it looks more like a dashboard instead of stacked blocks

It actually feels like a real product now. You run a scan and it has weight. It gets recorded. It exists.

Next up: actually showing scan history in the UI instead of just storing it silently in the database.

Architecture Cleanup + Module Fixes

Right after Results v2, I thought FluxOSINT was finally stable.

Then I actually used it properly.

Some modules technically worked but weren’t structured consistently. Username scans weren’t rendering correctly, IP and Domain intel sometimes showed weird “unknown” values, and LeakGuard broke depending on how the route was accessed. Classic production reality check.

So this sprint wasn’t about adding features, it was about cleaning up the system properly.

• Unified module return format across Email, Username, Domain and IP
• Fixed nested result structure that was breaking frontend rendering
• Properly wired the LeakGuard router end-to-end
• Cleaned up duplicate database helpers and standardized DB access
• Wrote a README

No flashy additions. Just making the engine consistent and maintainable.

FluxOSINT now feels engineered instead of experimental.

**Next up: ** scan history and smarter monitoring so targets aren’t just scanned once and forgotten.

Results v2 + Backend Fix Era

FluxOSINT went through its “why does production hate me” phase.

After shipping the frontend, deploying the real backend exposed a ton of issues: broken imports, database crashes, modules misbehaving, and leftover experimental features causing chaos. This sprint became a full stability + polish update.

Big wins from this update

• Fixed deployment and package structure so the backend boots reliably in the cloud

• Automatic database creation on startup (no more missing table crashes)

• Cleaned the module loader and removed unfinished features (goodbye report generator chaos)

• Replaced raw JSON responses with real UI result cards and risk indicators

• Fully integrated LeakGuard into the web app

• FluxOSINT finally feels stable and usable instead of fragile and scary.

Next up: scan history and background jobs so FluxOSINT can remember and monitor targets over time.

Frontend v1

Today FluxOSINT finally stopped looking like an API and started looking like a real product.

• Until now the project technically worked, but everything lived inside JSON responses and API docs. So I built the first proper web interface and connected it to the live backend.

• The biggest goal was design consistency. I rebuilt the UI using the exact same minimal black-and-white theme as my portfolio so the whole Flux3tor ecosystem now feels like one platform instead of random projects stitched together.

This update includes:

• A full OSINT dashboard interface
• Scan form supporting emails, usernames, domains and IPs
• Live results viewer connected to the deployed API
• Fixed encoding bugs and UI polish
• Responsive layout and accessibility improvements

Seeing a scan run from a real website instead of Postman was a huge moment. This is the first time FluxOSINT actually feels like a product someone could use, not just a backend experiment.

Next up: Results v2, turning raw JSON into clean visual reports and cards.

Automation & Deployment

• I added a background scheduler that lets FluxOSINT re-scan targets automatically instead of only running scans on demand. This turned the project from a simple tool into something that can continuously monitor targets over time.

• After that, I deployed the backend to Render with a custom domain and automatic GitHub deployments. Getting the app publicly accessible took a lot of debugging around Python packaging, DNS, and Cloudflare, but FluxOSINT is now live as a real hosted service.

CHANGELOG

• Create CNAME (8390b94)
• Automation v1 (67ded50)
• Merge branch ‘main’ of https://github.com/Flux3tor/fluxosint (1632fba)
• Added requirements.txt (f32da0f)
• Fixes (9403106)
• EVEN MORE FIXES (e710fd5)
• Fix package imports for Render deployment (87c0899)
• Remove static mount for Render deployment (0d5fb4f)
• Render Fix (863d9a8)
• Render Fix (c5be4bc)
• Render MORE FIXES (2b0b2bc)

Reports v1

Today I gave FluxOSINT the ability to generate real PDF reports instead of just showing JSON in the browser. Now every scan can turn into a clean, shareable intelligence file with branding and timestamps.

Getting a full document pipeline working made the project feel way more “platform” and less like a dev tool. Opening that first generated PDF was a legit milestone moment.

Next up, I’m building Automation v1, scheduled rescans and alerts so FluxOSINT doesn’t just scan once and forget.

LeakGuard v1

Now I added a privacy-safe password checker to FluxOSINT. Instead of sending passwords to the server, I used browser-side hashing and k-anonymity to only query small hash prefixes against a public breach database.

The coolest part was realizing the backend never touches the real password at any point so all the sensitive work stays in the browser. It made the feature feel way more “real-world” than just calling an API.

Next up, I’m adding Reports v1 so FluxOSINT can generate clean PDF intel summaries instead of just showing raw JSON.

Email Intel v1

Now I added FluxOSINT’s first real “security” feature. Instead of relying on paid breach APIs, I built an email intelligence module that looks at public reputation signals like MX records, disposable email providers, domain age, Gravatar presence, and whether the email shows up on public paste sites.

The hardest part was making all these checks work inside one plugin and still return a simple risk score that makes sense. Once it came together, the scans finally felt like real OSINT instead of just a tech demo.

Next up, I’m building LeakGuard, a privacy-safe password checker that tells users if their password has appeared in known leaks without ever sending the actual password to the server.

Module Engine v1

Now I turned FluxOSINT from a database into an actual system. I built a module engine that automatically runs OSINT tools when a target is added instead of just saving it.

My first real module checks if a username exists on a few major platforms and returns results instantly in the API. Watching it scan and respond in real-time was honestly the “okay this is real now” moment.

Next up, I’m building Email Intel + Breach Check, so FluxOSINT starts doing actual security analysis instead of just presence checks.

Target Engine v1

Today I got FluxOSINT’s core working. I built an API that lets me add investigation targets (usernames, emails, domains) and store them in a real database instead of just printing stuff to the terminal. This is basically the backbone everything else will plug into.

I hit a few dumb but important bugs, mainly running Python from the wrong folder and breaking my imports. Once I fixed the project structure and initialized SQLite properly, the API came online and started saving targets like it should.

Next up, I’m building the module engine so FluxOSINT can actually do something with these targets instead of just storing them.