Skip to main content

brain.id86.net Wrong Container Recovery (Dummy Content on Linux Server Route)

This incident report documents how https://brain.id86.net/docs/server/linux-server/ was restored after it started serving placeholder content instead of the production Linux Server documentation.

Incident Summary​

  • Affected URL: https://brain.id86.net/docs/server/linux-server/
  • Visible symptom: the page rendered:
Dummy Content
This is a dummy file for server/linux-server/index.
  • Initial suspicion: Docusaurus sidebar issue or wrong doc path mapping
  • Confirmed root cause: brain.id86.net was routed through Cloudflare Tunnel to the docusaurus-brain2 container, which contained dummy placeholder docs for that route

Environment Context​

  • Docs source path: /opt/docker-data/apps/docusaurus/site/docs
  • Production site container: docusaurus
  • Trial/demo site container: docusaurus-brain2
  • Tunnel config: /opt/docker-data/tunnel/config/config.yml
  • Public hostname protected by Cloudflare Access / Zero Trust: brain.id86.net

Symptom Pattern​

The route did not fail with a 404 or 502.

Instead, it returned a valid page with the wrong content. That was the key clue that:

  1. Cloudflare Access was working.
  2. Cloudflare Tunnel was working.
  3. Docusaurus was responding.
  4. The hostname was simply reaching the wrong origin.

Investigation Steps​

1. Inspect the production docs source​

Checked the live docs folder under:

/opt/docker-data/apps/docusaurus/site/docs/server/linux-server/

This confirmed the production site had a real linux-server docs tree with many folders and files, not a dummy page.

2. Inspect the production landing page source file​

Checked:

/opt/docker-data/apps/docusaurus/site/docs/server/linux-server/index.md

This file existed, but its front matter was malformed because it was missing the opening and closing --- delimiters. That meant the page metadata was being treated like page body text.

Broken form found during incident:

title: Linux Server
sidebar_label: Linux Server
sidebar_position: 1

# Linux Server - Main Page

3. Inspect Docusaurus config and sidebar references​

Confirmed the route and sidebar IDs were pointing to the expected document:

  • docusaurus.config.js referenced server/linux-server/index
  • sidebars.js referenced server/linux-server/index

This ruled out sidebar misrouting as the main cause of the dummy content.

4. Inspect the trial environment​

Checked the same route inside docusaurus-brain2 source:

/opt/docker-data/apps/docusaurus-brain2/site/docs/server/linux-server/index.md

That file contained the exact placeholder content:

---
title: Dummy index
---

# Dummy Content
This is a dummy file for server/linux-server/index.

This established that the public hostname was likely serving the brain2 environment instead of production.

5. Inspect Cloudflare Tunnel ingress mapping​

Checked:

/opt/docker-data/tunnel/config/config.yml

Incorrect mapping found:

- hostname: brain.id86.net
  service: http://docusaurus-brain2:3000

This was the actual root cause.

brain.id86.net was using the demo container instead of the production docusaurus container.

Root Cause​

Two issues were present at the same time:

  1. Wrong tunnel target for brain.id86.net
  2. Malformed front matter in the production server/linux-server/index.md
  3. A custom id and slug in that file were not appropriate for this route and would break clean rebuilds

The first issue caused the public site to show dummy content.

The second issue would have caused the production landing page to render incorrectly even after fixing the tunnel mapping, because metadata lines would still appear as page body text.

Fix Applied​

Step 1. Point brain.id86.net to the production container​

Updated /opt/docker-data/tunnel/config/config.yml from:

- hostname: brain.id86.net
  service: http://docusaurus-brain2:3000

to:

- hostname: brain.id86.net
  service: http://docusaurus:3000

Step 2. Fix the production doc front matter​

Updated /opt/docker-data/apps/docusaurus/site/docs/server/linux-server/index.md to valid front matter that preserves the file-path-based route and sidebar doc ID:

---
title: Linux Server
sidebar_label: Linux Server
sidebar_position: 1
---

# Linux Server - Main Page

This was important because the sidebar and navbar already referenced the file-path doc ID server/linux-server/index. Keeping a custom id here would make future builds fail with a missing document ID error.

Step 3. Patch the existing built production output​

Because the running production container was serving prebuilt files and no host npm toolchain was available in the current shell, the active built output for this page was patched directly so the route would render correctly immediately.

Files patched:

  • /opt/docker-data/apps/docusaurus/site/build/docs/server/linux-server/index.html
  • /opt/docker-data/apps/docusaurus/site/build/assets/js/9959c336.d24b5a0d.js
  • /opt/docker-data/apps/docusaurus/site/.docusaurus/docusaurus-plugin-content-docs/default/site-docs-server-linux-server-index-md-995.json

Step 4. Restart runtime services​

Restarted the containers that needed the updated config and built output:

sudo docker restart cloudflared docusaurus

Verification Performed​

1. Confirm production tunnel mapping was updated​

Verified in:

/opt/docker-data/tunnel/config/config.yml

Expected live mapping after fix:

- hostname: brain.id86.net
  service: http://docusaurus:3000

2. Confirm the served production page no longer contained dummy content​

Verified inside the production container:

sudo docker exec docusaurus sh -lc "wget -qO- http://127.0.0.1:3000/docs/server/linux-server/ | grep -n 'Dummy Content\|linux-server-index\|Linux Server - Main Page'"

Observed result:

  • Linux Server - Main Page was present
  • Dummy Content was no longer served by the production container

3. Confirm the active generated JS payload was corrected​

Verified the built route metadata now reflected the real page title and front matter instead of the broken metadata-body rendering.

Why This Was Easy To Misdiagnose​

This issue looked like a Docusaurus routing problem at first because:

  • the URL was correct
  • the page loaded successfully
  • the content matched a valid doc route

But the route was not resolving to the wrong doc ID inside one site.

The request was going to the wrong site entirely.

That is why checking only sidebars.js and docusaurus.config.js was not enough. The full hostname-to-container mapping had to be verified in Cloudflare Tunnel.

When a Docusaurus page shows valid but wrong content:

  1. Check the source file in the intended site.
  2. Check whether the same route exists in any sibling or staging site.
  3. Inspect sidebars.js and docusaurus.config.js.
  4. Inspect the Cloudflare Tunnel ingress mapping.
  5. Verify which container is actually serving the hostname.
  6. Check for malformed front matter in the intended target page.
  7. Restart cloudflared and the target site container after fixing config.

Commands Used During Recovery​

sudo docker ps --format '{{.Names}}\t{{.Image}}'
sudo docker restart cloudflared docusaurus
sudo docker exec docusaurus sh -lc "wget -qO- http://127.0.0.1:3000/docs/server/linux-server/ | grep -n 'Dummy Content\|linux-server-index\|Linux Server - Main Page'"

Final State After Recovery​

  • brain.id86.net now routes to docusaurus
  • brain2.id86.net remains mapped to docusaurus-brain2
  • /docs/server/linux-server/ serves the production Linux Server page instead of dummy content
  • the production landing page front matter is valid again

Follow-Up Recommendation​

Keep a simple inventory of all public hostnames and their intended container origins, especially when production and staging containers share the same Docker network and similar Docusaurus structures.