Remove automatic wildcard cert assumption. Each service gets its own
cert by default. Wildcards are user-initiated via the Certificates page.
Backend:
- HAProxy L7 frontend uses cert directory (/etc/haproxy/certs/)
instead of single wildcard file — loads all PEMs, serves by SNI
- Cert status API shows every registered service individually with
coveredBy field when a wildcard cert covers the domain
- Reconciliation filters L7 routes to services that have a cert
- No auto-provisioning in reconciliation (just warnings)
Frontend:
- Certificates page shows per-service cert status
- "Provision" button for individual certs
- "Add Wildcard" form for opt-in wildcard provisioning
- Fixed CloudflareComponent type errors from cert API changes
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
New dedicated Certificates page in Wild Central UI showing:
- All tracked certs (central, wildcard, per-service)
- Status (valid with days remaining, or missing)
- Per-domain Provision button
- Renew All button
Cert provisioning is now user-initiated only — reconciliation logs
warnings about missing certs but does NOT auto-provision. This
prevents unexpected wildcard cert requests on startup.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
API changes:
- /api/v1/cert/status now returns all relevant certs (central,
wildcard, per-service) with existence status and expiry
- /api/v1/cert/provision accepts ?domain= param for per-domain
provisioning
- Removed stale syncHAProxy references, uses reconcileNetworking
UI changes:
- Added TLS Certificates card to Cloudflare page showing cert status
for each domain with provision/renew actions
- Updated useCert hook and cert API types for new response format
Next: extract into dedicated Certificates page.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Replace "Instance Routes" with "Registered Services" on the Central
Ingress page. Services are fetched from /api/v1/services and display
name, domain, backend, source, reach level, and backend type.
Central no longer manages instances directly — it shows services
registered by Wild Cloud, Wild Works, and itself.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
VITE_API_BASE_URL must be empty (relative URLs) so API calls go to
the same origin the browser loaded the page from. Setting it to
http://localhost:15055 breaks when accessing via LAN hostname since
the browser resolves localhost to its own machine, not the server.
The Go backend handles /api/v1/* routes before the Vite proxy
catch-all, so relative URLs work correctly in dev mode.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Vite dev server pinned to port 5174 (avoids conflict with Wild Cloud on 5173)
- .envrc updated with WILD_CENTRAL_VITE_URL=http://localhost:5174
- API base URL set to http://localhost:15055 via .env
- Page title changed to "Wild Central"
Restart air and the Vite dev server to pick up these changes.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Extract Central pages from the wild-cloud web app into a standalone
React app for Wild Central. Includes:
- Central overview, DNS, DHCP, Firewall, VPN, Ingress, CrowdSec pages
- Simplified sidebar with Central-only navigation
- Branding updated to "Wild Central"
- All Cloud-specific pages, components, hooks, and API services removed
- TypeScript type-check and production build pass
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
