This page shows how one box can call a live TCP service running in another box inside the same org. Common cases are private APIs, helper daemons, and integration tests. This path is for box-to-box traffic inside the org, not for public ingress.
Start a private service
run9 box create api --image docker.io/library/ubuntu:24.04
run9 box exec api apt-get update
run9 box exec api -e DEBIAN_FRONTEND=noninteractive apt-get install -y python3
run9 box exec-bg api --service web:8080:30080 python3 -m http.server 8080box exec-bg prints an exec_id. Keep it, because you will use that id to stop the service later.
web:8080:30080 means:
- service name:
web - target port inside the box:
8080 - org-internal access port:
30080
Call it from another box
run9 box create client --image docker.io/library/alpine:3.20
run9 box exec client apk add --no-cache curl
run9 box exec client curl http://web.svc.run9.internal:30080/If curl returns the directory listing from python3 -m http.server, the private service path is working.
The endpoint is private to the org. It is not public ingress.
If the client cannot reach the service
Check the same background exec before you change the client:
run9 box exec-bg pull-output <exec-id> --from-start
run9 box execs inspect <exec-id>If output shows that python3 -m http.server exited, or execs inspect shows the exec is no longer running, the service is gone too because the endpoint only lives as long as that background exec.
If the exec is still running, re-check the exact service name and port you declared in --service web:8080:30080 and the client URL http://web.svc.run9.internal:30080/.
Understand the lifetime
The service exists only while the declaring exec exists. The box file system can outlive that exec, but the network endpoint does not.
That makes the lifetime easy to reason about: if the server exec exits, the service disappears too.
End the service
Replace exec-... with the exec_id printed by the box exec-bg command above.
run9 box exec-bg kill exec-...