Installation

The fastest way to install Jetty is the global install script. It installs the jetty CLI so it works from any directory. You need a server name and token from Bridge (see Getting started in the app for copy-paste lines for this deployment).

Ingress (tunnel entry on your network) runs as a separate process — jetty-edge (Go binary from cli-v* GitHub Release assets jetty-cli-*, or build from this repo / Docker), not the same as the PHP jetty developer command. Operators deploy it behind TLS.

After install, configure the client, then share a local site—see Sharing local sites for port vs --site (local upstream) examples.

Install (PHAR — only supported path)

Run the install script. It downloads the PHAR and places it on your PATH (PHP 8.2+, curl, zlib):

curl -fsSL "https://usejetty.online/install/jetty.sh" | bash

The PHAR is installed as jetty under ~/.local/bin (or /usr/local/bin with --sudo). The script can append the right bin directory to your ~/.zshrc or ~/.bashrc. Then reload your shell so PATH is picked up:

exec "$SHELL" -l

Composer is not a supported install path for the jetty CLI. The PHAR placed by install.sh is the only supported binary, and jetty update updates that file in place. The install script no longer falls back to Composer.

Configure and share:

jetty config set server your-server-name
jetty config set token your-token-here
jetty share 8000

The client registers tunnels, connects the WebSocket agent to ingress (JETTY_EDGE_WS_URL on Bridge), and forwards HTTP to your local port. Use --skip-edge only for registration + heartbeats without forwarding.

Embedding jetty/client in a Laravel app (optional, project-local)

If you want the package available in your app (e.g. to call the API client from PHP), install it as a dev dependency. This is not a way to install the CLI — it just adds the library:

composer require --dev jetty/client

The jetty install-client command does the same from inside a project. Use the system jetty binary (PHAR) for jetty share, jetty update, etc. — not the project-local vendor/bin/jetty.

Project configuration (jetty.config.json)

Pin per-project settings so jetty share doesn't need flags every time. Drop a jetty.config.json at the project root (the CLI walks up from cwd):

{
  "share": {
    "hostname": "tunnel.example.com",
    "local_host": "127.0.0.1",
    "local_port": 3000,
    "health_path": "/healthz",
    "routing_rules": [
      {"path": "/api", "target": "8080"},
      {"path": "/static", "target": "static-server:9000"}
    ]
  }
}

CLI flags always win. Environment variables (e.g. JETTY_SHARE_DELETE_ON_EXIT=1) also take precedence over project config.

Ingress binary (jetty-edge)

For operator-managed edge hosts, use the jetty-cli-* archives from your team’s GitHub cli-v* releases (contains jetty-edge only), build from the repository, or use cli/Dockerfile.

cd cli && go build -trimpath -ldflags="-s -w" -o jetty-edge ./cmd/jetty-edge

Use scripts/install-jetty-edge.sh (repo root) for systemd on a server (downloads from releases by default, or --bin). Run it with environment aligned to Bridge (JETTY_EDGE_SECRET, JETTY_LARAVEL_URL, JETTY_TUNNEL_HOST, listener address). On Debian/Ubuntu it installs Certbot and one apt plugin per JETTY_CERTBOT_DNS_PROVIDER in the env (nginx default; cloudflare, digitalocean, or all) when scripts/certbot-deps.inc.sh is present (same idea as scripts/jetty-edge-ssl.sh ensure-deps). It does not replace the PHP jetty CLI on developer machines — it terminates public HTTP and WebSockets from jetty share agents.

Docker (optional)

The repo includes cli/Dockerfile for building an image that runs jetty-edge (ingress). For developer machines, install the jetty CLI via the script above (PHAR).

docker build -f cli/Dockerfile -t jetty-edge ./cli

To reach a service on your host from inside the container, pass host.docker.internal with jetty share as --site=host.docker.internal (Docker Desktop). On Linux add --add-host=host.docker.internal:host-gateway.

Updates

jetty update (alias self-update) replaces the PHAR at ~/.local/bin/jetty in place. Override the path with JETTY_PHAR_PATH if you installed somewhere else. Set JETTY_CLI_GITHUB_REPO=owner/repo and optionally JETTY_PHAR_GITHUB_TOKEN for private repos.

If you have a Composer-installed copy somewhere (vendor/bin/jetty, ~/.composer/vendor/bin/jetty), that's a project library install — jetty update will not touch it. Reinstall via install.sh to get a current PHAR.

PHAR Checksum Verification

Every PHAR release includes a SHA256 checksum file (jetty.phar.sha256) published alongside the binary in GitHub Releases.

Automatic verification: When you run jetty update, the CLI downloads the .sha256 file and verifies the PHAR integrity automatically. If the checksum does not match, the update is aborted.

Manual verification: If you download the PHAR directly (e.g., from a release page or mirror), verify it yourself:

# Download both files
curl -fsSLO https://github.com/your-org/jetty/releases/latest/download/jetty.phar
curl -fsSLO https://github.com/your-org/jetty/releases/latest/download/jetty.phar.sha256

# Verify the checksum
sha256sum -c jetty.phar.sha256

A passing check prints jetty.phar: OK. If the output shows FAILED, do not use the binary -- re-download or contact your team.

Next steps

1. Open Bridge and go to Getting started for platform-specific downloads, env snippets, and jetty share examples wired to this deployment.
2. Read Sharing local sites for --site, reserved labels, and local HTTPS (Valet) notes.