Share your localhost app with Zync Public URLs

Your app works at http://localhost:3000. You want a teammate to review it, check it on your phone, or receive a webhook from a service outside your network. Sending someone your localhost address will not help: their browser treats localhost as their own computer.

Zync Public URLs gives that local web service a public HTTPS link. Keep building on your computer and share the running app when you need an outside caller, without deploying a separate preview first.

Public URLs launched in beta with Zync v2.27.1 on August 29, 2026. Here is how to use it for a short preview or integration test.

Start with a working local app

Run your application as usual and open it in your browser. For this example, confirm that it responds at http://127.0.0.1:3000. If your development server uses another port, use that port instead.

You can keep the app bound to 127.0.0.1, this computer’s IPv4 loopback address. You do not need to make it listen on every network interface to share it through Zync.

With Zync v2.32.0, released September 20, Public URLs also reaches apps that listen only on IPv6 localhost (::1). This fixes the case where a local development server worked in your browser but the public link showed App unreachable. Update Zync if you encounter that behavior on an older release.

Check the page or API route locally before creating a share. An HTTPS link cannot make a stopped application respond.

Create your first Public URL

1. Open Public URLs in Zync.
2. Choose Continue with GitHub or Continue with Google, and complete the browser sign-in.
3. Select Share a port and enter 3000 in Local port.
4. Optionally add a name that helps you recognize the share, such as Checkout preview.
5. For a private preview, enable Require a password and choose a visitor password.
6. Select Share. Wait for the share to show Online, then use Copy to copy the generated HTTPS link.

The sign-in is for Public URLs. You can use Zync’s local terminal and SSH workspace without creating a sharing account.

Open the copied link yourself before sending it. Check the route you intend to share and, if you enabled a password, confirm that a fresh browser session asks for it.

The browser’s sign-in prompt asks for a username and password. Enter any nonempty username, such as guest, and the visitor password you chose for the share. Visitors do not need a Zync account.

Keep the local application and Zync’s sharing connection running while visitors need access. Your computer supplies the app; the link does not upload or host a permanent copy of it.

Use it for a live preview

Suppose you are adjusting a checkout page at /checkout. Copy the generated HTTPS link and append /checkout, then send that address to your reviewer. They can open the route while you continue working locally.

You can also open the link on your phone to check touch interactions and a real mobile browser. The phone needs internet access; it does not have to use your computer’s localhost address.

Public URLs carries HTTP and WebSocket traffic, so it can support apps with realtime features and development servers that use WebSockets. Test the actual interface you are sharing, including updates and navigation.

An app can still contain URLs that point to localhost. Those URLs will refer to the visitor’s computer. If the page loads but its API calls or assets fail, review the app’s public base URL and use relative routes where appropriate. Creating a share does not rewrite every URL inside your application.

Test an incoming webhook

A webhook provider needs a reachable address for your local handler. If your app handles test events at /webhooks/demo, append that path to the generated HTTPS link and configure it as the provider’s test destination.

Then trigger one test event and inspect the result in your own application logs. Confirm that the handler received the request and returned the response the provider expects.

Visitor passwords are useful for human previews, but an automated webhook sender must also support the share’s password authentication if you enable it. A sender that cannot authenticate will not reach the handler. Keep the webhook endpoint’s own signature verification and use the provider’s test mode or test data.

Stop the share after the test and remove the temporary callback from the provider’s configuration when it is no longer needed.

Choose what you expose

Anyone with an active, unprotected link can reach the shared service. HTTPS protects the connection, but it does not decide who may use your app.

Share a development service you intend others to access. Avoid exposing local administration tools or applications containing private data. Use the visitor password for a preview intended for specific people, and keep any authentication already built into the application.

The share targets a port, not a single page. Sending a link to /checkout does not restrict visitors to that route; other routes served on the same port may also be reachable. Check what the service exposes before sharing it.

For the full user guide, see Public URLs.

Stop sharing when you are finished

Use the controls on the share itself:

Action	What happens
Stop	Pauses the share while keeping its address reserved. You can use Start to resume it.
Start	Resumes a stopped share when this device can provide the service.
Delete	Removes the share and releases its reserved address. Do not rely on that old address remaining yours.

Closing the local app can leave the URL listed but returning connection errors. Use Stop or Delete when you want to end sharing explicitly. Signing out of Public URLs also ends sharing from this device.

During beta, the current limit is three owned Public URLs, including stopped ones. Stopping a share keeps its slot; delete an unused share when you need room for another. Check the quota shown in Zync before creating a new one.

When the link does not work

The share shows Offline

Check that Zync is running and your computer has internet access. Use Start for a stopped share, or Start sharing when the panel says this device is not sharing. If sign-in needs attention, complete it before retrying.

The browser says App unreachable

Open the service locally using the same port. Check whether it stopped, switched ports, or failed during startup. A share showing Online confirms the sharing connection; it does not guarantee the application behind it is healthy.

The page loads but realtime updates do not

Check your application’s WebSocket address and allowed-host or origin settings. Use the framework’s supported configuration for the intended public hostname rather than disabling those checks globally. Test again through the public link.

I cannot create another URL

Review the owned shares, including stopped ones. Delete one you no longer need to free a slot, then retry.

When to use SSH port forwarding instead

Public URLs fits a local web preview or an incoming HTTP callback. It works independently of an SSH session.

If you need to reach a database through an SSH server, forward a remote service to your computer, or use a SOCKS proxy, use SSH port forwarding. Public URLs provides HTTPS and WebSocket access to a local web service; it is not a general TCP or UDP sharing feature.

Start with one test app, open the public link yourself, and stop the share after the review. Download Zync or see Public URLs in action to try the workflow.