
You and Claude have built an app. It works on your machine. Now someone else needs to see it.
Screenshots and screen recordings only show what you chose to capture. A reviewer learns more by clicking through the running application themselves.
With noBGP, Claude can deploy the app to a machine, publish it at an HTTPS URL, and share it with the people who need to see it, all from the conversation where the code was written. This guide covers each step, from getting the app running to taking the demo down.
Before you start
Your assistant needs noBGP MCP connected. Set up noBGP with Claude if you have not already.
You also need a machine to run the demo. That can be:
- A machine you already have, with the noBGP agent installed. See the agent installation guide.
- A noBGP Compute machine, started from the conversation when you need somewhere to run it. Read about compute nodes.
Step 1: Deploy the app
Ask Claude to move the app onto the machine and start it:
Deploy this app to the demo machine. Copy the project, install its dependencies, and start it on port 8080 so it keeps running after this conversation.
Claude handles this with noBGP's file and command tools:
- Copy the files. The file tools write project files to the node, or copy them from one machine to another.
- Install dependencies. The
commandtool runs the project's install step, such asnpm installorpip install -r requirements.txt. - Start the app. Claude starts the application listening on a local port.
For a demo that must stay up, ask Claude to run the app as a service or under a process manager, so it survives a closed session or a restart.
Step 2: Check it locally
Before anything is published, confirm the app answers on the machine itself:
curl -I http://localhost:8080
A response from the app means it is ready to publish. An error at this stage is much easier to diagnose than a blank page at a public URL.
Step 3: Publish it at an HTTPS URL
Ask Claude to publish the service:
Publish port 8080 on the demo machine as an HTTPS service, with sign-in required.
The service_publish tool exposes the local port through noBGP. The service gets its own HTTPS URL, such as https://abc123.nobgp.com, with certificates managed automatically. There is no firewall rule, port forward, or DNS record to set up.
Step 4: Decide who can open it
Published services require sign-in by default. Only members of your noBGP organization can open the URL until you grant access to someone else.
To share the demo with reviewers outside your organization, add their email addresses with service_share. Wildcards are supported, so *@example.com grants access to everyone at that company's domain.
If someone without access opens the URL, they see an Access Required page. Opening that page sends you an access request by email, which you can approve or deny from the permissions page in the noBGP dashboard.
Making a service public removes sign-in entirely. It requires an Owner or Admin role, because it changes the auth_required setting to false. For an unreleased demo, sharing with specific people is usually the better choice.
Read the publishing services guide.
Step 5: Confirm the URL works
A successful publish records the route. It does not prove the app behind it is running. Ask Claude to check:
Check that the published demo actually responds.
The service_check tool probes the backend and reports whether it is reachable, with its status code, or unreachable, with error details. Run it again after any restart or redeploy.
Step 6: Update, pause, or take it down
Demos change as feedback arrives. Claude can redeploy new code to the same machine, and the URL stays the same.
When the review period ends, choose what to keep:
- Disable the service to make it inaccessible while keeping the URL and its configuration for later.
- Delete the service to remove the URL.
- Remove the machine if it was a Compute node created for the demo. Deleting a node removes its local data, so save anything worth keeping first.
Deciding on an end date before you share the link keeps short-lived demos from quietly becoming long-lived ones.
A demo brief you can reuse
Deploy this project to [machine], install dependencies, and run it on port [port] as a service. Confirm it responds locally, then publish it as an HTTPS service with sign-in required and share it with [email addresses]. Check the published URL responds and give me the link.
Frequently asked questions
Do reviewers need a noBGP account?
Reviewers need to sign in when a service requires authentication. You can grant access by email address or approve their access requests. A public service needs no sign-in, but should only be used when anyone with the link is allowed to see it.
Can I share a demo running on my own computer?
Yes, if the machine has the noBGP agent installed. Keep in mind the demo is only available while that machine is on and the app is running.
Is publishing a service the same as a browser terminal?
No. A proxy service routes web traffic to your application. noBGP terminal services are a separate feature that provide browser-based shell access to a node.
What happens to the URL if I redeploy?
The published service points at the port on the machine, so restarting or redeploying the app keeps the same URL. Run service_check afterwards to confirm it responds.
Show the real thing
Pick the next demo you would have sent as a screenshot, and ask Claude to deploy and share it instead.
Set up noBGP with Claude to get started, or learn how to run commands on your machines from Claude.