Railway preview environments per pull request, automated

Build me a code workflow that gives every pull request its own Railway preview environment and tears it down when the PR closes. The whole thing should be deterministic with no judgement steps.

Trigger: a GitHub webhook listening for pull_request events with actions opened, reopened, synchronize, and closed. The first thing the workflow does is check that the event's repository (owner and name) matches the configured target repo. If it doesn't match, exit immediately so unrelated webhooks never spin anything up.

Name preview environments deterministically as pr-<number> using the PR number from the webhook payload. This way the close handler can find the right environment by name without storing any state.

When the event action is opened or reopened:

1. Call Railway's Create Environment to make a new environment in the configured Railway project, cloning from the designated base environment so all variables and service config copy over. Name it pr-<number> and mark it ephemeral (Railway's isEphemeral flag) so Railway knows it's a preview.

2. For each cloned service in the new environment, call Update Service Instance Settings to point its source branch at the PR's head branch (from pull_request.head.ref).

3. For each cloned service, call Trigger Environment Deploy so the preview build kicks off against the PR branch.

4. For each service, call List Domains to fetch the Railway-provided URLs for the new environment.

5. Call GitHub's Create an Issue Comment on the pull request with a tidy markdown comment listing each service and its preview URL so the reviewer can click straight in.

When the event action is closed:

1. Call Railway's List Environments on the configured project and find the one named pr-<number> for this PR.

2. If it exists, call Delete Environment to clean it up. If it doesn't exist, skip and exit cleanly.

3. Call GitHub's Create an Issue Comment with a short confirmation that the preview was torn down.

For synchronize events (new commits pushed to an open PR), check if the pr-<number> environment already exists. If it does, do nothing in the workflow itself, Railway's normal auto-deploy from the branch will pick up the new commits. If it doesn't exist yet (rare race), run the same create flow as opened.

Inputs to expose at workflow setup: the target GitHub repository (owner and name), the Railway project ID, the Railway base environment ID to clone from, and the GitHub and Railway credentials.

Additional information

What does this prompt do?

Creates a new Railway preview environment every time someone opens or reopens a pull request, cloned from your chosen base so variables and services copy over.
Points each cloned service at the pull request's branch and kicks off a deploy so the preview reflects the proposed code.
Posts a tidy comment on the pull request listing each service and its live preview URL so reviewers can click straight in.
Deletes the preview environment automatically the moment the pull request is closed or merged, and leaves a short confirmation comment.

What do I need to use this?

A Railway account with a project and a base environment you want to clone from, such as your staging environment.
A GitHub repository you can configure webhooks on and where the workflow can post comments.
The name of the GitHub repository you want to target, so the workflow ignores unrelated pull request events.

How can I customize it?

Choose which GitHub repository the workflow listens to so unrelated activity is ignored.
Pick the Railway base environment to clone from, for example staging or a dedicated preview-base.
Adjust the comment format, for example to group URLs by service or include a Slack ping for the PR author.

Frequently asked questions

Will this work with private repositories?

Yes, as long as the GitHub connection has access to the repository you point the workflow at.

Does it spin up an environment for pull requests from forks?

Only for the repository you configure. Pull requests on other repositories are ignored, which is what you want to avoid unrelated webhooks creating environments.

What happens if a pull request is reopened later?

The workflow creates a fresh preview environment again and posts a new comment with the live URLs.

How does the cleanup find the right environment when a PR closes?

Each preview is named after the pull request number, like pr-123, so when the PR closes the workflow looks up that name and deletes it. There is no state to manage.

Will it carry over my environment variables and service settings?

Yes. The new preview is cloned from the base environment you choose, so variables, services, and their configuration copy across.