diff --git a/Vim Cheatsheet.md b/(Neo) Vim/Vim Cheatsheet.md
old mode 100755
new mode 100644
similarity index 100%
rename from Vim Cheatsheet.md
rename to (Neo) Vim/Vim Cheatsheet.md
diff --git a/neovim-setup.md b/(Neo) Vim/neovim-setup.md
similarity index 100%
rename from neovim-setup.md
rename to (Neo) Vim/neovim-setup.md
diff --git a/verschiedene/Ansible.md b/verschiedene/Ansible.md
new file mode 100644
index 0000000..1d20457
--- /dev/null
+++ b/verschiedene/Ansible.md
@@ -0,0 +1,271 @@
+# 🧩 Was ist Ansible?
+
+**Ansible** ist ein Open-Source-Tool zur **Automatisierung von IT-Aufgaben**. Es wird vor allem genutzt für:
+
+* **Konfigurationsmanagement** (Server einrichten)
+* **Deployment** (Software ausrollen)
+* **Orchestrierung** (komplexe Abläufe steuern)
+
+👉 Einfach gesagt:
+Mit Ansible kannst du **wiederholbare Aufgaben automatisieren**, die sonst manuell auf Servern ausgeführt werden müssten.
+
+💡 Besonderheit:
+Ansible ist **agentenlos** – es muss nichts auf den Zielsystemen installiert werden (nur z. B. SSH-Zugang bei Linux).
+
+---
+
+# 🧠 Grundprinzip (einfach erklärt)
+
+Ansible arbeitet mit sogenannten **Playbooks** (YAML-Dateien), in denen du beschreibst:
+
+> „Was soll passieren?“ – nicht „Wie genau Schritt für Schritt?“
+
+Beispiel (vereinfacht):
+
+```yaml
+- hosts: webserver
+  tasks:
+    - name: Installiere Nginx
+      apt:
+        name: nginx
+        state: present
+```
+
+👉 Bedeutung:
+
+* Ziel: Servergruppe „webserver“
+* Aufgabe: Installiere Nginx, falls noch nicht vorhanden
+
+➡️ Wichtig: **idempotent**
+→ Der gleiche Befehl kann beliebig oft laufen, ohne Schaden anzurichten.
+
+---
+
+# 🔍 Abgrenzung zu ähnlichen Tools
+
+Ansible gehört zur Kategorie „Infrastructure as Code“. Hier ein Vergleich:
+
+### 🆚 Puppet
+
+* arbeitet mit Agenten auf Zielsystemen
+* eigene DSL (Programmiersprache)
+* komplexer Einstieg
+
+👉 Ansible:
+
+* kein Agent nötig
+* nutzt YAML (einfacher lesbar)
+
+---
+
+### 🆚 Chef
+
+* basiert stark auf Ruby
+* eher „programmatisch“
+
+👉 Ansible:
+
+* deklarativ („Zielzustand beschreiben“)
+
+---
+
+### 🆚 Terraform
+
+* erstellt Infrastruktur (Cloud, Netzwerke)
+* Fokus: „Was existiert?“
+
+👉 Ansible:
+
+* konfiguriert Systeme („Was läuft darauf?“)
+
+💡 Typische Kombination:
+
+* Terraform erstellt Server
+* Ansible konfiguriert sie
+
+---
+
+### 🆚 Docker
+
+* isoliert Anwendungen in Containern
+
+👉 Ansible:
+
+* kann Docker automatisieren (z. B. Container starten)
+
+---
+
+# 🧩 Welche Probleme löst Ansible?
+
+## 1. ❌ „Works on my machine“-Problem
+
+Unterschiedliche Umgebungen führen zu Bugs.
+
+👉 Lösung:
+
+* identische Konfiguration überall
+
+---
+
+## 2. ❌ Manuelle Server-Konfiguration
+
+Admins klicken sich durch Systeme → fehleranfällig
+
+👉 Lösung:
+
+* alles als Code definieren
+
+---
+
+## 3. ❌ Deployment-Chaos
+
+Unklare Abläufe beim Software-Rollout
+
+👉 Lösung:
+
+* automatisierte Deployments
+
+---
+
+## 4. ❌ Skalierung schwierig
+
+Mehr Server = mehr Aufwand
+
+👉 Lösung:
+
+* gleiche Playbooks für 1 oder 100 Server
+
+---
+
+# ⚙️ Typische Anwendungsfälle (mit Praxisbeispielen)
+
+## 🧪 Beispiel 1: Webserver aufsetzen
+
+Statt:
+
+* SSH einloggen
+* Pakete installieren
+* Config schreiben
+
+👉 Mit Ansible:
+
+* ein Playbook ausführen → fertig
+
+---
+
+## 🚀 Beispiel 2: Continuous Deployment
+
+In Kombination mit Tools wie:
+
+* Jenkins
+* GitLab
+
+Ablauf:
+
+1. Code wird gepusht
+2. Pipeline startet
+3. Ansible deployed neue Version
+
+---
+
+## ☁️ Beispiel 3: Cloud-Setup
+
+* Server via Terraform erstellen
+* Ansible installiert:
+
+  * Datenbank
+  * Backend
+  * Monitoring
+
+---
+
+## 🔄 Beispiel 4: Updates automatisieren
+
+```yaml
+- name: Update alle Server
+  apt:
+    upgrade: dist
+```
+
+👉 Ergebnis:
+
+* alle Systeme sind aktuell – ohne manuelles Eingreifen
+
+---
+
+# ⚠️ Herausforderungen und Grenzen
+
+## 1. 📚 Komplexität bei großen Projekten
+
+* viele Playbooks → schwer zu überblicken
+
+👉 Lösung:
+
+* Rollen & Struktur nutzen
+
+---
+
+## 2. 🐢 Performance
+
+* läuft über SSH → langsamer als agentbasierte Tools
+
+---
+
+## 3. 🧪 Debugging
+
+* Fehleranalyse manchmal schwierig
+
+---
+
+## 4. 🧑‍💻 YAML-Fallen
+
+* Einrückung kritisch („Whitespace matters“)
+
+---
+
+## 5. 🔐 Zugriffsmanagement
+
+* SSH-Keys und Rechte müssen sauber konfiguriert sein
+
+---
+
+# 🧱 Wichtige Konzepte (kurz erklärt)
+
+* **Inventory** → Liste der Zielsysteme
+* **Playbook** → Ablaufbeschreibung
+* **Task** → einzelne Aktion
+* **Role** → wiederverwendbare Struktur
+* **Module** → konkrete Funktionen (z. B. apt, copy)
+
+---
+
+# 🧭 Wann solltest du Ansible verwenden?
+
+👉 Gute Wahl, wenn du:
+
+* viele Server verwalten musst
+* wiederholbare Deployments brauchst
+* schnell starten willst (geringe Einstiegshürde)
+
+👉 Weniger geeignet:
+
+* bei extrem großen, hochdynamischen Systemen (teilweise bessere Alternativen)
+
+---
+
+# 🧠 Fazit
+
+**Ansible ist eines der zugänglichsten Tools für Automatisierung in der Softwareentwicklung.**
+
+Es hilft dir:
+
+* Fehler zu reduzieren
+* Zeit zu sparen
+* Infrastruktur reproduzierbar zu machen
+
+👉 Besonders stark ist es durch:
+
+* einfache Syntax (YAML)
+* agentenlose Architektur
+* breite Einsatzmöglichkeiten
+
diff --git a/Docker.md b/verschiedene/Docker.md
similarity index 100%
rename from Docker.md
rename to verschiedene/Docker.md
diff --git a/verschiedene/Gunicorn.md b/verschiedene/Gunicorn.md
new file mode 100644
index 0000000..398b006
--- /dev/null
+++ b/verschiedene/Gunicorn.md
@@ -0,0 +1,330 @@
+# 🧠 1. Grundsätzliche Definition
+
+**Gunicorn** (Green Unicorn) ist ein **Python-basierter HTTP-Server**, der das **WSGI-Protokoll (Web Server Gateway Interface)** implementiert. ([Wikipedia][1])
+
+👉 Vereinfacht gesagt:
+
+> Gunicorn ist die **Laufzeitumgebung**, die deine Python-Webanwendung (z. B. Flask/Django) tatsächlich **für HTTP-Anfragen erreichbar macht**.
+
+### Rolle im System
+
+```
+Browser → Webserver (z. B. Nginx) → Gunicorn → Python App (Flask/Django)
+```
+
+* Browser sendet HTTP-Request
+* Gunicorn nimmt ihn entgegen
+* Gunicorn ruft deine Python-App auf
+* Response wird zurückgegeben
+
+➡️ Gunicorn fungiert also als **Brücke zwischen Webserver und Python-Code** ([backendmesh][2])
+
+---
+
+# 🔍 2. Abgrenzung zu verwandten Begriffen
+
+Gunicorn wird oft verwechselt mit anderen Komponenten. Hier die klare Einordnung:
+
+## 🔹 Gunicorn vs. Webserver (z. B. Nginx, Apache)
+
+| Komponente        | Aufgabe                                                     |
+| ----------------- | ----------------------------------------------------------- |
+| Webserver (Nginx) | Liefert statische Inhalte (HTML, CSS, Bilder), SSL, Routing |
+| Gunicorn          | Führt Python-Code aus                                       |
+
+👉 Wichtig:
+Gunicorn ist **kein vollständiger Webserver**, sondern ein **Application Server**.
+
+➡️ Deshalb wird häufig kombiniert:
+
+* Nginx → Reverse Proxy
+* Gunicorn → Python-Ausführung ([gunicorn.org][3])
+
+---
+
+## 🔹 Gunicorn vs. WSGI
+
+* **WSGI** = Standard (Schnittstelle)
+* **Gunicorn** = konkrete Implementierung dieses Standards
+
+👉 Analogie:
+
+* WSGI = Steckdose
+* Gunicorn = konkretes Gerät, das man einsteckt
+
+---
+
+## 🔹 Gunicorn vs. andere Server
+
+| Tool     | Typ  | Besonderheit          |
+| -------- | ---- | --------------------- |
+| Gunicorn | WSGI | klassisch, stabil     |
+| uWSGI    | WSGI | sehr mächtig, komplex |
+| Uvicorn  | ASGI | für async (FastAPI)   |
+| Daphne   | ASGI | Channels / WebSockets |
+
+👉 Abgrenzung:
+
+* Gunicorn = eher **synchron / klassisch**
+* Uvicorn & Co = **async-first**
+
+---
+
+# 🧩 3. Welche Probleme löst Gunicorn?
+
+## ❌ Problem 1: Python kann nicht direkt HTTP sprechen
+
+Python-Apps (z. B. Flask) sind **keine Webserver**.
+
+👉 Gunicorn löst:
+
+* HTTP parsing
+* Request-Handling
+* Verbindung zu Python-Code
+
+---
+
+## ❌ Problem 2: Entwicklungsserver ist ungeeignet für Produktion
+
+Beispiel:
+
+```bash
+flask run
+```
+
+➡️ Nachteile:
+
+* langsam
+* unsicher
+* nicht skalierbar
+
+👉 Gunicorn bietet:
+
+* stabile Produktionsumgebung
+* parallele Verarbeitung
+* Fehlerisolierung
+
+---
+
+## ❌ Problem 3: Skalierung / Parallelität
+
+Gunicorn nutzt ein **Pre-Fork Worker-Modell**:
+
+* Master-Prozess startet mehrere Worker
+* Jeder Worker verarbeitet Requests unabhängig ([Wikipedia][1])
+
+👉 Vorteil:
+
+* bessere CPU-Auslastung
+* stabil bei Lastspitzen ([gunicorn.org][4])
+
+---
+
+## ❌ Problem 4: Standardisierung (WSGI)
+
+Ohne WSGI:
+
+* jedes Framework anders
+
+Mit Gunicorn:
+
+* einheitliche Schnittstelle für:
+
+  * Django
+  * Flask
+  * FastAPI (WSGI/ASGI-kompatibel)
+
+---
+
+# ⚙️ 4. Architektur & Funktionsweise
+
+## 🧱 Pre-Fork-Modell
+
+* 1 Master-Prozess
+* N Worker-Prozesse
+
+```
+        Master
+        / | \
+ Worker Worker Worker
+```
+
+👉 Vorteile:
+
+* Isolation (Crash betrifft nur einen Worker)
+* gute Parallelisierung
+
+---
+
+## 🔄 Worker-Typen
+
+Gunicorn bietet mehrere Modelle:
+
+| Typ                     | Einsatz                          |
+| ----------------------- | -------------------------------- |
+| sync                    | einfache APIs                    |
+| async (gevent/eventlet) | viele gleichzeitige Verbindungen |
+| threads                 | Mischung                         |
+| asyncio                 | moderne async Apps               |
+
+---
+
+# ⚠️ 5. Herausforderungen & Nachteile
+
+## ❗ 1. Kein vollwertiger Webserver
+
+Gunicorn kann nicht gut:
+
+* statische Dateien ausliefern
+* SSL terminieren
+
+👉 Lösung:
+→ Kombination mit Nginx
+
+---
+
+## ❗ 2. Konfiguration nicht trivial
+
+Beispiel:
+
+```bash
+gunicorn -w 4 -k gevent app:app
+```
+
+Fragen:
+
+* wie viele Worker?
+* sync vs async?
+* Threads?
+
+👉 falsche Wahl = schlechte Performance
+
+---
+
+## ❗ 3. Async-Limitierungen
+
+* Gunicorn ist historisch WSGI (synchron)
+* Async nur über Erweiterungen
+
+👉 Alternative:
+→ Uvicorn / Hypercorn für moderne Apps
+
+---
+
+## ❗ 4. Ressourcenverbrauch
+
+* Jeder Worker = eigener Prozess
+* hoher RAM-Verbrauch bei vielen Workern
+
+---
+
+## ❗ 5. Debugging schwieriger
+
+* mehrere Prozesse
+* Race Conditions möglich
+
+---
+
+# 💡 6. Praxisnahe Beispiele
+
+## 🧪 Beispiel 1: Flask lokal vs. Produktion
+
+### Entwicklung
+
+```bash
+flask run
+```
+
+### Produktion
+
+```bash
+gunicorn -w 4 app:app
+```
+
+👉 Effekt:
+
+* 4 parallele Worker
+* deutlich höhere Stabilität
+
+---
+
+## 🧪 Beispiel 2: Typisches Deployment
+
+```text
+Internet
+   ↓
+Nginx (SSL, Static Files)
+   ↓
+Gunicorn (Python Server)
+   ↓
+Django App
+```
+
+👉 Vorteile:
+
+* Nginx: schnell für statische Inhalte
+* Gunicorn: spezialisiert auf Python
+
+---
+
+## 🧪 Beispiel 3: Skalierung
+
+Traffic steigt → Anpassung:
+
+```bash
+gunicorn -w 8 app:app
+```
+
+👉 Mehr Worker = mehr parallele Requests
+
+---
+
+## 🧪 Beispiel 4: Async API (z. B. Chat-App)
+
+Problem:
+
+* viele offene Verbindungen
+
+Lösung:
+
+```bash
+gunicorn -k gevent -w 4 app:app
+```
+
+👉 async Worker verarbeitet tausende Verbindungen
+
+---
+
+# 🧭 7. Wann nutzt man Gunicorn?
+
+✅ Typische Einsatzfälle:
+
+* Django / Flask Apps
+* klassische REST APIs
+* Container (Docker)
+* Linux-Server
+
+❌ Weniger geeignet:
+
+* hochgradig async Systeme (→ Uvicorn)
+* statische Seiten (→ Nginx allein)
+
+---
+
+# 🧾 Fazit
+
+Gunicorn ist ein **zentraler Baustein moderner Python-Webanwendungen**:
+
+👉 Kurz gesagt:
+
+* **Definition:** WSGI HTTP Server für Python
+* **Rolle:** verbindet Webserver mit Python-Code
+* **Stärken:** einfach, stabil, production-ready
+* **Schwächen:** begrenztes Async, braucht oft Nginx
+
+---
+
+[1]: https://en.wikipedia.org/wiki/Gunicorn?utm_source=chatgpt.com "Gunicorn"
+[2]: https://www.backendmesh.com/gunicorn-python-wsgi-http-server/?utm_source=chatgpt.com "A Detailed Overview of Gunicorn: Python WSGI HTTP Server - Backendmesh"
+[3]: https://gunicorn.org/index.html?utm_source=chatgpt.com "Gunicorn - Python WSGI HTTP Server for UNIX"
+[4]: https://gunicorn.org/?utm_source=chatgpt.com "Gunicorn - Python WSGI HTTP Server for UNIX"
diff --git a/LibrechatAI.md b/verschiedene/LibrechatAI.md
similarity index 100%
rename from LibrechatAI.md
rename to verschiedene/LibrechatAI.md
diff --git a/Open WebUI.md b/verschiedene/Open WebUI.md
similarity index 100%
rename from Open WebUI.md
rename to verschiedene/Open WebUI.md
diff --git a/verschiedene/hypercorn.md b/verschiedene/hypercorn.md
new file mode 100644
index 0000000..3353e32
--- /dev/null
+++ b/verschiedene/hypercorn.md
@@ -0,0 +1,319 @@
+# 🧠 1. Grundsätzliche Definition
+
+**Hypercorn** ist ein **Python-Webserver**, genauer gesagt ein sogenannter **ASGI-Server** (und optional auch WSGI-Server).
+
+👉 Kurz gesagt:
+
+> Hypercorn ist die Software, die deine Webanwendung tatsächlich „ins Internet bringt“ und HTTP-Anfragen verarbeitet.
+
+Technisch:
+
+* implementiert die **ASGI-Spezifikation (Asynchronous Server Gateway Interface)**
+* kann **HTTP/1.1, HTTP/2, WebSockets und sogar HTTP/3** bedienen ([PyPI][1])
+* basiert auf modernen Netzwerkbibliotheken wie `h11`, `h2`, `wsproto` ([PyPI][1])
+
+👉 Beispiel:
+
+```bash
+hypercorn app:app
+```
+
+→ startet deine Web-App und macht sie erreichbar
+
+---
+
+# 🔄 2. Abgrenzung zu ähnlichen Begriffen
+
+## (a) Hypercorn vs. ASGI
+
+* **ASGI** = Standard / Schnittstelle
+* **Hypercorn** = konkrete Implementierung dieses Standards
+
+👉 Vergleich:
+
+* ASGI ist wie ein „Steckdosenstandard“
+* Hypercorn ist ein konkretes „Netzteil“
+
+---
+
+## (b) Hypercorn vs. andere Server
+
+### 1. Uvicorn
+
+* ebenfalls ASGI-Server
+* sehr schnell, minimalistisch
+
+👉 Unterschied:
+
+* Hypercorn: mehr Features (HTTP/2, HTTP/3, mehrere Event-Loops)
+* Uvicorn: oft performanter, einfacher
+
+---
+
+### 2. Gunicorn
+
+* klassischer WSGI-Server (synchron)
+
+👉 Unterschied:
+
+* Gunicorn → synchron (klassisches Request/Response)
+* Hypercorn → async + moderne Protokolle
+
+---
+
+### 3. Daphne
+
+* ASGI-Server speziell für Django Channels
+
+👉 Unterschied:
+
+* Hypercorn → universeller
+* Daphne → stärker Django-zentriert
+
+---
+
+## (c) ASGI vs. WSGI (wichtige Grundlage)
+
+| Merkmal    | WSGI     | ASGI      |
+| ---------- | -------- | --------- |
+| Modell     | synchron | asynchron |
+| WebSockets | ❌        | ✅         |
+| Echtzeit   | ❌        | ✅         |
+| Skalierung | begrenzt | besser    |
+
+👉 ASGI erlaubt **gleichzeitige Verarbeitung vieler Verbindungen** (z. B. Chats) ([DEV Community][2])
+
+---
+
+# 🚧 3. Welche Probleme löst Hypercorn?
+
+## Problem 1: Asynchrone Webanwendungen
+
+Früher:
+
+* jede Anfrage blockiert einen Thread
+
+Heute (mit Hypercorn + ASGI):
+
+* tausende Verbindungen gleichzeitig möglich
+
+👉 Beispiel:
+
+* Chat-App mit WebSockets
+* Live-Dashboard (z. B. Börsenkurse)
+
+---
+
+## Problem 2: Moderne Protokolle
+
+Hypercorn unterstützt:
+
+* HTTP/2 → Multiplexing
+* WebSockets → Echtzeitkommunikation
+* HTTP/3 (optional) → moderne Performance ([PyPI][1])
+
+👉 Beispiel:
+
+* Echtzeit-Kollaboration (Google Docs-ähnlich)
+
+---
+
+## Problem 3: Flexibilität im Event Loop
+
+Hypercorn kann verschiedene Laufzeitmodelle nutzen:
+
+* `asyncio`
+* `uvloop` (schneller)
+* `trio` (strukturierte Concurrency)
+
+👉 Vorteil:
+→ Entwickler können Architektur anpassen
+
+---
+
+## Problem 4: Vereinheitlichung
+
+Hypercorn kann:
+
+* **ASGI und WSGI Apps** bedienen ([PyPI][1])
+
+👉 Beispiel:
+
+* Alte Django-App (WSGI)
+* Neue FastAPI-App (ASGI)
+
+→ beide mit einem Server betreiben
+
+---
+
+# ⚠️ 4. Herausforderungen & Nachteile
+
+## (a) Komplexität von Async
+
+* Async-Code ist schwieriger zu verstehen
+* Fehler wie:
+
+  * Race Conditions
+  * Deadlocks
+
+👉 Beispiel:
+
+```python
+await db_call()  # blockiert Event Loop wenn falsch implementiert
+```
+
+---
+
+## (b) Deployment-Komplexität
+
+Produktionssetup oft nötig:
+
+* Reverse Proxy (z. B. Nginx)
+* TLS/HTTPS
+* Worker-Management ([Linux Command Library][3])
+
+👉 Beispiel-Setup:
+
+```
+Client → Nginx → Hypercorn → FastAPI
+```
+
+---
+
+## (c) Performance-Tuning
+
+Viele Optionen:
+
+* Worker-Anzahl
+* Event Loop
+* Timeout-Settings
+
+👉 falsche Konfiguration = schlechte Performance
+
+---
+
+## (d) Konkurrenz & Tooling
+
+* Uvicorn oft „Standard“ bei FastAPI
+* Community teilweise kleiner
+
+---
+
+# 🧪 5. Praxisnahe Beispiele
+
+## Beispiel 1: FastAPI Backend
+
+```python
+from fastapi import FastAPI
+
+app = FastAPI()
+
+@app.get("/")
+async def root():
+    return {"message": "Hello World"}
+```
+
+Start:
+
+```bash
+hypercorn main:app --workers 4
+```
+
+👉 Nutzen:
+
+* parallele Requests
+* skalierbar
+
+---
+
+## Beispiel 2: WebSocket-Server
+
+```python
+@app.websocket("/ws")
+async def websocket_endpoint(ws):
+    await ws.accept()
+    while True:
+        data = await ws.receive_text()
+        await ws.send_text(f"Echo: {data}")
+```
+
+👉 Ohne ASGI/Hypercorn:
+→ schwer oder unmöglich
+
+---
+
+## Beispiel 3: HTTP/2 API
+
+```bash
+hypercorn app:app --certfile cert.pem --keyfile key.pem
+```
+
+👉 Vorteil:
+
+* mehrere Requests über eine Verbindung
+* bessere Performance bei vielen Ressourcen
+
+---
+
+## Beispiel 4: Programmatische Nutzung
+
+```python
+from hypercorn.asyncio import serve
+from hypercorn.config import Config
+import asyncio
+
+asyncio.run(serve(app, Config()))
+```
+
+👉 Einsatz:
+
+* Integration in eigene Infrastruktur
+* Tests
+
+---
+
+# 🧩 6. Einordnung im Gesamt-Stack
+
+Typischer moderner Python-Web-Stack:
+
+```
+[Browser]
+   ↓
+[Nginx / Load Balancer]
+   ↓
+[Hypercorn (ASGI Server)]
+   ↓
+[FastAPI / Starlette / Quart]
+   ↓
+[Business Logic / DB]
+```
+
+---
+
+# 🧾 Fazit
+
+Hypercorn ist:
+
+✔ ein **moderner, flexibler ASGI-Webserver**
+✔ besonders geeignet für:
+
+* Echtzeit-Apps
+* skalierbare APIs
+* moderne HTTP-Protokolle
+
+👉 Seine Stärke liegt in:
+
+* **Asynchronität**
+* **Protokollvielfalt**
+* **Flexibilität im Runtime-Modell**
+
+👉 Seine Schwächen:
+
+* höhere Komplexität
+* stärkere Konkurrenz (z. B. Uvicorn)
+
+---
+
+[1]: https://pypi.org/pypi/Hypercorn/?utm_source=chatgpt.com "Hypercorn · PyPI"
+[2]: https://dev.to/devopsfundamentals/python-fundamentals-asgi-1m67?utm_source=chatgpt.com "Python Fundamentals: asgi - DEV Community"
+[3]: https://linuxcommandlibrary.com/man/hypercorn?utm_source=chatgpt.com "hypercorn man | Linux Command Library"