Get started with networking and public IPs
Every workspace has one private network of its own. Everything you create in the workspace joins it: managed services, virtual machines, game servers, web apps and the nodes of Kubernetes clusters reach each other there by private address, and nothing from another workspace can. On the public side, the workspace has one public IPv4 address, shared by its public instances, load balancers and clusters. Each public port on it answers for exactly one of them, and only the ports you open are reachable.
Your private network
The network is created the first time you launch something into the workspace, and it takes a moment on that first launch only. Open Networks to see it, its status and what is attached to it, each with its Private IP.
- Every instance's Network tab shows its Private address: its private IP and the port it listens on. Anything on the workspace network connects there directly.
- A web app can also reach an instance by its private name, such as
orders.acme.internalfor an instanceordersin the workspaceacme. - Private traffic never passes through the public address, so inbound rules do not apply to it.
Make an instance public or private
You choose when you create an instance, under Network access, and can change it later on its Network tab:
- Make public asks how the instance gets its public address. Choose Shared workspace IP and Apply.
- Make private, after you confirm, stops its public address answering within a few seconds.
The tab shows Changing access… until the change is done, and the instance keeps running. A public instance gets a hostname of its own, such as orders-c3d4.db.sahabti.app, and a port of its own from 40000–49999 on the shared IP. Always connect with the hostname: the shared IP can change. A Dedicated IP is shown, but not offered yet.
Open a port and choose who connects
On a public instance's Network tab, the Inbound rules table lists what its public address forwards. Anything not listed is closed.
- To reach another service inside the instance, such as a web server on a virtual machine, choose Forward a port, pick TCP or UDP and the Port inside the machine, and select Add rule. The rule gets its own public port, shown under Public endpoint.
- To limit who reaches a port, choose Edit allowed sources in the rule's menu and list up to 20 IPv4 addresses or CIDR ranges, one per line. An empty list means anyone.
Restrict the built-in rule whenever you can, above all a database's port and a machine's SSH port. See Instance network.
With PromptOps
In a workspace with PromptOps on, ask in the chat. It always asks before it changes inbound rules or access:
- "Which of my instances are public, and who can reach them?"
- "Make orders private."
- "Forward TCP port 8080 on build_box, open only to 203.0.113.0/24."
- "Let 198.51.100.7 reach orders on its database port."
With the API or MCP
Create an API token with the instance actions. GET /v1/networks?orgId=$WORKSPACE_ID lists the workspace's network. To forward a port, save the rule as rule.json:
{
"protocol": "tcp",
"guestPort": 8080,
"sources": ["203.0.113.0/24"]
}
curl -X POST "https://api.sahabti.com/v1/servers/$INSTANCE_ID/inbound-rules" \
-H "x-api-key: $SAHABTI_TOKEN" \
-H "Content-Type: application/json" \
-d @rule.json
POST /v1/servers/{id}/access makes an instance public or private. Over MCP, use list_networks, list_inbound_rules, add_inbound_rule, set_inbound_rule_sources and set_instance_access.
What it costs
The private network and the shared IP come with the workspace. Metered network lines, such as outbound data transfer, appear under Usage as they are used. See the pricing page.
First checks
- Networks shows the network as Ready, with your instances attached.
- From a machine or a pod in the workspace, the instance answers on its Private address.
- On every public instance, each rule's Allowed sources lists only who should connect.
- Outbound port 25 is blocked: send mail through your provider on port 587.
Next steps
- Instance network: public and private, the shared IP and inbound rules
- Get started with load balancers: one address in front of several targets
- Cluster access: who can reach a Kubernetes cluster's API
- Regions: where your workloads and data are