> ## Documentation Index > Fetch the complete documentation index at: https://docs.rigbox.dev/llms.txt > Use this file to discover all available pages before exploring further. # Expose Ports & Route Apps > Map ports from inside your workspace to public URLs on rigbox.dev. When a service runs inside your workspace, it's only accessible within the VM by default. To make it reachable from the internet, you create an **app** - a route that maps an internal port to a public URL at `{name}.rigbox.dev`. ## How Routing Works The flow from a running service to a public URL: ```mermaid theme={null} flowchart LR A[Your service\nport 8080 inside VM] --> B[App created\nname: your-app] B --> C[Reverse proxy\nconfigured] C --> D[your-app.rigbox.dev] ``` Each app gets a unique subdomain on `rigbox.dev` of the form `.rigbox.dev`, where `` is the name you choose when creating the app. HTTPS is handled automatically - your service only needs to listen on HTTP inside the VM. App subdomains are globally unique across all Rigbox users. If a name is taken, you'll need to choose a different one. ## Discover Listening Ports Before exposing a port, you can check which ports have active listeners inside the workspace. ```bash theme={null} rig workspace ports --workspace $WORKSPACE_NAME ``` This scans the workspace for active TCP listeners and returns the port number along with the process name when available. See [List Listening Ports](/api-reference/apps/listening-ports) for the full response schema. ## Create an App Manually If you know the port and want full control over the app name, create it directly. Replace `` with a name of your choice — it will become the public subdomain. ```bash theme={null} rig app new --name --port 8080 ``` From outside the workspace, add `--workspace ` to target a specific VM. Pass `--kind cli` for interactive tools you'll invoke over SSH rather than expose as a public service. See [Create App](/api-reference/apps/create) for the API form. ## Expose Port Shortcut `rig app expose-port` detects the process listening on the specified port and, with `--wrap`, creates an app route in one call. This is the easiest way to make a service public. Omit `--wrap` to only detect the process without creating the route. ```bash theme={null} rig app expose-port --workspace $WORKSPACE_NAME --port 3000 --wrap ``` The command automatically detects the process name and uses it to generate a sensible app name. See [Expose Port](/api-reference/apps/expose-port) for details. ## Reconcile Template Apps If your workspace was created from a template that defines default apps (like a web server or API), you can ensure those apps exist with a reconcile call. ```bash theme={null} rig workspace reconcile --workspace $WORKSPACE_NAME ``` This checks the template definition and creates any missing apps. It's idempotent - running it multiple times has no side effects. See [Reconcile Apps](/api-reference/apps/reconcile) for details. ## Check App Health Before sharing a URL, verify the app is reachable. ```bash theme={null} rig app health --app $APP_NAME ``` If health returns unhealthy, check that your service is actually listening on the correct port inside the VM. Use `rig workspace ports` to verify. See [App Health](/api-reference/apps/health-check) for the response schema. ## App Lifecycle: Start, Stop, Restart Control the routing for an app without affecting the underlying service: ```bash theme={null} rig app stop rig app start rig app restart ``` | Action | Effect | | --------- | --------------------------------------------------------------------- | | `stop` | Removes the public route. The service inside the VM keeps running. | | `start` | Re-enables the public route. | | `restart` | Removes and re-adds the route. Useful if the proxy is in a bad state. | See [Start App](/api-reference/apps/start), [Stop App](/api-reference/apps/stop), and [Restart App](/api-reference/apps/restart) for the API form. ## Update an App You can rename an app or change its port. Renaming an app changes its public subdomain URL. There is no dedicated CLI subcommand for this, so use `rig api` to send the raw request: ```bash theme={null} echo '{"name": "new-name"}' | rig api PATCH /v1/apps/$APP_ID --body - ``` Renaming an app changes its public URL. Any existing links to the old subdomain will stop working immediately. See [Update App](/api-reference/apps/update) for the full schema. ## Delete an App Deleting an app removes the public route. The service inside the VM is unaffected. ```bash theme={null} rig app rm ``` See [Delete App](/api-reference/apps/delete) for the API form. ## Complete Example: Deploy a Python Server This walkthrough starts a Python HTTP server inside a workspace and exposes it to the internet. ### Start a service inside the VM SSH into your workspace and start a simple Python server: ```bash theme={null} # Inside the VM python3 -m http.server 8080 & ``` ### Expose the port From inside the same workspace (or from your laptop with `--workspace `): ```bash theme={null} rig app new --name my-server --port 8080 ``` `rig app new` prints the resulting subdomain — `https://my-server.rigbox.dev`. If you'd rather have Rigbox detect the listening process and pick a name automatically, the [Expose Port](/api-reference/apps/expose-port) API endpoint does both in one shot. ### Verify health ```bash theme={null} curl -sf https://my-server.rigbox.dev/ -o /dev/null && echo "live" || echo "not ready yet" ``` For programmatic health checks via Rigbox's own probe, see [App Health](/api-reference/apps/health-check). ### Share the URL Once healthy, anyone with the URL can access your service (if visibility is set to public). See [App Visibility](/guides/visibility) to control access. ## Next Steps * [App Visibility](/guides/visibility) - control who can access your apps * [Catalog Apps](/guides/catalog) - install VS Code, Jupyter, and more (routing is handled automatically) * [Workspaces](/guides/workspaces) - workspace lifecycle management