/portal-expose

name: portal-expose
description: Expose, preview, protect with x402 payments, or keep a local web app, static site, HTTP route set, or explicitly requested TCP/UDP service reachable through Portal, then verify the public endpoint and report its lifecycle. This is the app side of Portal, the same flow as the quick-start form on a relay website (install, run one portal expose command built from the app settings, open the public URL). Use when the user asks to deploy, publish, share, tunnel, expose, or connect a local app to Portal or to a specific relay, create a public preview, add a paid route, configure x402, needs an HTTPS URL on a phone or another device because a browser feature such as microphone, camera, geolocation, or PWA install refuses to work over a LAN http address, or wants a Go app to embed the Portal SDK. Do not use for deploying a Portal relay, generic cloud hosting, publishing this plugin, or reaching a service that someone else already published (portal-connect).
license: MIT

Expose an App with Portal

Portal publishes a service that is already running on the user's machine. It does not build the app or move it to a cloud host. Treat a successful tunnel as dependent on both the local app and the Portal process or agent remaining available. This is the app side of Portal: every relay website offers the same three steps (paste what to share, run one install-and-expose command built from the app settings, open the public URL), and this skill performs those steps for the app with verification around them. Any other program that reaches the published URL needs nothing from Portal.

Run the workflow in order. Open a reference only when that branch is taken: `references/x402.md` for a paid route, `references/safety-and-verification.md` for an authenticated, sensitive/high-risk, or non-HTTP service, `references/game-hosting.md` for a game server, `references/portal-cli.md` when choosing persistent-agent configuration or checking a flag, `references/sdk-embed.md` only for a Go app that should run the tunnel inside its own process. Use the installed `portal` CLI for flags.

Choose the Mode

Use the smallest mode that satisfies the request:

• Temporary web preview: `portal expose <target>`.
• Connect the app to a relay the user picked, as its website's quick start does: install Portal from the official GitHub installer if it is missing, then `portal expose <target> --name <name> --relays <relay-url>`, with `--discovery=false` when only that relay should carry the app.
• Trusted static directory or HTML entry: `portal expose --serve <path>`.
• Multiple local HTTP services under one URL: repeat `--http-route`.
• Paid HTTP path: routed HTTP with an explicit x402 payment contract; never enable payment implicitly.
• Durable tunnel that should survive terminal or login restarts: an explicit `portal agent` config and managed service.
• Session-owned durable tunnel without an OS service: `portal agent run --foreground`.
• Game server (Minecraft, Terraria, Palworld, or any dedicated game server): always start from `references/game-hosting.md` — raw TCP/UDP transport has different prerequisites and verification than HTTP.
• Go app that should carry the tunnel in-process instead of running the CLI next to it: `references/sdk-embed.md`. The CLI stays the default even for Go; embedding is for users who ask for it.

Default to a temporary preview when the user says only "share", "preview", or "deploy locally". Do not install an OS service unless the user asks for a persistent, managed, or restart-surviving tunnel and accepts that `portal agent run` without `--foreground` installs a per-user launchd or systemd unit.

Workflow

1. Inspect the Project

• Read the applicable repository instructions before running or changing anything.
• Determine the app directory, start command, expected protocol, loopback target, and a meaningful health path.
• Prefer declared scripts and documented ports over guessing from process lists.
• Do not expose a port merely because it is listening. Tie it to the requested app.
• If the project is already running, preserve its process. If it is not running and deployment was requested, start it with the project's normal command and retain the terminal/session handle.

Ask one concise question only when the target, desired lifetime, or transport cannot be discovered safely. An explicit request to deploy, publish, expose, tunnel, or share authorizes creating the public tunnel for the named app; it does not authorize exposing adjacent services.

For x402, do not guess the protected path, payment methods, amount, network, recipient, or network-specific asset. Collect any missing consequential value before building the command or config. Treat an omitted method list as charging every method on the route and confirm that scope when it was not explicit.

2. Verify the Local Service

• Wait for the app's real readiness signal, not only for the process to exist.
• Make a bounded local request to the selected target. For HTTP, record the URL and status. For TCP/UDP, use a protocol-appropriate check that does not mutate application data.
• Stop before opening a tunnel if the local health check fails.
• Warn and require explicit direction before exposing databases, container daemons, debug consoles, unauthenticated admin panels, or services containing sensitive data.
• Before opening the tunnel, say that the public hostname is enumerable through each participating relay's `GET /api/state` unless the user asked for `--hide`, and that relays which enable their directory page show it there too.

3. Check Portal

• Run `portal version` when `portal` is available.
• If Portal is missing, present the official GitHub installer and request approval before running it because installation writes outside the project. A relay also serves an installer at `<relay>/api/install.sh` (`install.ps1` on Windows), but the relay then supplies the script, the binary, and the