Ports and proxies
Your container gets no inbound network by default. To reach something listening inside it - Jupyter, a web UI, an API, SSH - you declare the port when you create the job and then open a proxy to it while it runs.
Opening one
Section titled “Opening one”- Declare the port in the Ports section when creating the job.
- Once it is running, open its detail panel and go to Proxy.
- Open the port as public or private.
- Use the address that appears in the table.
The port action menu is disabled unless the job is running.
Public or private
Section titled “Public or private”| Public | Private | |
|---|---|---|
| Reachable from | The internet | Inside the private network |
| Confirmation | Asked before opening | Opens directly |
| Requires | Public-port permission | Private-port permission |
Opening a public port always asks first, because it genuinely exposes the service. Declining leaves it closed.
Private ports are unavailable when the job’s relay runs without DNS - in that case no private option is offered at all, which is a property of the installation and not of your permissions.
If you have neither permission, the Ports field is disabled at creation time and nothing is submitted.
IP filters
Section titled “IP filters”A port can carry a filter listing the addresses allowed to reach it. Edit it from the port’s row; the allowed addresses are then shown in the table.
For anything on a public port that is not meant for the whole internet, this is the control to use.
Jupyter
Section titled “Jupyter”A running job that exposes the Jupyter port gets a Jupyter action that opens it in a new tab. Where the job does not expose it, the action is disabled.
The Quick Deploy templates that include Jupyter already declare the right port, which is the easiest way to get it.
Closing
Section titled “Closing”Close a port from the same menu; the proxy is removed. Ports close with the job anyway, but closing one you are finished with is good hygiene on a public address.