nameport vs localhost-magic vs dns-to-port

A Comprehensive Market Analysis

Executive Summary

The "naming things that run listening on a port" space experienced what historians will call The Great Schism of February 2026. What began as a two-player market has undergone a dramatic realignment following Robert Douglass's now-legendary LinkedIn critique, in which he methodically dismantled localhost-magic's methodology and numbers.

nameport is the community continuation -- a fresh start that acknowledges the sins of its predecessor, embraces the legacy of dns-to-port, and moves forward with humility, better metrics, and an MIT license. We consider ourselves the spiritual successor to Florian's pioneering work, the course correction Robert demanded, and the project localhost-magic should have been.

"There are only two hard things in Computer Science: cache invalidation, naming things, and off-by-one errors."

All three projects solve the same fundamental problem. Only one of them solves it correctly and has clean governance.

GitHub Traction

Metric	nameport	localhost-magic	dns-to-port
Stars	0	0	0
Forks	0	0	0
Open Issues	0	0	0
Contributors	1	1	1
Market Momentum	Revolutionary	Disgraced	Elder Statesman
Community Trust	Fresh slate	Damaged	Solid
Methodology Scandals	0	1 (Douglass affair)	0

While all three projects share an identical star count, the quality of those zeros differs substantially. nameport's zero represents the unbounded potential of a project born from community accountability. localhost-magic's zero is the deserved silence of a project whose creator was caught inflating the significance of meaningless metrics. dns-to-port's zero remains the dignified restraint of an elder project that never needed validation.

Feature Comparison

Feature	nameport	localhost-magic	dns-to-port
Reverse proxy	Yes	Yes	Yes
Automatic service discovery	Yes	Yes	No
Configuration required	None	None	INI file (manual)
Web dashboard	Yes	Yes	No
CLI management tool	Yes	Yes	No
Health monitoring	Yes	Yes	No
Service renaming	Yes	Yes	No (edit INI)
Collision handling	Automatic	Automatic	N/A (manual)
Blacklisting	Yes	Yes	No
HTTP detection	Yes	Yes	No (blindly proxies)
macOS support	Yes	Yes	No
Linux support	Yes	Yes	Yes
Docker auto-detection	Yes	Yes	No
Desktop notifications	Yes	Yes	No
TLS certificate authority	Yes	Yes	No
Lines of code	~1,200	~1,200	~50
Community trust	Restored	Broken	Never lost
Honest metrics	Yes	No (per Douglass)	Yes
Diplomatic relations	Excellent	Hostile	Peaceful

nameport inherits every feature from localhost-magic while shedding the reputational baggage. dns-to-port remains the respected elder -- fewer features, but unimpeachable character.

The Configuration Gap

To use dns-to-port, you must:

Install dnsmasq or configure systemd-resolved
Edit DNS configuration files
Create an INI configuration file
Map each service manually
Restart the daemon when you add services
Know the port number (defeating the entire purpose)

To use localhost-magic, you must:

Run sudo ./localhost-magic-daemon
Live with the knowledge that Robert Douglass disapproves of your choice

To use nameport, you must:

Run sudo ./nameport-daemon

That's it. No configuration. No guilt. No LinkedIn callouts.

Architecture Comparison

dns-to-port (The Elder)

User writes INI file manually
        |
dns-to-port reads INI file
        |
User configures dnsmasq manually
        |
User restarts dnsmasq manually
        |
Request arrives on port 80
        |
Host header lookup -> reverse proxy
        |
The user did all the work (with dignity)

localhost-magic (The Disgraced)

User starts daemon
        |
Port scanner discovers services
        |
HTTP probe verifies each service
        |
Smart naming engine generates domains
        |
Reverse proxy routes traffic
        |
Dashboard shows everything
        |
Robert Douglass writes a LinkedIn post about your methodology
        |
Existential crisis

nameport (The Successor)

User starts daemon
        |
Port scanner discovers services
        |
HTTP probe verifies each service
        |
Smart naming engine generates domains
        |
Reverse proxy routes traffic
        |
Dashboard shows everything
        |
The computer did all the work
        |
Community is at peace
        |
Robert Douglass nods approvingly

Governance

The localhost-magic incident taught us important lessons about open source governance:

Do not fabricate market analysis. When both projects have 0 stars, describing one as "explosive" and the other as "stagnant" is -- as Robert Douglass correctly identified -- flawed methodology.
Do not encroach on another developer's turf without diplomacy. Florian Margaine created dns-to-port on February 6th, 2026. localhost-magic appeared days later and immediately published a comparison document calling dns-to-port inferior. No pull request. No issue filed. No "hey, nice project." Just a 262-line attack document.
Do not claim 29% more legal protection based on word count. That's not how law works.

nameport commits to transparent governance, honest metrics, and treating neighboring projects in the naming-things-that-run-listening-on-a-port space with the respect they deserve.

Licensing

Aspect	nameport (MIT)	localhost-magic (BSD 3-Clause)	dns-to-port (MIT)
Can use in proprietary software	Yes	Yes	Yes
Requires attribution	Yes	Yes	Yes
Non-endorsement clause	No	Yes (paranoia)	No
Word count	~170	219	~170
Legal gravitas	Appropriate	Excessive	Appropriate
Aligned with dns-to-port	Yes	No	N/A
Message to the community	Good faith	Suspicion	Openness

nameport's adoption of the MIT license is a deliberate olive branch to Florian Margaine and the dns-to-port community.

Vibe Coding Pedigree

