Jetty

Documentation for Jetty

Future work

Ideas for Jetty after the core tunnel flow (Bridge + edge + agent) is reliable and shippable. Not a committed roadmap—prioritize by audience (solo devs vs teams vs enterprise) and maintenance cost.

Product & positioning

  • Clear “why Jetty” story — one page: self-host/hybrid option, PHP-first CLI, how it compares to ngrok/Cloudflare Tunnel/localtunnel for your target users.
  • Stable preview URLs — same subdomain across restarts, or reserved names per project/team (reduces friction vs random URLs every time).
  • Usage transparency — fair limits, predictable behavior when limits hit, simple dashboards for active tunnels and recent traffic.

Teams & governance

  • Workspaces / organizations — shared tunnels, roles (viewer vs operator), per-project API tokens.
  • Audit trail — who created or revoked a tunnel, when, and optional export for compliance reviews.
  • Policies — optional SSO, IP allowlists, session lifetime, mandatory 2FA for dashboard accounts.

Developer experience

  • Declarative configjetty.yml (or similar) in the repo: local targets, named shares, CI-friendly non-interactive setup.
  • Multi-service routing — one public hostname with path- or host-based routing to different local ports (web, API, WS).
  • Better diagnostics — structured errors for DNS, TLS, and agent disconnects; suggested fixes in the CLI output.
  • Connection health — lightweight RTT/reconnect/throughput hints in CLI or dashboard so “slow tunnel” is explainable without raw tcpdump.

Security

  • Optional edge auth — OAuth, JWT validation, or basic auth in front of localhost (useful for demos and staging).
  • mTLS / client certificates — for partners or internal tools that must not be wide-open on the public internet.
  • Request inspection (privacy-aware) — opt-in, sanitized request/response preview for debugging; clear defaults that avoid leaking secrets.

Infrastructure & operations

  • Regional / residency options — document and productize edge region selection where it matters for latency or data handling.
  • Self-host / hybrid hardening — backup/restore for Bridge, health checks, runbooks for edge upgrades (build on existing systemd/deploy docs).
  • Observability — metrics and logs hooks operators expect (structured logs, optional Prometheus-style endpoints where appropriate).

Integrations

  • Chat notifications — Slack/Discord/email for tunnel lifecycle (up, down, expiring soon).
  • Git forges — post or update preview URLs on pull requests (GitHub/GitLab) where that fits your workflow.

CLI & packaging

  • PHAR / Composer parity — keep install paths smooth; document token rotation and non-interactive flows for servers and CI.
  • Shell completions & discoverabilityjetty help topics, examples for common stacks (Laravel, Vite, Docker port mapping).

Documentation & onboarding

  • Troubleshooting matrix — symptom → likely cause → fix (agent not connected, wrong local URL, DNS, TLS, firewall).
  • Architecture diagram — Bridge vs edge vs agent, for contributors and for buyers who need a quick technical overview.

Plain-language ideas

These are intentionally easy to explain to someone who is not deep in networking—they are product directions, not promises.

  • QR code for your link — show a QR code next to the public URL so phones can open your demo without typing a long address.
  • One-click copy — a single obvious “copy HTTPS URL” action in the CLI output and dashboard so sharing links is frictionless.
  • Password on the public URL — optional simple password so your preview is not open to the entire internet.
  • Auto-expire — “turn this off after 30 minutes” (or similar) so you do not accidentally leave a tunnel running.
  • Big connection status — clear green/red “tunnel is up / tunnel is down” before you debug your app.
  • Recent tunnels list — see your last few URLs in the dashboard to resend or compare without digging through logs.
  • Docker-friendly hints — short help when your app listens inside a container and localhost is not the obvious port.
  • Webhook inbox — a simple view of incoming webhook payloads for services that need a public callback URL.
  • Send link to someone — share the preview URL via email or message with a prefilled note from the dashboard.
  • Mobile-friendly dashboard — check status and copy links from a phone without needing a laptop.

When prioritizing, bias toward: reliability and clear failure modes first, then team/audit if selling to organizations, then integrations for adoption inside companies.