# Self serve preview environments for every pull request

> A board where product, design and QA bring up a clickable running version of any open pull request themselves, without asking an engineer to spin one up.

- Workflow type: app
- Services: Daytona, GitHub
- Categories: Engineering, Operations
- Published: 2026-08-17

## What it does

- Lists every open pull request across the repositories you choose, showing the title, who wrote it, the branch, how many files changed, and where it stands in review
- Puts a Launch button on every row that brings up a running copy of that change and hands back a link you can open in your browser a moment later
- Keeps a live section showing which pull requests currently have an environment up, who launched it, and how long it has been running, with a Tear Down button beside each one
- Optionally drops the preview link onto the pull request itself as a comment, so reviewers find it in context instead of asking where to look

## What you'll need

- A GitHub account with access to the repositories you want to preview
- A Daytona account, which is where the preview environments actually run
- The install command, the start command, and the port the app runs on for each repository. Someone technical enters these once during setup and nobody has to type a command again
- Nothing else. There is no schedule to configure, because the board only does something when a person presses a button

## Prompt

I want a preview environment desk that the non engineers on my team open whenever they need to click through a change before it ships, so product managers, designers and QA stop asking an engineer to spin one up for them. Build it as an app backed by GitHub for the pull requests and Daytona for the environments. There is no trigger anywhere in this app and nothing runs on a schedule: a person opens the board, browses open pull requests, and chooses which one to bring up so they can look at it in a browser. Keep it that way.

Start with a settings view where someone technical registers the repositories the desk covers. Each row holds the GitHub owner and repository name, the install command for that repository, the start command that runs its dev server, and the port that server listens on. Persist these for the whole app so everybody opens the same board and so the person launching never types a shell command. The board only ever shows pull requests from registered repositories, and the launch handler only ever runs commands read from this configuration, never free text entered at launch time.

The main surface is a board of open pull requests across every registered repository. For each repository call List Pull Requests with state open, then call Get a Pull Request per result for the head branch, the changed file count and the additions and deletions, and List Pull Request Reviews to work out where it stands: approved, changes requested, or still waiting on a reviewer. Each row shows the repository, the pull request number and title, the author, the branch, the number of changed files, the review state as a colored label, how long ago it was updated, a link out to the pull request on GitHub, and a Launch button. Give the board a manual refresh control and let people filter by repository and by review state.

Launch runs a server side handler. Before creating anything, call List Sandboxes filtered by the pull request label and enforce one environment per pull request: if an environment already exists for that pull request, do not create a second one, just take the person to the link that already exists and say who launched it. Otherwise call Create Sandbox with public set to true, which is required for the preview URL to be reachable without a Daytona login, and attach labels recording the repository, the pull request number, the name of the person who launched it and the launch timestamp. Sandbox creation is asynchronous and comes back in a creating state, so poll Get Sandbox until the state is started before making any call that runs inside it.

Once the sandbox reports started, call Set Auto-Stop / Auto-Archive / Auto-Delete Intervals straight away with a short window so a forgotten environment shuts itself down without anyone remembering to, for example stop after thirty minutes of inactivity, archive soon after, and delete within a day. Then call Git Clone Repository to pull in the pull request head branch, Create Session for a persistent shell, and Execute Command in Session to run the stored install command and wait for it to finish. Run the stored start command through Execute Command in Session as well, using the async option, so the long running dev server keeps running after the call returns rather than being killed when a synchronous command completes. Finally call Get Sandbox Preview URL for the configured port and show a clickable link the moment it is ready.

Show real progress while a launch is in flight, stepping through creating the environment, pulling the branch, installing, starting and waiting for the port, because this takes long enough that silence reads as failure. If the install or start command exits non zero, show the actual command output in the app rather than a generic error message, and offer a Tear Down button right there so a broken attempt does not sit around consuming quota. If Daytona returns a quota error because too many environments are already running, say so plainly and point at the live section.

Above the pull request list, keep a live section showing which pull requests currently have an environment up. Rebuild this section from List Sandboxes filtered by the label rather than from anything held in app state, so it survives a page refresh and correctly shows environments other people launched. Each live row shows the repository and pull request title, who launched it, how long it has been running, the preview link, and a Tear Down button wired to Delete Sandbox with a confirmation step. If a sandbox exists whose labels point at a pull request that has since been merged or closed, flag it in the live section as safe to tear down.

Give each live environment a Post link to the pull request action that uses Create an Issue Comment to drop the preview link onto the pull request itself, so reviewers find it in context. Make it a deliberate button someone presses rather than something that fires on every launch, and have the comment name the person who launched the environment and mention that the link stops working once the environment shuts down.

## How to customize

- Choose which repositories appear on the board, and give each one its own install command, start command and port
- Change how long an idle environment is allowed to sit before it shuts itself down and cleans itself up
- Decide whether launching also posts a comment on the pull request, and reword what that comment says
- Filter the board down to the pull requests that matter, for example only those already approved or only those touching a particular branch

## FAQ

### Do I need to know any commands to use this?

No. The install and start commands for each repository are saved in the app once during setup. Everyone else picks a pull request from the list and presses Launch.

### What stops us leaving environments running and wasting money?

Every environment is created with a short idle window, so anything nobody is using stops and cleans itself up on its own. You can also tear one down by hand from the board at any time.

### Can two people accidentally launch the same pull request twice?

No. The board allows one environment per pull request. If a teammate already brought it up, you are taken straight to the link they created instead of starting a second one.

### Will the live list still be right after I refresh the page?

Yes. The live section is rebuilt from the environments that actually exist, so it always reflects what is running right now, including environments other people started.

### Does anything run on a schedule or fire automatically?

No. Nothing happens until someone opens the board and presses Launch. This is a place your team goes when they need to look at a change, not an automation running in the background.

### Can people outside the engineering team use the link?

Yes. Each environment is published at a link that opens in an ordinary browser, so a designer or a client reviewer can click through the change without any developer tooling installed.

Use this prompt in General Input: https://www.generalinput.com/prompts/self-serve-preview-environments-for-every-pull-request