Remove Content Pipeline system from the public repo

Removed by request - it was the one unfinished system in the repo,
and it's the user's call on what represents them publicly. Removed
completely: the README section, docs/content-pipeline.md, and the
two stacks that only existed to back it (postiz, nocodb-content).
Fixed cross-links in dns-naming.md and firewall-and-network.md that
pointed at it (replaced the public-facing-app example with the
still-present Ghost blog), and notifications.md (dropped the
reference, also fixed a leftover 'documented rather than hidden'
phrase in the same paragraph). Stat strip and stack counts updated
(55->53 stacks, 16->15 systems).
This commit is contained in:
thesabear committed 2026-08-22 22:29:38 +03:00
1 parent c1ab267a00
commit be949216bf
8 files changed
+7 -250

No files matched your search

+1 -1
View File
@@ -52,7 +52,7 @@ flowchart LR
EdgeFW --> J3["Security tooling<br/>Suricata inline IDS/IPS, cert renewal"]
```
The second reverse-proxy layer here is genuinely separate from the internal two-zone model in [`docs/dns-naming.md`](dns-naming.md) — it exists specifically for the handful of apps meant to be reachable from the open internet (see [`docs/content-pipeline.md`](content-pipeline.md) for one example), and nothing else ever routes through it.
The second reverse-proxy layer here is genuinely separate from the internal two-zone model in [`docs/dns-naming.md`](dns-naming.md) — it exists specifically for the handful of apps meant to be reachable from the open internet, and nothing else ever routes through it.
> [!IMPORTANT]
> **Failure impact, thought through in advance, not discovered during an actual outage**: if pfSense goes down, public access and outbound internet both go with it — but every internal service that doesn't depend on WAN reachability keeps running normally, including the orchestration flows in [`docs/orchestration.md`](orchestration.md), which only ever reach internal hosts. The blast radius is deliberately bounded to "the edge," not "the fleet" — a design property worth stating explicitly rather than leaving implicit, since it's exactly the kind of thing that should be known *before* an incident, not discovered during one.