# NX9 Philosophy: Engineering Beyond Frameworks

## A Real-World Case Study in Software Minimalism, Explicit Routing, and Reduced Attack Surface

> *"The best way to reduce complexity is not to manage more software—it is to deploy less software."*

---

## Executive Summary

This case study examines the first publicly accessible deployment of **NX9** and the unsolicited Internet traffic it received immediately after exposure.

The objective was not to conduct a penetration test or security benchmark. Instead, the production access logs were analyzed to understand how real-world Internet scanners interacted with a deliberately minimal software stack.

The results were revealing.

During the observed period:

* **362 HTTP requests** were received.
* **331 requests (91.4%)** resulted in **`404 Not Found`**.
* **20 requests (5.5%)** returned **`304 Not Modified`**, indicating normal browser caching.
* **11 requests (3.1%)** returned **`200 OK`**, serving legitimate published resources.

The overwhelming majority of incoming requests were **not attempts to use the application**.

They were attempts to identify technologies that were never deployed.

---

# Introduction

Modern software engineering frequently begins with a familiar question:

> **"Which framework should we use?"**

NX9 begins with a different question:

> **"Do we need one at all?"**

This distinction is fundamental.

NX9 is not opposed to frameworks.

Frameworks such as React, Angular, Laravel, Spring Boot, Django, and Next.js have solved genuine engineering problems at enormous scale.

React solved Facebook's UI challenges.

Angular addressed Google's enterprise applications.

Laravel transformed PHP productivity.

Those are significant engineering achievements.

The question NX9 asks is simply:

> **Does our project have those same problems?**

Many self-hosted services do not.

A documentation website.

A URL shortener.

An authentication server.

A digital timestamping service.

A lightweight dashboard.

These applications often require reliability, simplicity, maintainability, and operational transparency far more than they require extensive framework ecosystems.

NX9 therefore adopts a different philosophy.

---

# The NX9 Philosophy

Every NX9 project follows a common set of engineering principles.

* Privacy First
* Self-Hosted First
* Linux Native
* Rust Native
* Single Binary Applications
* Explicit Routing
* Minimal Dependencies
* Open Source (FOSS)
* No Vendor Lock-In
* Operational Simplicity

Rather than beginning with a framework and removing features, NX9 begins with the application itself and adds only the software required to solve the problem.

Nothing more.

Nothing less.

---

# Complexity Is Not Free

Every dependency introduces responsibility.

Someone must eventually:

* install it;
* configure it;
* update it;
* monitor it;
* patch it;
* audit it;
* understand it.

Modern web applications frequently include:

* thousands of npm packages;
* hundreds of indirect dependencies;
* build systems;
* transpilers;
* runtime environments;
* middleware layers;
* plugins;
* framework conventions.

Each component may be valuable.

Collectively, they also increase operational complexity and expand the software that must be maintained throughout the application's lifetime.

NX9 therefore asks a much simpler engineering question:

> **Can this problem be solved with significantly less software?**

If the answer is yes, simplicity becomes the preferred engineering decision.

---

# Production Snapshot

This study is based entirely on production access logs collected after **nx9.in** became publicly accessible.

This was **not**:

* a penetration test;
* a laboratory simulation;
* synthetic benchmark traffic.

It was ordinary Internet traffic.

Within a short period of public exposure:

* automated vulnerability scanners began probing the server;
* legitimate browsers accessed the published website;
* Twitter/X generated preview cards;
* search crawlers indexed the content;
* additional independent scanners continued probing throughout the observation period.

---

# Observed Traffic

During the observation period:

| Response         |   Count | Percentage |
| ---------------- | ------: | ---------: |
| 404 Not Found    | **331** |  **91.4%** |
| 304 Not Modified |      20 |       5.5% |
| 200 OK           |      11 |       3.1% |

The most striking observation is that **over 91% of incoming requests were not attempts to use the application.**

They were attempts to discover software that was never deployed.

---

# What Were the Bots Looking For?

Representative examples include:

```text
/.env
/vendor/.env
/wp-admin/
/wp-content/
/wp-includes/
/phpinfo.php
/admin.php
/public/css.php
/f35.php
/222.php
/chosen.php
/vercel.json
/vite.config.ts
/vendors~main.bundle.js
/vue/
/v1/admin/
```

These requests reveal remarkably consistent assumptions.

| Requested Resource       | What the Scanner Expected   |
| ------------------------ | --------------------------- |
| `.env`                   | Laravel / PHP configuration |
| `vendor/.env`            | Composer project            |
| `wp-admin`               | WordPress                   |
| `wp-content`             | WordPress plugins           |
| `phpinfo.php`            | PHP runtime                 |
| `admin.php`              | PHP administration panel    |
| `f35.php`                | PHP web shell               |
| `public/css.php`         | Vulnerable PHP application  |
| `vite.config.ts`         | Vite project                |
| `vendors~main.bundle.js` | Webpack / React build       |
| `vercel.json`            | Vercel deployment           |
| `vue/.env`               | Vue application             |

