A preview URL on every pull request is one of those features that quietly changes how a team ships. Reviewers stop cloning branches to see a change; they click a link in the PR and look at the real thing. Vercel and Netlify made it standard. Today it's a first-class part of Ngris too — with one difference that matters: your preview is served behind the same security edge as production.

The official ngris-edge/deploy-action builds your app, deploys the output as a preview, and comments the live URL back on the PR. Every push updates it.

Setup takes two minutes

Create an API key in the dashboard under Settings → API keys (it starts with ngk_), add it to your repository as a secret named NGRIS_API_KEY, and drop this workflow into your repo:

# .github/workflows/preview.yml
name: Preview
on: pull_request
permissions:
  contents: read
  pull-requests: write
jobs:
  preview:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20 }
      - uses: ngris-edge/deploy-action@v1
        with:
          api-key: ${{ secrets.NGRIS_API_KEY }}
          build-command: npm ci && npm run build
          dir: dist

That's the whole thing. Open a pull request and the action builds your app, deploys it, and leaves a comment with the preview link. The Ngris application is created automatically on the first run — there's nothing to set up in the dashboard first.

Your preview lives behind a real edge

Here's what a plain static host doesn't give you. On Ngris, a deployed app — preview or production — sits behind a per-endpoint policy edge. That means the same preview URL can carry a web application firewall, OAuth or basic-auth in front of it, IP allow/deny rules, JA3 bot rules, and rate limits — configured per endpoint, whenever you want them. Want previews visible only to your team? Put login in front of them. Worried a preview will get scraped or hammered? The rate limiter and WAF sit at the edge, not in your app.

It's also one platform. The same account that hosts your front-end builds and backends is the one that tunnels your local services and runs the Ngris MCP server — so you go from expose localhost to a production URL with a WAF and auth without stitching four vendors together.

Any framework that builds to a folder

The action deploys your build output, so it works with anything that produces static files. Set dir to your framework's output directory:

Vite / Astro            dir: dist
Create React App        dir: build
SvelteKit (static)      dir: build
Next.js (static export) dir: out
Nuxt (generate)         dir: .output/public
Hugo                    dir: public

The action exposes preview-url and deploy-uuid as outputs if you want to use them in later steps. For a managed backend (Go, Node, Python, or a Dockerfile), connect the repo in the dashboard and turn on branch auto-preview instead — the action is for static and framework builds.

Or just ask Iris

If you'd rather not read docs, ask the in-product assistant. Iris knows the setup — tell it “set up preview deploys on my pull requests” and it walks you through the API key, the repo secret, and the exact workflow file for your framework.

Try it

The action is open source at github.com/ngris-edge/deploy-action — the README has the full input reference and the per-framework table. It's new, so kick the tires on a throwaway repo and tell us what breaks. If you're coming from Vercel or Netlify and want previews that carry your security rules instead of just serving files, this is the shortest path there.