Skip to main content
The Preview page in the developer portal renders one contribution at a time against an in-memory bridge. Nothing is installed, no token is minted, and your server is not called — it is the shortest loop for looking at a component.
The second line it prints is the preview URL, with your local remote entry already in it. Open it and pick a contribution. Reload is for after you change the Remote entry field yourself.

​
What answers the bridge

The frame is sandboxed: it runs in an opaque origin with no access to the portal’s session, cookies or storage. tap is the same in-memory mock your own tests build, with every scope granted, tap.ui.size fixed at slot, and the sandbox fixtures behind tap.data — so a component that renders here renders the same way under renderWithTap. Navigation, toasts, confirmations and action runs are recorded and go nowhere; storage writes live in memory for as long as the frame does. A procedure is the one call with no answer here. The frame registers no server handler, so tap.server.<name> raises TAP_UNKNOWN_PROCEDURE and a widget that reads through useTapServer renders its error state. Procedures are answered by a live session started with --server <tunnel url>, and nowhere else while you are developing. What the preview does not do: mint an install token, read the owner’s data, write hosted storage, or reach your server. For those, use live preview.

​
Previewing a deployed build

Any https remote entry works — paste it into Remote entry, or point the CLI at it:
That covers branch previews. If your team deploys previews through Zephyr Cloud or a similar service, the preview URL for a branch is already an https remote entry, so it previews here with no configuration on either side and nothing in Tappify depends on how you built it. http is accepted only for localhost and 127.0.0.1. Anything else comes back as “That remote entry was refused. The preview loads https URLs, and http only from localhost.”