Move Rails into k8s pod, CLI becomes kubectl patch

### Type Feature ### Lineage Standalone -- discovered during networking debugging session. The current nginx-bridge architecture has durability, security, and complexity issues that are eliminated by running Rails inside the cluster. ### Repo `ldraney/mdview` ### User Story As a developer using mdview I want the rendering server to run in k8s instead of on archbox directly So that the Funnel stays up reliably, LAN exposure is eliminated, and the nginx bridge is unnecessary ### Context mdview currently runs puma on archbox and uses an nginx pod in k8s as a bridge to forward Tailscale traffic to it. This requires puma to bind `0.0.0.0` (exposing port 3137 on LAN), a hardcoded Tailscale IP in the deployment, and a terminal session to keep puma alive. The westside-ror overlay already solves this with a pod-based architecture using hostPath mounts. mdview should adopt the same pattern. Full design doc: `docs/networking/kubectl-cli-architecture.md` ### File Targets Files the agent should modify or create: - `bin/mdview` -- rewrite to kubectl patch instead of rails server - `pal-e-deployments/overlays/mdview/deployment.yaml` -- Rails pod with hostPath volume, replace nginx - `pal-e-deployments/overlays/mdview/service.yaml` -- port 3000 targeting Rails directly Files the agent should remove: - `pal-e-deployments/overlays/mdview/configmap.yaml` -- nginx config no longer needed Files the agent should NOT touch: - `app/` -- Rails application code stays the same - `pal-e-deployments/overlays/mdview/ingress.yaml` -- Tailscale Ingress config unchanged ### Acceptance Criteria - [ ] When I run `mdview path/to/file.md`, the k8s deployment updates and the file is viewable at `https://mdview.tail5b443a.ts.net` - [ ] When I run `mdview` with a different file, the pod restarts and serves the new file - [ ] When no terminal session is open, the Funnel URL still serves the last-viewed file - [ ] Port 3137 is no longer listening on archbox - [ ] `192.168.x.x:3137` from a LAN device is no longer reachable ### Test Expectations - [ ] Manual: run `mdview docs/networking/analogy.md`, verify Funnel URL renders it - [ ] Manual: run `mdview README.md`, verify Funnel URL switches to README - [ ] Manual: close all terminals, verify Funnel URL still works - [ ] Manual: scan archbox ports, verify 3137 is closed - Run command: `curl -s -o /dev/null -w "%{http_code}" https://mdview.tail5b443a.ts.net` ### Constraints - Follow the westside-ror overlay as the reference pattern for pod + hostPath - Pod restart latency of a few seconds on file switch is acceptable - Must work with any absolute path on archbox (not limited to ~/mdview) - The Rails app code must not change -- only infrastructure and CLI ### Checklist - [ ] PR opened - [ ] nginx bridge removed - [ ] kubectl CLI tested - [ ] Funnel verified end-to-end - [ ] No unrelated changes ### Related - `ldraney/pal-e-deployments` -- overlay changes live here - westside-ror overlay -- reference implementation of same pattern

ldraney commented

2026-05-22 12:13:41 +00:00

Owner

Type

Feature

Lineage

Standalone -- discovered during networking debugging session. The current nginx-bridge architecture has durability, security, and complexity issues that are eliminated by running Rails inside the cluster.

Repo

ldraney/mdview

User Story

As a developer using mdview
I want the rendering server to run in k8s instead of on archbox directly
So that the Funnel stays up reliably, LAN exposure is eliminated, and the nginx bridge is unnecessary

Context

mdview currently runs puma on archbox and uses an nginx pod in k8s as a bridge to forward Tailscale traffic to it. This requires puma to bind 0.0.0.0 (exposing port 3137 on LAN), a hardcoded Tailscale IP in the deployment, and a terminal session to keep puma alive. The westside-ror overlay already solves this with a pod-based architecture using hostPath mounts. mdview should adopt the same pattern.

Full design doc: docs/networking/kubectl-cli-architecture.md

File Targets

Files the agent should modify or create:

bin/mdview -- rewrite to kubectl patch instead of rails server
pal-e-deployments/overlays/mdview/deployment.yaml -- Rails pod with hostPath volume, replace nginx
pal-e-deployments/overlays/mdview/service.yaml -- port 3000 targeting Rails directly

Files the agent should remove:

pal-e-deployments/overlays/mdview/configmap.yaml -- nginx config no longer needed

Files the agent should NOT touch:

app/ -- Rails application code stays the same
pal-e-deployments/overlays/mdview/ingress.yaml -- Tailscale Ingress config unchanged

Acceptance Criteria

When I run mdview path/to/file.md, the k8s deployment updates and the file is viewable at https://mdview.tail5b443a.ts.net
When I run mdview with a different file, the pod restarts and serves the new file
When no terminal session is open, the Funnel URL still serves the last-viewed file
Port 3137 is no longer listening on archbox
192.168.x.x:3137 from a LAN device is no longer reachable

Test Expectations

Manual: run mdview docs/networking/analogy.md, verify Funnel URL renders it
Manual: run mdview README.md, verify Funnel URL switches to README
Manual: close all terminals, verify Funnel URL still works
Manual: scan archbox ports, verify 3137 is closed
Run command: curl -s -o /dev/null -w "%{http_code}" https://mdview.tail5b443a.ts.net

Constraints

Follow the westside-ror overlay as the reference pattern for pod + hostPath
Pod restart latency of a few seconds on file switch is acceptable
Must work with any absolute path on archbox (not limited to ~/mdview)
The Rails app code must not change -- only infrastructure and CLI

Checklist

PR opened
nginx bridge removed
kubectl CLI tested
Funnel verified end-to-end
No unrelated changes

ldraney/pal-e-deployments -- overlay changes live here
westside-ror overlay -- reference implementation of same pattern

Rows
Columns

Move Rails into k8s pod, CLI becomes kubectl patch #9