For the last couple years I was always somewhere around traffic systems, affiliate stuff, redirects, postbacks, campaign analytics, ROI reports, all that not very sexy infrastructure.
And honestly after some time I got tired of the same thing.
Almost every serious tracker is a SaaS product. Or a paid self-hosted product. Or some “book a demo” thing. You pay every month, you work inside their model, you accept their limits, and the most interesting part of the system is hidden from you.
You can create campaigns, add streams, configure offers, paste postback URLs, look at reports.
But you don’t really own the thing.
At some point I realized that I don’t want just another dashboard. I wanted to see the whole pipeline myself.
Click comes in.
Tracker makes a routing decision.
User gets redirected.
Event is stored.
Conversion comes later.
Revenue is matched.
Postback goes out.
Reports update.
That full loop.
So I started building TraffoFlex.
GitHub: https://github.com/devflex-pro/traffo-flex
It’s an open-source, self-hosted traffic tracking and routing project. Right now it’s still MVP level, not gonna pretend it is some enterprise monster. But the idea is clear: build a base that can replace the core of what people usually use big trackers for, but keep it open and hackable.
I’m talking about the same class of tools as Voluum, RedTrack, Binom, Keitaro, BeMob, CPV Lab and similar platforms.
Not “killer” in the cringe marketing sense. I hate that wording.
More like: I want an open-source foundation for the same problem space.
The problem space is actually pretty simple if you remove all the SaaS marketing around it.
You need to receive clicks.
You need to decide where to send them.
You need to track what happened.
You need to receive conversions.
You need to calculate money.
You need to send postbacks somewhere else.
And you need reports that don’t lie to you.
That’s the boring version. The real version gets messy very fast.
Because every click asks one question:
“Where should this user go right now?”
And the answer is not always “offer A”.
Maybe the destination is capped. Maybe geo doesn’t match. Maybe this browser is not good for that offer. Maybe advertiser is dead again. Maybe ROI is negative today. Maybe trafficback should trigger. Maybe you don’t want to send same user to same destination twice. Maybe you want weighted rotation. Maybe you want waterfall logic. Maybe you want some custom rule that no SaaS vendor will add for you because your case is too weird.
That’s where I started enjoying the project.
Trackers are basically decision engines pretending to be dashboards.
The dashboard is just the visible part. The interesting part is routing, attribution, events, postbacks, storage, deduplication, and all the small ugly edge cases.
In TraffoFlex I split the project into several services because I didn’t want one big backend doing everything.
There is an api-service for admin stuff. Campaigns, streams, destinations, traffic sources, affiliate networks, postback templates, users, all that CRUD side of the system.
There is a traffic-service for the hot path. This is the thing that receives clicks and redirects users. It should stay focused. It should not care about admin UI. It should not run heavy reports. It should not become a kitchen sink.
There is a postback-service for conversions. It receives incoming postbacks, normalizes values, validates secrets, deduplicates conversions, enriches data from clicks and sends outbound postbacks when needed.
Then there is React admin frontend, MongoDB for configuration/state, ClickHouse for analytics, and Redpanda for event streaming.
Nothing super exotic. Just a stack that makes sense for this kind of system.
MongoDB is fine for campaign configs because configs are nested and operational. ClickHouse is much better for analytical events like clicks, conversions, revenue, cost, profit, ROI and logs. Redpanda gives event streaming without turning local dev into pain. Go is just nice for this kind of backend infra. Fast enough, simple enough, not too magical.
The main thing I wanted was separation.
Admin panel should not be on the redirect hot path.
Reports should not slow down clicks.
Postbacks should not be mixed with campaign editing logic.
ClickHouse should do analytics, not campaign configuration.
MongoDB should store configs, not billions of event rows.
This sounds obvious, but a lot of internal tools slowly become one giant backend where everything touches everything. I didn’t want that here.
Performance was one of the biggest reasons I started thinking about this project seriously.
In tracking, redirect speed matters. Not in a fake benchmark way. It actually matters because the user is waiting. The traffic source is waiting. The offer page is waiting. If the tracker is slow, everything after it becomes worse.
The click path should be stupid fast.
Receive request. Resolve campaign. Match stream. Pick destination. Write/publish event. Redirect.
That’s it.
No dashboard logic. No heavy aggregation. No random “let me calculate ROI right now inside redirect request” nonsense.
Of course TraffoFlex is still MVP, so I’m not saying “this is faster than every commercial tracker”. That would be stupid. Tools like Binom, Keitaro, Voluum and RedTrack have years of production battle testing and many optimizations.
But with self-hosted open-source infra I can do something that I can’t do with a black box.
I can profile it.
I can cache configs in the exact way I need.
I can move redirect nodes closer to traffic.
I can change ClickHouse tables.
I can remove features I don’t need.
I can write ugly custom routing logic that would never be accepted into some SaaS roadmap.
I can load test my exact case instead of reading “high performance” on a landing page.
That control is the whole point.
Money is the other big part.
Commercial trackers are not cheap. And I’m not saying they should be cheap. Good tracking infra is hard. Support costs money. Integrations cost money. Cloud traffic costs money. Teams need salaries. Fair.
But from the user side, it still becomes another subscription. $100 per month, $150 per month, $300 per month, $500 per month, sometimes more depending on plan, usage, team, domains, events, features, whatever.
And when you are already paying for traffic, proxies, landing pages, hosting, domains, spy tools, creatives, automation, and 20 other things, one more recurring SaaS bill starts to hurt.
Especially when you only need the core part.
Maybe you don’t need a huge automation suite. Maybe you don’t need all integrations. Maybe you don’t need a polished enterprise UI. Maybe you need a fast redirect service, postbacks, ClickHouse reports and full control over raw data.
Then paying forever for a big closed platform starts to feel kinda dumb.
Self-hosted open source doesn’t mean “free” in the magic sense.
Servers cost money. Monitoring costs money. Backups cost money. Your time costs money. Bugs cost money too, sometimes more than the server lol.
But the cost model is different.
You pay for infrastructure you control.
A VPS, maybe a dedicated server later, ClickHouse storage, backups, maybe some monitoring. You can start small and scale the parts that actually need scaling. You are not paying a vendor tax every time you want to keep more data, add some custom rule, or run weird experiments.
For me that’s the big advantage.
With SaaS I rent the result.
With self-hosted I own the system.
That doesn’t mean self-hosted is always better. It is not.
If someone needs a polished tracker today, with support, docs, onboarding, integrations, team permissions, billing-friendly reports and less headache, then commercial tools make total sense. I would not tell everyone to replace Voluum or RedTrack or Keitaro with some MVP from GitHub.
That would be dishonest.
But if you are a developer, technical media buyer, small team, indie hacker, infra nerd, or someone who just wants to understand how tracking actually works, then self-hosted is much more interesting.
And honestly more fun.
Another reason I wanted this open-source is because this niche is weirdly closed.
A lot of people use trackers. Very few people see how trackers are built. Most discussions are around which tool has better UI or which one has better pricing. But there is not much public code showing the real moving parts.
How do you model campaigns and streams?
How do you select destinations?
How do you handle trafficback?
How do you normalize postbacks from different affiliate networks?
How do you deduplicate conversions?
How do you store click events?
How do you calculate ROI?
How do you keep redirect path separate from reporting?
I wanted TraffoFlex to be at least one public codebase where this stuff is visible.
Not perfect. Not finished. But visible.
Right now TraffoFlex can already cover the core tracking flow.
You can create campaigns, streams and destinations. You can route traffic. You can use rules. You can use weighted distribution and fallback logic. You can receive postbacks. You can deduplicate conversions. You can send outbound postbacks. You can store events in ClickHouse. You can look at reports in the admin UI. You can seed demo data and test the whole flow locally.
Again, MVP. I’ll repeat it because internet people love to ignore context.
It still needs hardening. Auth needs more work. Security needs proper review. Observability should be better. Tests should be better. Docs should be better. Deployment story should be cleaner. Load testing should be done properly. There are many boring production things left.
But the foundation is there.
And I prefer releasing it early instead of pretending I will disappear for one year and come back with a perfect product. That never happens anyway.
Also, one important point.
Traffic routing tools can be used for normal and useful things, like campaign analytics, A/B testing, affiliate tracking, trafficback, monetization optimization, internal attribution, performance marketing workflows.
They can also be misused.
I don’t want TraffoFlex to be used for phishing, malware, deceptive redirects, spam, cloaking for abuse, or anything like that. The goal is not to build shady infra. The goal is to build an inspectable open-source tracker for legit use cases.
I know this space has some reputation problems. Still, the infrastructure itself is not the problem. Intent matters.
For me this project started from a very simple frustration:
Why is such an important part of the traffic business always a black box?
I wanted to open the box.
Maybe TraffoFlex becomes a useful tool for someone. Maybe it becomes a learning project. Maybe somebody forks it and builds a better tracker. Maybe it just helps one developer understand how postback tracking works.
All of that is fine.
I already learned a lot building it.
Way more than from another “how to build scalable systems” blog post with boxes and arrows and no code.
If you’re interested in self-hosted tracking, Go services, ClickHouse analytics, affiliate infra, routing engines or just weird marketing infrastructure, check it out.
GitHub: https://github.com/devflex-pro/traffo-flex
And yeah, issues and feedback are welcome. Just don’t expect enterprise polish yet. It’s still a real project in progress, not a landing page pretending to be software.
Top comments (2)
Really resonated with the "trackers are decision engines pretending to be dashboards" framing — that's a clean way to describe what actually matters in the system.
The service separation you described (traffic hot path isolated from admin/reporting) is something I ran into building Pronto — an open-source POS/booking system for service SMBs. Same principle: the checkout path should never wait for analytics aggregation to finish. Sounds obvious until you see how fast a monolith grows when you're moving fast solo.
The ClickHouse + MongoDB split makes sense for your workload. Curious — did you consider keeping everything in ClickHouse including campaign configs, or was the operational read/write pattern the main reason to keep Mongo?
Good call shipping early. The "disappear for a year and return with perfect product" thing really never happens.
Thanks! Yeah, exactly, the hot path separation was one of the main things I wanted to keep clean from the beginning.
I did think about putting more into ClickHouse, but campaign configs felt like the wrong fit there. They are mutable, nested, edited from the admin UI, and read in an operational way, not analytical way.
So the split is basically: MongoDB for “current state / config I need to route traffic”, ClickHouse for “events I want to analyze later”.
Could it be done fully in ClickHouse? Probably, but I think it would make config updates and app logic more awkward for no real benefit.
And yeah, monolith growth while moving solo is painfully real lol.