Publicly Exposing Local Sites and Services in ServBay Using Pinggy

Pinggy is an extremely simple and user-friendly NAT traversal tool that leverages reverse proxy technology to securely expose your locally running web services (such as those in a ServBay environment) to the public internet. This guide offers a step-by-step walkthrough on how to use Pinggy within ServBay, helping developers quickly make local web services accessible online for remote demos, team collaboration, or receiving webhook requests.

Technical Principle

Pinggy works by establishing a secure SSH tunnel. It forwards the service port deployed on your local machine (possibly behind a NAT or firewall) to a public Pinggy server via SSH connection. When external users access the URL assigned by Pinggy, their requests are securely relayed through this tunnel to your local service.

In the context of ServBay, this means you can map a local website running within ServBay (such as: https://myproject.servbay.demo) to a public URL with Pinggy, without the need for complex port forwarding or firewall configuration.

Prerequisites

Pinggy requires no additional local client software installation. All you need is:

1. ServBay installed and running: Ensure that ServBay is properly installed on your machine, and that the local website or service you want to expose is up and running.
2. At least one running ServBay site: Configure and start one or more local websites in ServBay. These sites typically listen on local port 80 (HTTP) or 443 (HTTPS) via ServBay’s built-in Caddy or Nginx server.
3. SSH-capable terminal: macOS includes a terminal by default, or you can use any terminal emulator that supports SSH.
4. Basic SSH knowledge: Know how to execute SSH commands in your terminal.

Tunnel Configuration in Practice

Core Command

Setting up a tunnel with Pinggy is straightforward—just run a single SSH command in your terminal. The following example demonstrates how to expose a ServBay-configured website accessible at local port 443 (servbay.new) to the public internet:

ssh -p 443 -R0:localhost:443 -o StrictHostKeyChecking=no -o ServerAliveInterval=30 -t [email protected] x:localServerTls:servbay.new "u:host:servbay.new"

Important Note: Replace XXXXXXXXXXX with your username as provided by the Pinggy website (typically a string of characters). The servbay.new part should be replaced with your own local website domain configured in ServBay that you wish to expose (e.g., myproject.servbay.demo).

Here’s a breakdown of the key parameters in this command:

Parameter Component	Description
-p 443	Specifies port 443 for the SSH connection to the Pinggy server. Using the default HTTPS port increases the chances of bypassing firewalls.
-R0:localhost:443	Core of the remote port forwarding. 0 lets Pinggy pick a random public port; localhost:443 forwards all incoming traffic to local port 443. ServBay’s Caddy or Nginx typically listens on port 443 for HTTPS.
-o StrictHostKeyChecking=no	Disables SSH host key checking. Convenient for first-time connections or testing, but for production use, you should verify host keys.
-o ServerAliveInterval=30	Sends a keep-alive message every 30 seconds, preventing the SSH connection from being dropped due to inactivity.
-t [email protected]	Your Pinggy username and server address. Replace XXXXXXXXXXX with the Pinggy username you receive.
x:localServerTls:servbay.new	Pinggy custom argument, indicating your local service supports TLS (HTTPS) and specifying your site’s domain. Update this with your own.
"u:host:servbay.new"	Another Pinggy argument forcing the incoming request’s HTTP Host header to servbay.new, ensuring the correct virtual host responds — crucial if you have multiple sites (virtual hosts) configured in ServBay.

After running this command, Pinggy will print out HTTP and HTTPS URLs for public access to your local service, such as:

http://rnirh-172-188-50-148.a.free.pinggy.link
https://rnirh-172-188-50-148.a.free.pinggy.link

Service Verification

Once the tunnel is up, you can verify whether public access is working as expected in several ways:

1. Via curl (Recommended): Use curl with the -I flag (to fetch only the headers) to test your public URL. Replace the sample address with the actual Pinggy URL provided.

   curl -I https://rnirh-172-188-50-148.a.free.pinggy.link

   If everything is set up correctly, you’ll see HTTP headers similar to the following, with server details from your local web server (e.g. Nginx or Caddy):

   HTTP/1.1 200 OK
   Connection: close
   Access-Control-Allow-Credentials: true
   Access-Control-Allow-Headers: Content-Type, Authorization
   Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
   Access-Control-Allow-Origin: *
   Cache-Control: max-age=0, must-revalidate, no-cache, no-store, private
   Connection: keep-alive
   Content-Type: text/html; charset=UTF-8
   Date: Tue, 18 Feb 2025 11:51:48 GMT # The date may differ
   Expires: Sun, 02 Jan 1990 00:00:00 GMT
   Pragma: no-cache
   Server: nginx # Or caddy, depending on your ServBay setup
   Vary: Accept-Encoding
   X-Frame-Options: SAMEORIGIN
   X-Powered-By: PHP/8.4.3 # Or other stack info

   Seeing HTTP/1.1 200 OK and the correct Server header typically indicates a successful connection and response from your local ServBay web server.

2. Browser Access: Open the Pinggy HTTPS URL (such as https://rnirh-172-188-50-148.a.free.pinggy.link) in any browser, on any device—even devices outside your local network. You should see the same content as when accessing the site locally through ServBay.

3. Expected Results:

   • External users can access your local ServBay site or service via the Pinggy-provided URL.
   • If your local service uses HTTPS (ServBay generates self-signed certs by default), Pinggy will also automatically grant HTTPS access via a free, public CA-issued certificate—no extra setup required.
   • Response times and stability depend on your local network, the Pinggy server connection, and Pinggy’s own service load.

Advanced Tips

1. Expose different local ports or services: If your local service isn’t a web server or doesn’t use ServBay’s default ports 80/443, you can modify the -R parameter. For example, to expose a local service on port 8000 (say, a Python or Node.js app):

   ssh -p 443 -R0:localhost:8000 -o StrictHostKeyChecking=no -o ServerAliveInterval=30 -t [email protected]

   Note: If the service isn't a web server or doesn't handle the Host header, you typically don’t need the x:localServerTls and u:host arguments.

2. Custom domains (Pinggy Pro): Pinggy Pro users can use custom domains instead of the randomly assigned subdomains, offering a more professional public URL. Refer to Pinggy's official documentation for setup details.

3. Persistent tunnels (using autossh): SSH tunnels may drop due to network issues. If you require always-on tunnels, use the autossh tool to automatically monitor and restart dropped SSH connections. To install on macOS: brew install autossh. Use it as follows:

   autossh -M 0 -t "ssh -p 443 -R0:localhost:443 -o StrictHostKeyChecking=no -o ServerAliveInterval=30 -t [email protected] x:localServerTls:servbay.new \"u:host:servbay.new\""

   The -M 0 flag tells autossh to forgo additional monitoring ports, relying instead on SSH’s built-in keep-alive (ServerAliveInterval) for health checks.

4. Token-less commands: Pinggy lets you generate one-off commands from its website that do not require embedding your username or token. This is ideal for safely sharing commands with others without risking token exposure.

Common Use Cases

• Remote demos: Show clients or team members your locally developed website or app in the ServBay environment without deploying to staging or production.
• Webhook debugging: Receive webhook requests from third-party services (e.g., payment gateways, GitHub) and debug them directly on your local machine.
• Cross-device testing: Test your site’s responsive design and compatibility on various devices (phones, tablets) even if they’re not on the same LAN.
• Team collaboration: Make it easy for teammates to access and test each other's local ServBay-hosted services.

Troubleshooting

Issue	Solution
SSH connection times out or fails	Check your internet connection and verify you can reach a.pinggy.io. Make sure your firewall allows outbound connections on port 443. Also ensure your Pinggy username is correct.
Pinggy URL inaccessible or returns errors (e.g., 502 Bad Gateway)	Check that your local site/service in ServBay is running and listening on localhost:443 (or the port you used in -R). Ensure ServBay’s web server (Caddy/Nginx) is configured correctly.
Visiting Pinggy URL returns 404 or ServBay’s default page	If you have multiple sites (virtual hosts) in ServBay, make sure to set the x:localServerTls and u:host arguments in your SSH command to your intended local site domain (e.g., myproject.servbay.demo). This tells ServBay’s web server which host to respond to.
Intermittent disconnects	Likely due to network instability or SSH timeout. Try increasing the ServerAliveInterval, or use autossh for automatic reconnects (see “Advanced Tips”).
Certificate errors on HTTPS access	Pinggy issues public CA certificates for free users. If you're using a self-signed certificate locally, browsers may warn you. Pinggy’s public CA should resolve this for public access. If issues persist, confirm your ServBay service indeed uses HTTPS (listening on 443).

Solution Summary

With Pinggy, ServBay users can easily and securely open their local development websites and applications to the public internet. Key benefits:

• No client installation required: Streamlines setup and usage.
• One-click operation: Start a tunnel with a simple SSH command.
• Automatic HTTPS support: Pinggy supplies free public CA certificates, solving certificate issues for public access.
• Supports HTTP and TCP tunnels: Meets a wide range of exposure needs for different services.
• Highly compatible with ServBay: Easily expose specific ServBay-configured local sites by setting the correct Host header.
• Token-less command options: Increases security when sharing commands with others.

Compared to some NAT traversal tools that require complex installers or configuration files, Pinggy provides a much lighter and more convenient approach—especially suitable for ServBay developers conducting quick tests, demos, or temporarily sharing local services. For long-term reliability or professional use with custom domains, consider Pinggy’s paid plans. Combining ServBay’s robust local environment with Pinggy’s effortless public access will significantly enhance your development productivity and team collaboration.