Deploying a front-end app is a solved problem — push a repo, a build runs, a URL comes back. What isn't solved on most static hosts is what sits in front of that URL. A web application firewall, login, and rate limits are usually a second product, a second bill, or a DIY project. On Ngris they're part of the same edge your app is served from, and you can put them on any deployed app at no extra vendor cost. This is the one-click deploy walkthrough, plus the part that makes it different.
Deploy in one click
There are two fast paths to a live app, and both auto-detect your framework.
From the template gallery. The Ngris starter templates page has one-click-deploy starters for React, Vue, Svelte, Solid, Astro, and plain static HTML. Pick one, click Deploy to ngris, and the create-from-git flow is pre-filled with the template repo — Ngris clones it, detects the framework, runs the build, and serves the output at an HTTPS URL. Nothing to configure first.
From your own repo. Connect a GitHub or GitLab repo in the dashboard, or drop a Deploy to ngris button in your README that deep-links straight into the create flow with the repo pre-filled:
# Markdown for your README — the button deep-links into the create flow
[](https://dashboard.ngris.com/deploy?repo=YOUR_REPO_URL)Rendered, that's the same badge you see across the template gallery:
Whichever path you take, the builder runs your npm, yarn, or pnpm install and build in a sandboxed job, then publishes the output to the edge. Every deploy also gets a preview URL and instant rollback (an atomic pointer flip back to the previous release).
The builder auto-detects your framework
You don't tell Ngris what you built — it works it out from your repo and picks the right output directory. Detection (and every value) is overridable, but the defaults cover the usual suspects:
React (Create React App) build
Vite (React/Vue/Svelte/Solid) dist
Vue dist
SvelteKit (static) build
Angular dist
Astro dist
Gatsby public
Next.js (static export) out
Nuxt (generate) .output/public
Hugo public
Plain / prebuilt static served as-isIf your build outputs somewhere unusual, set the install command, build command, and output directory yourself. Per-app environment variables and encrypted secrets are injected at build time, so framework-prefixed variables like VITE_* or NEXT_PUBLIC_* resolve during the build.
Every app can sit behind a real WAF
Here's the part a plain static host doesn't give you. A deployed app on Ngris is an endpoint — the same kind of endpoint a tunnel produces — so the whole per-endpoint policy engine is available to it. That includes a web application firewall you attach as a single traffic-policy rule.
The engine is Coraza, a Go, ModSecurity-compatible WAF that speaks SecLang. Turning it on is adding one waf rule to your app's endpoint, and it defaults to detect mode — it logs matches and lets requests through — so switching it on can't break your traffic on day one. When you're ready, flip it to block and a matched request gets a plain 403. The built-in core ruleset is a curated baseline compiled into the edge (SQL injection, XSS, path traversal, sensitive-file probes, command injection, Log4Shell/JNDI, template injection, known scanners) — and when you need the full OWASP Core Rule Set, you paste it into custom_rules and run core+custom. Read the deep dive in Ship a Web Application Firewall in One Rule.
The honest shape of it: the WAF isn't on until you attach the rule — it's presence-gated, so an app with no waf rule pays nothing for it — but it's available on every deployed app, and there is no separate WAF product to buy. Attach it in detect, watch what it catches, then enforce.
Login and rate limits, same edge
A WAF is the headline, but it's one rule type among many on the same endpoint. Because your deploy is a policy-enforcing endpoint, you can also:
- Put login in front of it. An OAuth/OIDC portal (sign in with Google, GitHub, or your IdP) or HTTP basic auth at the edge — handy for gating a staging deploy or an internal tool to your team, with nothing to build into the app.
- Rate-limit it. Cap requests per IP so a preview URL doesn't get scraped or hammered — enforced at the edge, before traffic reaches your app.
- Restrict by IP. Allow or deny CIDR ranges so a deploy is reachable only from your office or VPN.
Vercel, Netlify, and ngrok each do parts of this, but not this bundle in front of a build you just shipped: Vercel and Netlify are static/JAMstack hosts where a managed WAF and identity are enterprise add-ons or a third-party service you wire up; ngrok tunnels a service you're already running and doesn't build your app. Ngris builds the app and gives you the security edge in the same account, on the same URL.
Wire it into CI for preview deploys
Want a preview URL on every pull request? The official ngris-edge/deploy-action builds your app, deploys the output as a preview, and comments the live link back on the PR — and because a preview is an endpoint too, it carries the same WAF, auth, and rate limits as production. The setup is a short workflow file plus an NGRIS_API_KEY repo secret; see the CI/CD docs and the preview-deploys walkthrough.
What it costs
Ngris is a hosted SaaS with self-serve pricing. The Developer plan is $0 — no credit card — and includes one-click deploys and tunnels, so you can put an app live and share it for free. Attaching the policy engine (the WAF, edge auth, custom domains, rate limits) is on the Team plan at $10/mo; Enterprise is $25/mo for dedicated ports/IPs and SSO. Your deployed apps, tunnels, and the security layer share one account and one data-transfer allowance — there's no separate WAF vendor to add.
Frequently asked questions
Which frameworks can Ngris deploy in one click?
Anything that builds to a folder. Ngris auto-detects React (Create React App), Vite (React, Vue, Svelte, Solid), Vue, SvelteKit static, Angular, Astro, Gatsby, Next.js static export, Nuxt generate, and Hugo, plus prebuilt/plain static served as-is. It runs your npm, yarn, or pnpm install and build in a sandboxed job and serves the output — and you can override the install command, build command, and output directory for anything it doesn't guess.
Do I really get a WAF on the free plan?
The one-click deploy and a live HTTPS URL are free on the Developer plan. The web application firewall is part of the per-endpoint policy engine, which is on the paid Team plan ($10/mo). It's still bundled — a Coraza-based WAF you attach as one rule, with no separate WAF vendor or per-request WAF metering — rather than a third-party add-on you assemble yourself.
Is the WAF a real firewall or just a checkbox?
It's a real Coraza (ModSecurity-compatible) engine that inspects the URI, headers, and optionally the request body against SecLang rules. The built-in core ruleset is a curated baseline for high-signal attack classes, and you can supply your own SecLang — including the full OWASP Core Rule Set — via custom_rules. It runs per endpoint, defaults to detect mode so it can't break traffic on day one, and blocks with a 403 once you enforce.
How is this different from deploying on Vercel or Netlify?
The deploy loop is similar — git push, framework detection, build logs, preview URLs, env vars, rollback. The difference is what's in front of the URL. On Ngris every deploy is a policy-enforcing endpoint, so a WAF, OAuth/basic-auth login, IP allowlists, and rate limits attach to it directly, from one account. On Vercel or Netlify a managed WAF and identity-aware access are enterprise add-ons or a separate service you integrate. Ngris also tunnels local services and runs backends on the same edge.
Can I password-protect a preview or staging deploy?
Yes. Attach an edge auth rule to the app's endpoint — either an OAuth/OIDC portal (sign in with Google, GitHub, or your identity provider) or HTTP basic auth — and the deploy is only reachable after login. Nothing needs to be built into the app itself, and you can restrict by IP range too.
Deploy an app, then put a WAF in front of it
One click to a live URL — free — with a Coraza WAF, edge login, and rate limits one rule away.
Browse the deploy templates →