Context
When you ./buddy dev a Stacks app today, dev traffic doesn't land on a proper HTTPS origin with a friendly per-app domain — instead it's localhost:<port> and HTTP. Per Chris's 2026-05-07 task drop:
"please make sure you harden rpx (and tlsx bc its used in rpx) if
./buddy devdoesn't utilize proper https and pretty-app-url.localhost domains (like valet, in some ways)"
The reference behaviour is Laravel Valet — every project gets https://<app-name>.test (or .localhost in our flavour), with a trusted local CA so the browser doesn't yell at you. We have the building blocks (rpx for proxying, tlsx for cert issuance) but the integration isn't there yet.
Acceptance
./buddy dev(in a Stacks app, e.g.pet-store,training,paweldregan) starts the dev server reachable athttps://<app-name>.localhost(HTTPS, valid cert from our locally-trusted CA), nothttp://localhost:<port>.- The cert chain is trusted out-of-the-box — no browser warnings, no manual cert installation step beyond the one-time CA install (which
tlsxshould handle). - Multiple apps can run concurrently and each gets its own
*.localhosthost without port collisions on 443 (rpx fronts them all). - Works on macOS (primary dev env). Linux + Windows feasibility noted but not blocking.
- Trial against at least 3 real apps before declaring done:
pet-store,training,paweldregan.
Open questions
.localhostvs.testvs.dev: Chris's wording is*.localhost. macOS resolves*.localhostto127.0.0.1natively (RFC 6761) so no/etc/hostsediting or dnsmasq required — likely the right choice.- Single shared rpx process vs one-per-app: a single rpx fronting 443 with vhost routing is the simpler model.
Related
stacksjs/tlsx— cert issuance side; will likely need a paired issue if its CA install / wildcard cert flow is missing pieces (file when scoped from rpx work).