Coder Legion - Recent posts tagged port

How to Expose Localhost to the Public Using Nginx and SSH Tunnels

Sun, 03 May 2026 09:35:44 +0000

Hello, I'm Ganesh. I'm building git-lrc, an AI code reviewer that runs on every commit. It is free, unlimited, and source-available on Github. Star Us to help devs discover the project. Do give it a try and share your feedback for improving the product.

As a developer, you’ve likely faced this hurdle: You are building a complex application on your local machine, and you need to show it to a client or test a webhook of your application.

You could deploy it to a staging server, but that's slow.
You could use Ngrok, but the free tier has limits and dynamic URLs.

Today, I’ll show you how to build your own "Unlimited" Reverse Proxy using Nginx, Autossh, and a small VPS.

The Architecture

The goal is to route traffic from a professional URL (like test1.yourdomain.com) directly to a port on your local machine (like localhost:3000).

We use three layers of technology to make this happen:

Nginx: Acts as the entry point and handles SSL (HTTPS).
SSH Reverse Tunnel: Creates a secure "pipe" from your VPS back to your laptop.
Autossh: Ensures that if your internet flickers, the "pipe" automatically reconnects.

Step 1: The Remote Server (Nginx)

On your server, you need an Nginx configuration that listens for HTTPS traffic and passes it to a local port.

server {
    listen 443 ssl http2;
    server_name test1.yourdomain.com;

    ssl_certificate /etc/letsencrypt/live/your-domain/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/your-domain/privkey.pem;

    location / {
        # Proxy traffic to the SSH-forwarded port
        proxy_pass http://127.0.0.1:6540;

        # Keep the original user's info
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
    }
}

Step 2: The Local Bridge

On your local machine, you need to open the tunnel.

Using a Makefile or a shell script makes this repeatable. The core command uses the -R flag, which stands for Remote Forward.

# -R [Remote Port]:[Local Destination]:[Local Port]
autossh -M 20000 -R 6540:localhost:3000 root@your-server -N

Why this is "Unlimited"

Unlike third-party services, this setup gives you:

