Portix: The Frustration That Led Me to Build My Own Localhost Sharing Tool
I was sick of waiting for staging deployments just to test a new feature. Portix came from wanting developers to share their work directly with me, earlier, so I could give feedback while it still mattered.
The thing that broke me was the wait.
As a QA lead, a big part of my job is testing new features early and giving developers fast, useful feedback. But the workflow was slowing everything down. A developer would build something locally, I would not be able to see it until it was deployed to a staging environment, and by the time it got there it had usually gone through several more changes. The feedback loop was too long and too slow.
Staging deployments take time. They require the feature to be in a state someone is comfortable putting on a shared environment. That means by the time I am looking at something, it is already further along than it needed to be for me to give useful input. Catching a problem at that point costs more to fix than catching it when the work is fresh.
What I actually needed was a way for developers to share what they were building directly from their local machine, before it was ready for staging, so I could see it, test it, and give feedback immediately. Not a screen share. Not a description. The actual running thing, with a URL I could open and interact with properly.
I looked at what existed. Ngrok does the tunnelling but it is generic, has no context about what is being shared or why, and the free tier limits made it awkward for regular daily use. Nothing I found had a feedback layer built in, which meant any comments still had to go through Slack or Jira anyway.
So I built Portix.
How it works
Portix runs a lightweight tunnel from your local machine to a public URL hosted on an Oracle Cloud VM behind NGINX. When you start it, you get a URL you can share immediately. The tunnel stays open as long as you need it and closes cleanly when you are done.
The Git integration came from a practical problem. Developers are often working across multiple branches and when they share a link I need to know immediately what I am looking at. Is this the feature branch or main? Is this the fix or the original issue? Portix picks up the current branch name and labels the preview URL with it so when I open the link I can see exactly which branch I am testing. Small thing but it removes a whole category of confusion before the feedback even starts.
The feedback overlay is a floating widget that appears on the shared page. Reviewers can pin comments to specific areas of the page without needing any account or setup. The comments come back to me in real time via WebSockets. No email thread, no separate feedback tool, no trying to decode written descriptions of visual problems.
The infrastructure decisions
Running a tunnelling tool means I needed something persistent on the server side. I went with an Oracle Cloud VM because the free tier is genuinely usable, NGINX to handle the routing and SSL termination, PM2 to keep the Node process running reliably, and Cloudflare in front for DNS and additional protection.
The WebSocket layer for real time feedback was the trickiest part to get stable. Keeping connections alive reliably across different network conditions, handling reconnects gracefully, making sure feedback posted from a reviewer actually arrives even if there is a brief drop in connectivity, all of that needed more attention than I expected.
What it changed about the QA workflow
The feedback loop is genuinely faster now. Developers share a Portix link when something is ready for a first look, I open it, test it properly in the browser rather than watching someone scroll around on a call, pin my comments directly onto the relevant parts of the page, and they have actionable feedback within minutes.
The quality of the feedback has improved too. When I am actually interacting with a feature rather than watching a demo, I find things I would not have found otherwise. Real interactions, real edge cases, the kind of stuff that only surfaces when you are actually using the thing.
The other shift is that developers share earlier now because the barrier is low. There is no deployment, no preparation, just a link. That means I am seeing features at a stage where changing direction is still cheap. That is exactly where QA input should be landing.
Before Portix I was either waiting for staging or asking developers to walk me through things on a call. Both options were slower, more disruptive, and produced worse feedback. Removing that friction changed how the whole team works together.
It is available at portix.ayteelabs.com if you want to try it.