overview:"Empfohlener Standard-Stack: Next.js (React) + Payload CMS (self-hosted) + PostgreSQL, alles als Docker-Images über GitHub → Coolify. Cursor/MCP für die Entwicklung, GitHub Actions für Qualitätssicherung vor dem Deploy."
Du bist unsicher bei CMS und Frontend – hier ist ein **bewährtes Default**, das zu deinen Vorgaben passt (React, Animationen, Docker, Coolify, KI/MCP, CI):
| Schicht | Technologie | Warum |
|---------|-------------|--------|
| **Frontend** | [Next.js 15](https://nextjs.org) (App Router, TypeScript) | SEO/SSR/ISR, React-Ökosystem, `output: 'standalone'` für ein schlankes Production-Docker-Image |
| **Animationen** | GSAP (+ ScrollTrigger), Framer Motion, Lenis | GSAP für Scroll/Timeline-Premium-Feel; Framer für UI-Micro-Interactions; Lenis kennst du bereits aus FlixCooks |
| **CMS** | [Payload CMS 3](https://payloadcms.com) (eigener Container) | TypeScript, Postgres-native, Admin-UI out of the box, Docker-freundlich, passt zu Coolify wie dein aktuelles Postgres-Setup |
| **Datenbank** | PostgreSQL 16 (Coolify Database Service) | Eine Instanz, getrennte DBs/User für CMS vs. App optional |
| **Runtime / Deploy** | Docker + [Coolify](https://coolify.io) | Git-Webhook → Build → Traefik/HTTPS; du hast das Muster schon in [docs/COOLIFY.md](docs/COOLIFY.md) |
| **Lokale Dev** | `docker compose` (Web + CMS + Postgres) | Parität zu Production, wie [docker-compose.yml](docker-compose.yml) bei FlixCooks |
**Alternative Frontend:** Vite + React SPA + nginx-Image – maximal frei für reine Animation-Landingpages, aber schlechteres SEO und kein ISR ohne Extra-Aufwand. **Alternative CMS (weniger Ops):** Sanity/Contentful (Cloud) – nur Frontend-Container auf Coolify. **Alternative CMS (kein Backend):** Tina/Decap + Markdown im Repo – gut für Blogs, schwächer für Redakteur:innen ohne Git.
---
## Zielarchitektur auf Coolify
```mermaid
flowchart TB
subgraph dev [Entwicklung]
Cursor[Cursor + MCP]
LocalCompose[docker compose]
Cursor --> LocalCompose
end
subgraph github [GitHub]
Repo[Monorepo]
GHA[GitHub Actions CI]
Repo --> GHA
end
subgraph coolify [Coolify Server]
PG[(PostgreSQL)]
CMS[Payload CMS Container]
WEB[Next.js Container]
Traefik[Traefik HTTPS]
PG --> CMS
CMS -->|REST/GraphQL| WEB
Traefik --> WEB
Traefik --> CMS
end
dev -->|push main| Repo
GHA -->|grüner Build| Repo
Repo -->|Webhook Deploy| coolify
```
**Drei Coolify-Ressourcen** (analog zu deinem FlixCooks-Setup: Postgres + App):
1.**PostgreSQL**– internal URL, nicht öffentlich
2.**CMS-App**– Dockerfile aus `apps/cms`, Port z. B. 3001, Env: `DATABASE_URL`, `PAYLOAD_SECRET`
3.**Web-App**– Dockerfile aus `apps/web`, Port 3000, Env: `CMS_URL` (internal), `REVALIDATE_SECRET` für On-Demand-ISR
Persistenz: Postgres-Volume (Inhalte), optional Volume für CMS-Uploads (`/app/media`).
---
## Repository-Struktur (Greenfield-Vorlage)
Ein Repo pro „Site-Familie“ oder Monorepo für mehrere Marken:
```
my-site/
├── apps/
│ ├── web/ # Next.js
│ │ ├── Dockerfile
│ │ ├── src/
│ │ └── next.config.ts # output: 'standalone'
│ └── cms/ # Payload
│ ├── Dockerfile
│ └── payload.config.ts
├── packages/
│ └── shared-types/ # optional: gemeinsame TS-Typen CMS ↔ Web
├── docker-compose.dev.yml # nur Postgres (wie bei FlixCooks)
├── .github/workflows/
│ ├── ci.yml
│ └── gemini-pr-review.yml # optional, aus FlixCooks übernehmen
├── .cursor/
│ └── mcp.json # MCP-Server für das Team
├── .agents/
│ ├── brain.md # Architektur für KI (Pattern aus FlixCooks)
│ └── rules/AGENT.md
└── docs/
└── COOLIFY.md
```
---
## Frontend-Stack (React + Animationen)
**Kern:**
- **Next.js App Router** – Seiten in `app/`, Server Components für CMS-Daten, Client Components nur für Animation/Interaktion
- **TypeScript** – strikt; Typen aus Payload generieren (`payload generate:types`)
- **Styling** – CSS Modules oder Tailwind (nur wenn du es willst; FlixCooks bleibt bei Vanilla CSS – für neue React-Sites ist Tailwind optional, nicht Pflicht)
**Warum Payload als Default:** Self-hosted, eine Postgres-URL, Admin unter `/admin`, Collections/Blocks für Seitenmodule, Media-Uploads, Webhooks – alles containerisierbar.
**Coolify Env (CMS):**
-`DATABASE_URL`– internal Postgres URL (gleiches Muster wie [docs/COOLIFY.md](docs/COOLIFY.md) Zeilen 33–43)
-`PAYLOAD_SECRET`– langer Zufallswert (nur Secrets, nie ins Repo)
**Workflow `ci.yml`** (bei jedem PR + push auf `main`):
1.**checkout**
2.**Node 22** + Cache (`apps/web`, `apps/cms`)
3.**Parallel jobs oder Matrix:**
-`npm run lint` (ESLint)
-`npm run typecheck` (`tsc --noEmit`)
-`npm run build` (Web + CMS)
4.**Docker build test** (ohne Push):
-`docker build -f apps/web/Dockerfile apps/web`
-`docker build -f apps/cms/Dockerfile apps/cms`
5.**(optional) Playwright** gegen `docker compose up`– Smoke: Startseite, eine CMS-Seite, Health endpoints
6.**(optional) PR Review** – bestehendes Gemini-Workflow aus FlixCooks wiederverwenden
**Branch-Schutz:**`main` nur mit grünen Required Checks mergebar.
Coolify deployt **nach** Merge – CI blockiert kaputte Images, Coolify baut das echte Production-Image (oder du pushst zu GHCR – für den Start reicht Coolify-eigener Build).
---
## KI-gestützte Entwicklung mit MCP
**Cursor `mcp.json` (Team-Standard):**
| MCP | Zweck |
|-----|--------|
| **GitHub** | Issues, PRs, Actions-Logs aus dem Chat |
Du kannst FlixCooks auf Coolify weiterbetreiben und **neue Projekte** im Monorepo-Template starten. Eine spätere Migration FlixCooks → Next wäre ein separates Projekt (Content-Export aus Postgres/JSON → Payload-Collections).
---
## Nächste konkrete Schritte (nach Plan-Freigabe)
1.**Greenfield-Repo** aus der Struktur oben scaffolden (oder `create-payload-app` + Next in Monorepo).
2.**Minimale Collections** in Payload: `pages`, `recipes` (oder `projects`), `siteSettings`, Media.
3.**Dockerfiles + compose** + `docs/COOLIFY.md` vom FlixCooks-Muster kopieren/adaptieren.
4.**GitHub Actions `ci.yml`** anlegen.
5.**Coolify:** Postgres → CMS → Web → Webhook Revalidate testen.
6.**`.cursor/mcp.json` + `.agents/brain.md`** für das neue Repo.
Wenn du willst, kann im nächsten Schritt ein **konkretes Starter-Repo** (Dateien + minimale Hero-Animation + eine Payload-Collection) direkt in einem neuen Ordner oder Branch angelegt werden.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
smacks