Web apps on runtime ports

Anything that listens on a TCP port inside your runtime (TensorBoard, a Gradio or Streamlit demo, a Jupyter you started yourself, python -m http.server) can be opened in a browser tab at

https://<port>-<runtime-id>.run.neuralstudio.co/

where <runtime-id> is the runtime's rt-… label, shown with every port under Connect → Web Ports. (This label is not the session id that ns ssh uses; see SSH into your runtime.) Every port of a runtime is its own subdomain, the app is served at the root of that host (no path prefix to configure), and WebSockets pass through, so live-reloading dev servers and streaming UIs work as they do locally.

The runtime still opens no inbound port. The browser talks to the platform's session gateway, which reaches the port through the same outbound tunnel the notebook uses (see Isolation and secrets).

Opening a port

  1. Start the server in a cell or the terminal. Bind it to 0.0.0.0 or 127.0.0.1; both are reachable. For example:

    !tensorboard --logdir runs --port 6006 --host 0.0.0.0 &
    
  2. Open Connect → Web Ports in the notebook's runtime bar. Ports the runtime is listening on are detected and listed within ten seconds; click one to open it in a new tab. You can also type a port number by hand.

  3. The tab lands on https://<port>-<runtime-id>.run.neuralstudio.co/. The first visit goes through a short redirect that signs you into that host; after that the address works directly, and you can share it with anyone in the workspace.

Who can open a port

Any member of the runtime's workspace, viewers included (unlike the kernel, the terminal and SSH, which need the editor role). The gateway checks your sign-in and your membership on every request, so a link pasted to someone outside the workspace stops at a sign-in page, and a member who is removed loses access at their next request.

The sign-in for a port host is separate from the app's own session: opening a port sets a cookie on that one host only, valid for eight hours. Your Neural Studio session is never sent to the app.

What the app sees

The app receives the request path, query, and your browser's headers, minus anything that would identify you to the platform: the Authorization header and the platform's own cookies are removed before the request is forwarded. Cookies the app sets for itself work normally.

Because the app is your code, the platform does not add security headers on its behalf beyond HTTPS enforcement. If your app needs a Content-Security- Policy or wants to refuse being framed, set those headers in the app.

Limits

  • Reserved ports. 22, 8081, 8888 and 8889 are the runtime's own SSH, kernel and terminal ports and are never proxied (the gateway answers 403).
  • Nothing listening. A port with no server behind it answers 502 with no server on port N rather than hanging.
  • Request size and time. A single request is buffered by the gateway and must complete within 30 seconds; long-running streams should use a WebSocket, which is proxied without buffering.
  • Stopped runtimes. A port address is bound to a running runtime. When the runtime stops, the address answers "not reachable"; a new runtime gets a new rt-… label.

Programmatic access

Scripts can call a port host directly with a Cognito access token:

curl -H "Authorization: Bearer <access token>" \
  https://8000-rt-<id>.run.neuralstudio.co/

API keys are not accepted on port hosts. For unattended access to a service in the runtime, prefer SSH with a local port forward:

ssh -L 6006:localhost:6006 ns-<runtime-id>