# Ticket: Nginx reverse proxy and TLS standard

## Metadata
- Type: Ticket
- Status: Done
- Project: Homelab Operations
- Created: 2026-06-06
- Updated: 2026-06-06
- Priority: High

## Goal

Design and deploy a standard Nginx reverse proxy/TLS service for homelab applications.

## Why

No strong TLS solution is currently in place. The user prefers an Nginx proxy server running on the server to handle TLS and service routing where practical.

## Scope

Included:
- Decide reverse proxy placement: VM/LXC/server
- Define LAN/Tailscale-first access model
- Define certificate source and renewal process
- Define service registration process
- Define logging, backup, restore, and update expectations
- Integrate with internal DNS plan and VM/LXC template standard

Not included:
- Public exposure of services unless explicitly approved
- Migrating every existing service in the first pass

## Acceptance Criteria

This ticket is done when:
- [x] Reverse proxy architecture is selected — central Nginx reverse proxy LXC, LAN/Tailscale only, separate from dedicated DNS service.
- [x] TLS certificate approach is selected for MVP — temporary self-signed leaf cert for first smoke test; internal CA or Let's Encrypt DNS-01 remains long-term decision.
- [x] DNS dependency is documented — service names should resolve to the reverse proxy IP for proxied apps.
- [x] Nginx proxy service is deployed — CTID 105 `reverse-proxy` at `192.168.0.137`.
- [x] At least one internal service is proxied with TLS — `search.dropcutstud.io` via temporary self-signed TLS to SearXNG backend `192.168.0.133:8080`.
- [x] Runbook exists for adding a new proxied service — draft at `runbooks/nginx-reverse-proxy.md`.
- [x] Backup/update/monitoring expectations are documented — Nginx config backup configured and verified (runbook Backups/Restore section); update handling documented in Ansible managed-updates runbook; monitoring through basic health checks and Homepage dashboard

## Notes

- Coordinate with `2026-06-06-internal-dns-and-tailscale-naming.md`.
- Default access boundary remains LAN + Tailscale unless the user explicitly requests public exposure.
- 2026-06-07: Initial design captured in `tickets/artifacts/2026-06-06-internal-dns-and-tailscale-naming/01-dns-tailscale-tls-design.md`. Reverse proxy is an option and recommended as the central HTTPS routing layer; it still requires a certificate/trust approach such as internal CA for MVP or Let's Encrypt DNS-01 long-term.
- 2026-06-07: Draft implementation spec created at `tickets/artifacts/2026-06-06-nginx-reverse-proxy-and-tls-standard/02-reverse-proxy-implementation-spec.md`. Recommended first implementation is a `reverse-proxy` LXC with temporary self-signed TLS proxying SearxNG as the low-risk first backend.
- 2026-06-07: User clarified that new service creation does not require per-service approval if resources are checked first; approval was granted for this slice anyway. Live preflight found sufficient resources for a small LXC. CTID 105 `reverse-proxy` deployed and verified with SearXNG route using `curl --resolve` pending dedicated DNS.