# Why Docker, GitHub, CI, Composer, and npm break Lupopedia

This is a break-condition document, not a style preference.

Docker, Kubernetes, Vercel, Netlify, GitHub Actions, Composer, npm, monorepos, and build pipelines are not "also fine." They break the model.

Lupopedia is a **multi-domain semantic OS for shared hosting**. It is not a modern single-app deploy.

This is not a Lupopedia PRD. Pair with [architecture.md](architecture.md), [auto-installer-ecosystem.md](auto-installer-ecosystem.md), and [explaining-lupopedia-to-modern-ides.md](explaining-lupopedia-to-modern-ides.md).

---

## Locked statement

Lupopedia is not a single-domain app. It is an OS that installs on thousands of domains. Each domain keeps its own registry of color nicknames and its own lookup.

That model is incompatible with Docker, Kubernetes, Vercel, Netlify, GitHub Actions, Composer, npm, monorepos, and build pipelines. Those systems assume one app, one domain, one deployment, one pipeline, one environment.

Lupopedia assumes thousands of apps, thousands of domains, thousands of registries, thousands of local authorities, thousands of independent installs, and thousands of independent lookups.

You cannot containerize that. You cannot CI/CD that. You cannot GitHub-deploy that. It breaks the entire model.

---

## 1. Not one app on one domain

Lupopedia is not:

- colorlex.com only
- lupopedia.com only
- a SaaS
- a cloud service
- a microservice cluster

It is an OS that installs on thousands -- maybe hundreds of thousands -- of domains.

Each domain keeps its own registry of color nicknames and has its own lookup.

Modern stacks assume:

- one app
- one domain
- one deployment
- one pipeline
- one environment

Lupopedia is the opposite:

- thousands of apps
- thousands of domains
- thousands of registries
- thousands of local authorities
- thousands of independent installs
- thousands of independent lookups

ColorLex is node 3 (this domain). It is a reference color node, not the only install.

---

## 2. Auto-installers require subdirectory installs

The auto-installer ecosystem (Installatron, Softaculous, Fantastico, cPanel, DirectAdmin, Plesk, AMPPS, Webuzo, host catalogs such as InMotion) installs apps as:

```text
theirdomain.com/appname/
```

Not document root as the only shape. Not Docker. Not GitHub. Not CI/CD.

They install WordPress, Joomla, Drupal, phpBB, Crafty Syntax, and hundreds of other PHP apps as subdirectories.

Lupopedia MUST follow that rule:

```text
theirdomain.com/lupopedia/
```

On this host: `colorlex.com/lupopedia/`.

---

## 3. Auto-installer apps must be pure PHP files

No Composer. No npm. No build step. No Dockerfile. No container. No GitHub pipeline.

Auto-installers:

1. unzip files
2. drop them into a folder
3. run `install.php`
4. done

If Lupopedia required `composer install`, `npm build`, `docker compose up`, or `git push` as the install path, it would be dead on arrival.

Auto-installers cannot run those. Shared hosting cannot run those. cPanel, DirectAdmin, Fantastico, Installatron, and Softaculous cannot run those.

---

## 4. Federation requires local registries

This is the part modern IDEs miss.

Lupopedia is a decentralized color authority system. Every domain becomes:

- its own registry
- its own authority
- its own lookup
- its own mapping
- its own POWERED_BY identity

This is not a cloud service. This is not one centralized database. This is not a SaaS.

It is a federated OS.

Modern pipelines assume one database, one API, one backend, one deployment.

Lupopedia assumes thousands of databases, thousands of APIs, thousands of backends, thousands of deployments.

That is incompatible with Docker-style architecture. PRD 90: `DOMAIN + COLOR.NAME.<NICKNAME> -> COLOR.HEX6.<HEX6>`. Do not collapse domains into one registry to make a pipeline easier.

---

## 5. Distribution already lived here

Crafty Syntax was everywhere because auto-installers distributed it, not because a GitHub push deployed it.

Lupopedia is the upgrade of that ecosystem. It must:

- install the same way
- deploy the same way
- run the same way
- scale the same way
- federate the same way

---

## 6. Lupopedia is not a modern app

It is a multi-domain semantic OS for shared hosting.

You are not fighting the architecture. You are fighting modern assumptions.

If a change would require Docker, GitHub CI, Composer, npm, a single shared cloud database, or a root-only install, do not make the change.

---

See also:

- [local-data-model.md](local-data-model.md)
- [federation-registration-model.md](federation-registration-model.md)
- [auto-installer-ecosystem.md](auto-installer-ecosystem.md)
- [explaining-lupopedia-to-modern-ides.md](explaining-lupopedia-to-modern-ides.md)
- [architecture.md](architecture.md)
- [installation-notes.md](installation-notes.md)

Home: [../index.html](../index.html)
