Expose local Server-Sent Events over HTTPS

tunnel.to forwards a local Server-Sent Events endpoint through a public HTTPS URL while the long-lived HTTP response continues streaming.

No special SSE mode is required. Start anonymously, then test incremental delivery with a browser EventSource client or curl -N.

tunnelto 3000
Install the client Read the quick start
Public HTTPS
No inbound ports
No firewall rules
Anonymous tunnels

How to expose an SSE endpoint

  1. 1Run the SSE endpoint locally, such as http://localhost:3000/events.
  2. 2Start tunnelto for the local application port.
  3. 3Connect to the same path on the generated public HTTPS URL.
# local endpoint: http://localhost:3000/events
tunnelto 3000

# verify incremental delivery through the public tunnel
curl -N https://<generated-host>.tunnel.to/events

SSE works as normal streaming HTTP

Your application keeps ownership of the event stream. Return Content-Type: text/event-stream, separate messages with a blank line, and flush each event as it becomes available. tunnel.to carries the long-lived response through the public HTTPS endpoint without an SSE-specific mode.

Browser EventSource or HTTP client
https://<generated-host>.tunnel.to/events
tunnel.to streaming connection
http://localhost:3000/events
Your local SSE application
Content-Type: text/event-stream
Cache-Control: no-cache

event: update
data: {"status":"ready"}

When to use Server-Sent Events

  • AI token and response streaming
  • Build and deployment progress
  • Live dashboards and status updates
  • Notifications and activity feeds
  • Logs and observability output
  • MCP and agent streaming transports

SSE vs WebSockets

CapabilityServer-Sent EventsWebSockets
Data directionServer to clientBidirectional
ConnectionLong-lived HTTP responseWebSocket protocol
Browser APIEventSourceWebSocket
ReconnectionBuilt into EventSourceHandled by the application
Typical fitUpdates, progress, tokens, notificationsInteractive two-way messaging

Build a reliable public event stream

  • Flush events promptly instead of buffering them
  • Send comment heartbeats during quiet periods
  • Use event IDs when clients need resumable delivery
  • Handle disconnects and reconnects in the application
  • Apply authentication when the stream is not public
  • Use a stable hostname for long-lived integrations
Protect the public stream Use a custom domain

Start disposable. Make it permanent later.

Try it

localhost → anonymous public URL

Keep it

localhost → persistent tunnel.to hostname

Own it

localhost → custom domain + access controls

Related guides

Expose localhostExpose a local MCP serverProtect a tunnelReserve a persistent hostname

Frequently asked questions

Does tunnel.to support Server-Sent Events?

Yes. tunnel.to forwards SSE as streaming HTTP through anonymous, registered, and custom-domain tunnels.

Do I need to enable an SSE mode?

No. Point tunnelto at the local port serving the event stream; no SSE-specific tunnel setting is required.

Can I test an SSE endpoint without creating an account?

Yes. Start an anonymous tunnel and connect to the generated HTTPS URL with a browser EventSource client or curl -N.

How do I test that SSE events arrive incrementally?

Run curl with output buffering disabled: curl -N https://<generated-host>.tunnel.to/events.

What is the difference between SSE and WebSockets?

SSE is a one-way server-to-client stream over HTTP with browser reconnection support. WebSockets provide bidirectional messaging.

Can an SSE endpoint use a stable hostname or custom domain?

Yes. Reserve a tunnel name or attach a custom domain when clients need the endpoint URL to remain unchanged.

The shortest path from localhost to public HTTPS.

Start anonymously. Add a stable hostname or custom domain when you need one.

Install tunnelto