Total Control: No timeout limits or bandwidth caps (other than your own ISP's speed).
Professionalism: You use your own domain and your own SSL certificates.
Security: Your local machine is not truly "exposed." Only the specific port you choose (8081) is bridged through the encrypted SSH tunnel.

Troubleshooting Common Gotchas

502 Bad Gateway: This usually means Nginx is working, but your SSH tunnel isn't running or is on the wrong port.
Port Already in Use: If you restart your tunnel quickly, the server might still think the old one is active. Use a cleanup script to kill -9 <PID> any process currently sitting on your remote port before starting a new one.
Firewalls: Ensure your VPS allows traffic on ports 80 and 443!

Conclusion

By combining the stability of Nginx with the flexibility of SSH tunneling, you've created a production-grade development environment.

You now have a permanent bridge between your local setup and the rest of the world.

Any feedback or contributors are welcome! It’s online, source-available, and ready for anyone to use.
⭐ Star it on GitHub: https://github.com/HexmosTech/git-lrc

Porting Test Drive II from SNES to PC, Part 4: Validation, cleanup, and current blockers

Sat, 21 Mar 2026 13:48:16 +0000

Porting Test Drive II from SNES to PC, Part 4: Validation, cleanup, and current blockers

By the second week of this repo, the technical risk had changed.

The problem was no longer "we do not have enough scripts." The problem was "we have enough moving pieces that incorrect progress can look convincing."

That is why the March 6 to March 19 history matters so much. This is the phase where asmdump turns archaeology results into contracts, turns renderer bugs into isolated fixtures, and starts cleaning up its own generated noise.

Validation became executable

Commit c5ec8be on 2026-03-06 added the first real validation policy layer:

tools/check_regression_gates.py
tools/validate_callback_contracts.py
validation/regression_gates_intro.jsonc
rom_analysis/docs/callback_state_contracts.jsonc
rom_analysis/docs/validation_gates.md

This is a major change in the repo's engineering model.

Before that point, progress was mostly tracked through:

rendered outputs
trace logs
prose notes

After that point, the repo could encode claims like:

this frame or transition is allowed to drift only within a known bound
this callback and state tuple must still be true at this checkpoint
this promoted scene window has a machine-checkable gate

As of the March 19 roadmap snapshot, the current validation baseline is concrete:

callback contracts: 18/18 pass
regression gates: 6/6 pass

That does not mean the intro is solved. It means the repo now has a protected floor. Future archaeology and runtime work can move without silently breaking the windows that are already understood.

Renderer bugs got synthetic fixtures instead of ad hoc screenshots

The cleanup commit 1663f43 on 2026-03-19 is easy to misread as housekeeping. It is more important than that.

It added focused renderer checks:

tools/check_obj_vertical_flip.py
tools/check_bg_layer_priority.py

Those scripts generate tiny scenes with one narrow purpose:

prove the non-square vertically mirrored OBJ path
prove BG4 and tile-priority ordering

That is the right kind of renderer test for this project. Large captured frame windows are useful, but they are bad at isolating a single rule. Small synthetic scenes are much better at answering one question at a time.

The repo now checks those fixtures across multiple renderers:

Python simple path
Python mode7-ppu path
SDL runtime

That is exactly the kind of cross-checking a port project needs when the same scene can be exercised through more than one implementation.

Cleanup was part of the product work

The current repo state makes the cleanup motivation obvious.

The worktree already contains:

mutable .mesen-config outputs
large tools/out trees
generated design packs
probe logs
frame dumps
scratch bridge outputs

Without active cleanup, the difference between a committed result, a disposable intermediate file, and a stale experiment gets blurry fast.

That is what 1663f43 and 6076df3 were fixing:

tighter ignore policy
generated-artifact cleanup targets
removal of tracked build and cache artifacts
pressure to remove hard-coded personal paths from promoted scripts

This is not cosmetic. Port work slows down badly when the repo stops making it obvious which artifact is authoritative.

The current roadmap treats that explicitly as a first-class execution track, alongside the ongoing archaeology lanes. That is the correct call.

The remaining blocker is a composition problem, not a vague unknown

Commit 31f3ac7 on 2026-03-19 added tools/analyze_oam_delta.py and promoted late-intro OAM delta diagnostics into the main workflow.

That matters because the late intro gap is now described with much better precision.

The repo's current reading is roughly:

queue-driven and bridge-visible native coverage extends through frame 1093
frame 986 is no longer a generic mismatch; the BG path is close and the remaining error is in the OBJ/composition side
frame 990 behaves similarly when compared against bridge-visible output
by frame 994, the committed scene variants no longer show a distinct probe-vs-bridge OAM fork

That last point is important. It rules out one tempting explanation and keeps the next work item honest.

The repo can now say:

the bridge-visible path is real through 1093
the screenshot gap after 982 is still open
the unresolved part is not "some random late intro behavior"
the unresolved part is mostly in Mode 7 OBJ composition and presentation timing

That is the kind of blocker description that leads to fixes.

What the project looks like today

From the initial import on 2026-02-26 to the current snapshot on 2026-03-19, this repo has moved from a reverse-engineering base to a working port workbench:

deterministic Mesen capture and probe scripts
extraction tooling for palettes, VRAM, chunks, and frame windows
a modular C/SDL runtime that can replay native and extracted intro slices
trace-backed provenance tooling for bank 30 and tilemap windows
deterministic gameplay seed windows
machine-checkable regression gates and callback contracts
synthetic renderer fixtures for known correctness bugs

That is solid progress for 45 commits in just over three weeks.

It is also still clearly a port in progress.

The active blockers in the roadmap are sensible and specific:

close the 958..977 bootstrap gap
resolve the 986+ final-screen composition gap
keep replacing sampled attract windows with native callback/state playback
continue the bank 30, bank 10, and bank 11 contract work needed for gameplay

That is where this series leaves the repo for now.

The important point is that the project is no longer trying to solve all of that with one tool or one style of evidence. It has separate surfaces for:

extraction
runtime playback
archaeology
validation
cleanup

That separation is what makes the current state believable. The repo is not just producing images that look close. It is building a system that can explain why a frame is right, detect when it stops being right, and keep moving when only part of the game is ready for native code.