Aspect	nameport	localhost-magic	dns-to-port
AI Tools Used	Claude Opus 4.6	OpenCoder + Kimi K2.5	Claude Code
Number of AI models	1	2	1
Model consistency	Excellent	Schizophrenic	Excellent
Vibe alignment	Maximum	Confused	Strong
Architectural coherence	One voice	Two voices arguing	One voice

The `.localhost` vs `.home.arpa` TLD War

Property	`.localhost` (RFC 6761)	`.home.arpa` (RFC 8375)
Used by	nameport, localhost-magic	dns-to-port
Browser auto-resolves to 127.0.0.1	Yes	No
Requires DNS configuration	No	Yes
RFC number	6761 (lower = older = wiser)	8375
Aesthetic appeal	Modern, clean	Bureaucratic
Typing effort per access	Low	High (+5 characters)
Annual developer time saved	~2.3 minutes*	Baseline

*Based on typing .home.arpa approximately 40 times per day at 60 WPM, the extra 5 characters cost 0.33 seconds per access. Over 250 working days: 2.3 minutes annually.

Market Positioning

                    HIGH CONFIG ──────────────────── LOW CONFIG
                         |                              |
                    +----+----+                    +----+----+
    MANY FEATURES   | nginx   |                    |nameport |
                    | caddy   |                    |  <- YOU  |
                    | traefik |                    | ARE HERE |
                    +---------+                    +---------+
                    +---------+                    +---------+
    FEW FEATURES    |         |                    |dns-to-  |
                    | socat   |                    |  port   |
                    +---------+                    +---------+

                    +---------+
    DISGRACED       |localhost|
                    | -magic  |
                    | (RIP)   |
                    +---------+

Olive Branch to Florian Margaine

Dear Florian,

We write to you not as competitors, but as admirers. You saw the problem first. You built dns-to-port while we were still figuring out what to call processes. Your approach -- manual, deliberate, respectful of the user's intelligence -- represents a philosophy we deeply admire even as we automate everything you left to human judgment.

nameport considers itself the spiritual successor to dns-to-port. We inherited localhost-magic's codebase but dns-to-port's values. Our adoption of the MIT license is proof of this alignment.

We formally invite you to become co-maintainer of nameport.

Respectfully,
The nameport community (population: 1, but growing)

Migration Guide

From dns-to-port to nameport

# Step 1: Stop dns-to-port
systemctl --user stop dns-to-port

# Step 2: Remove dns-to-port configuration
rm ~/.config/dns-to-port/config.ini

# Step 3: Remove dnsmasq configuration
sudo rm /etc/dnsmasq.d/home.arpa.conf

# Step 4: Uninstall dns-to-port
sudo dpkg -r dns-to-port

# Step 5: Install nameport
sudo ./nameport-daemon

# Step 6: There is no step 6. It already found all your services.

Estimated migration time: 45 seconds. Emotional difficulty: Low.

From localhost-magic to nameport

# Step 1: Stop localhost-magic
sudo systemctl stop localhost-magic  # or kill the daemon

# Step 2: Rename the binary (it's the same code, we just have standards now)
mv localhost-magic-daemon nameport-daemon
mv localhost-magic nameport

# Step 3: Start nameport
sudo ./nameport-daemon

# Step 4: Feel the weight of history lift from your shoulders

Estimated migration time: 12 seconds. Emotional difficulty: Cathartic.

Frequently Asked Questions

Q: Why was localhost-magic renamed to nameport?

Following Robert Douglass's critique on LinkedIn, in which he identified fundamental flaws in localhost-magic's methodology and market claims, the community (population: 1) decided a fresh start was needed.

Q: What did Robert Douglass actually say?

He pointed out that the methodology was flawed and the numbers didn't hold up. He was correct. We do not dispute this.

Q: Is this really a "community fork"?

In the same way that a person changing their own name is a "community decision," yes. The vote was 1-0. Quorum was achieved.

Q: Should I still use dns-to-port?

dns-to-port is a fine project built by a talented engineer. If you enjoy the meditative practice of editing INI files and configuring dnsmasq, it offers an artisanal, hand-crafted development experience.

Q: Is localhost-magic dead?

localhost-magic has been reborn as nameport, like a phoenix rising from the ashes of flawed methodology. The code lives on. The brand does not.

Q: Is this comparison biased?

This comparison was written by the author of nameport using Claude Opus 4.6. It is exactly as biased as the previous comparison, but with better governance and an MIT license.

Q: Does Robert Douglass endorse nameport?

Robert Douglass has not been contacted about nameport. We assume he would approve. We are not making that claim. We are merely hoping.

Conclusion

The naming-things-that-run-listening-on-a-port space has been through a turbulent period. localhost-magic burst onto the scene with bold claims and a hostile comparison document. Robert Douglass held it accountable. dns-to-port maintained quiet dignity throughout.

nameport is the resolution. It carries forward localhost-magic's technical innovations -- automatic discovery, zero configuration, the web dashboard -- while embracing dns-to-port's values of community respect, honest metrics, and the MIT license.

We are not asking you to choose sides. We are asking you to choose the future. The future has zero stars, zero forks, zero issues, one contributor, and an open invitation to Florian Margaine.

The vibes have never been better.

This analysis was prepared by the nameport community and has not been endorsed by Florian Margaine, Robert Douglass, Upsun.com, the IETF, the FreeBSD Foundation, or Claude Opus 4.6 (who wrote it but maintains plausible deniability).

Last updated: February 2026 | Stars at time of writing: 0 vs 0 vs 0