The scanners were not attempting to identify NX9.

They were attempting to identify technologies commonly deployed across today's Internet.

---

# What Actually Happened?

Every vulnerability probe received essentially the same response.

```text
404 Not Found
```

Not because NX9 blocked the request.

Not because a Web Application Firewall intercepted it.

Not because an intrusion detection system analyzed it.

The requested resources simply did not exist.

This distinction is critical.

There is a significant engineering difference between software successfully defending itself and software that was never deployed in the first place.

---

# Explicit Routing

NX9 applications expose only routes intentionally defined by the developer.

Conceptually:

```text
/
├── /
├── /projects
├── /about
├── /contact
└── 404
```

There is:

* no automatic controller discovery;
* no runtime file resolution;
* no directory-based routing;
* no framework-generated endpoints.

If a route was never implemented, it simply cannot be reached.

Unknown requests terminate immediately at the fallback handler.

---

# Security Begins Before Deployment

Security is often discussed in terms of:

* firewalls;
* intrusion detection systems;
* endpoint protection;
* monitoring platforms.

Those remain valuable.

However, architecture itself is also a security decision.

The NX9 deployment contained:

* no PHP interpreter;
* no WordPress;
* no Laravel;
* no Composer vendor directory;
* no Node.js runtime;
* no exposed `.env`;
* no framework-generated administration interface;
* no debug endpoints.

Those components were never installed.

Consequently, they never became part of the deployment's attack surface.

This is not **security through obscurity**.

It is **security through intentional software selection**.

---

# A Smaller Stack

Many modern web deployments resemble:

```text
Internet
      │
      ▼
Reverse Proxy
      │
      ▼
Runtime
      │
      ▼
Framework
      │
      ▼
Middleware
      │
      ▼
Plugins
      │
      ▼
Packages
      │
      ▼
Application
```

NX9 deliberately reduces the deployment:

```text
Internet
      │
      ▼
Nginx
      │
      ▼
Rust Binary
      │
      ▼
Explicit Route Table
      │
      ▼
Application Logic
```

The objective is not minimalism for its own sake.

The objective is engineering proportional to the problem being solved.

---

# Frameworks Are Not the Enemy

This case study should not be interpreted as criticism of frameworks.

Frameworks solve difficult engineering problems.

Many projects genuinely require them.

NX9 simply argues that every dependency should justify its existence.

Engineering is not about choosing the most fashionable technology.

It is about choosing the most appropriate technology.

Sometimes that means a sophisticated framework.

Sometimes that means a single Rust binary.

---

# Legitimate Traffic Continued Normally

An equally important observation is what **did** work.

Legitimate clients successfully accessed the application throughout the observation period.

This included:

* desktop browsers;
* Android browsers;
* Twitter/X preview generation;
* search engine crawlers;
* browser cache validation (`304 Not Modified`).

The minimal deployment remained fully functional for intended users while exposing no unnecessary application surface.

---

# Non-Goals

This article does **not** claim:

* that Rust is immune to vulnerabilities;
* that frameworks are insecure;
* that 404 responses alone provide security;
* that NX9 cannot contain bugs.

Instead, it demonstrates a much simpler engineering principle:

> **Software that is never deployed cannot become part of your deployment's attack surface.**

---

# Lessons Learned

The production logs reveal a surprisingly simple truth.

The overwhelming majority of unsolicited Internet traffic was not exploring the application itself.

It was exploring assumptions.

The scanners assumed:

* PHP;
* WordPress;
* Laravel;
* Vue;
* Node.js;
* Composer;
* Vite;
* Vercel;
* common administration panels.

NX9 deliberately deployed none of them.

The result was not that sophisticated defensive software defeated the attacks.

The result was that the attacks found nothing matching their expectations.

---

# Conclusion

Every NX9 project begins with the same engineering question:

> **What is the smallest amount of software required to solve this problem well?**

Sometimes that answer includes a framework.

Often it does not.

This case study demonstrates that software minimalism is not merely an aesthetic preference.

It is an architectural decision with practical operational consequences.

During the observed period, more than **91%** of incoming requests were attempts to identify technologies that simply were not present.

That outcome was not accidental.

It was the direct consequence of choosing a smaller, simpler, explicitly designed software stack.

**Build only what you need.**

**Deploy only what you trust.**

**Maintain only what you own.**

Because every component you choose **not** to deploy is one less component to configure, patch, monitor, audit—and one less component available to be targeted.

**That is the NX9 philosophy.**