Why We Built Ngris

Every developer who has worked on web applications has faced the same problem: you build something locally, it works perfectly, and then you need to share it with someone — a teammate, a client, a stakeholder — and suddenly you're wrestling with firewall rules, NAT traversal, dynamic IPs, and VPN configurations.

The Problem We Kept Hitting

Tunneling tools have existed for years, and they solve the basic connectivity problem well enough. But as we scaled our own infrastructure, we kept running into the same friction points:

• Security was always an afterthought — no WAF, no per-endpoint access control, no audit logging
• Traffic management was primitive — no load balancing, no caching, no traffic policies
• Billing was confusing — everything was an add-on, and the final price was always 3-5x the advertised rate
• Visibility was limited — you could see requests, but not analyze patterns or detect anomalies
• Multi-region deployments required separate accounts and manual DNS management

What We Wanted

We wanted a single command — ngris http 3000 — that would give us a production-grade edge gateway, not just a tunnel. That meant:

The Architecture

Ngris is built as a cloud-native platform with microservices at its core. The tunnel-server handles agent connections and data forwarding using HTTP/2 multiplexing. The API server provides the management plane. The control plane coordinates everything. And the agent — a lightweight binary you run locally — maintains persistent connections to the nearest edge region.

This isn't a weekend project stitched together with reverse proxies. It's a production system designed to handle millions of concurrent connections with proper observability, billing, and security from day one.

Deploy, not just tunnel

Ngris grew a second door since those early days. Alongside exposing a service you're already running, you can now deploy to the same edge: connect a repo and Ngris builds your front-end framework app (React, Vite, Vue, SvelteKit, Astro, Next.js static export, Nuxt, Hugo, and more), runs your backend (a Go/Node/Python service or any Dockerfile), or hosts a scale-to-zero serverless function — each one an endpoint behind the same WAF, auth, and traffic policies. Monorepo builds, per-environment env vars, preview URLs on every deploy, instant rollback, and — on paid plans — image optimization, privacy-friendly analytics, and Speed Insights round it out. Two doors, one policy edge.

What's Next

We're just getting started. On the roadmap: more edge regions, hardening HTTP/3 out of experimental, a native zero-config SSR runtime so a server-rendered app deploys with no Dockerfile, and a marketplace for community WAF rules. Ngris stays a hosted platform — you never operate the edge yourself.

If you've been frustrated by the gap between "it works on my machine" and "it's production-ready," give Ngris a try. It takes 30 seconds to get started:

That's it. Your local server is now behind a production edge gateway with WAF, auth, and traffic management. No configuration files, no YAML hell, no credit card required.