Announcing Netwarden Apps (alpha): error tracking that also tells you when next ships a CVE

Announcing Netwarden Apps (alpha): error tracking that also tells you when next ships a CVE

Today we're putting the alpha door open on Netwarden Apps — a second product surface inside the same Netwarden tenant you might already use for hosts. Apps is an error tracker with a small twist: it also reads the lockfile your SDK reports on init, cross-references every installed package against OSV.dev's advisory feed once a day, and pages you the moment a CVE patch ships for something you're shipping. It also does the basics — pageviews, unique visitors, custom events — for the half of the buyer profile that wants "did anyone use my app today" answered without reaching for PostHog.

This post is the launch announcement. Who it's for, what we built, what we explicitly didn't, why the pricing is fixed, and how to install it. I'll keep the marketing fluff to a minimum — there's a features page for that.

Who this is for

The buyer we built Apps around is a solo developer with one to three production apps. Stack is Next.js, Remix, SvelteKit, Hono, Express, FastAPI, or Bun. Hosts on Vercel, Railway, Fly.io, or Render. They might be a traditional engineer, but in 2026 a meaningful share of solo shippers are people whose primary tool is Cursor, v0, Lovable, Bolt, or Replit Agent. They're technical enough to ship; not interested enough to install OpenTelemetry and read flamegraphs.

They will not pay $89/mo for Sentry. They might pay $9 for a tool that catches their bugs and tells them when their next dependency is a known-CVE behind. That's the slot Apps fits into.

The secondary buyer is the small SaaS team that already pays Netwarden for host monitoring. For them, Apps is a tab inside an existing tenant — same dashboard, same invoice, same alert preferences. We're not selling them anything new; we're giving them more reasons to consolidate.

The third buyer is the agency running multiple client apps. For them the per-project model and the fixed price both matter — they need linear pricing they can mark up, and a per-app dashboard a non-technical PM can read.

If you're an enterprise SRE running Datadog and 50 microservices on k8s, this is not for you. We are not that product.

What's in the alpha

Three things, as of today.

Error tracking. Drop in @netwarden/apps (JavaScript / Node) or netwarden-apps (Python alpha). Errors are caught from window.onerror, unhandledrejection, process.on('uncaughtException'), and Next.js's instrumentation.ts hooks. They're grouped into Issues by stack-trace fingerprint, deduped, counted, and decorated with first-seen / last-seen / users-affected. Source maps uploaded on deploy symbolicate browser stacks back to your source code. Auto-reopen fires when a previously-resolved issue regresses. Five lines from npm install to your first issue.

Dependency-update alerts. This is the wedge. On SDK init, the package reads your resolved lockfile (package-lock.json, pnpm-lock.yaml, bun.lock, requirements.txt, poetry.lock, Gemfile.lock, go.sum) and reports the package + version pairs to the platform. A daily cron downloads OSV.dev's advisory feeds for npm, PyPI, RubyGems, and Go modules — about 400 MB compressed across the four — and matches every advisory's affected ranges against every project's installed packages. When a match lands, a module_vulnerable finding fires, severity-routed to email and push, with the fixed version printed as a copy-paste line.

Lite analytics. One track('event_name', { props }) call. Pageviews and unique visitors are cookieless — we hash IP plus User-Agent with a daily salt. Five-step funnel per project. That's it. No cohorts, no retention curves, no heatmaps. We're deliberately less than PostHog.

The SDKs are tiny by design. The browser bundle is 4.9 KB gzipped, the Node bundle is 4.5 KB, and the source-map upload CLI is 26 KB. Six total config knobs: dsn, environment, release, tracesEnabled, eventsEnabled, beforeSend. Sentry has dozens of options because Sentry has dozens of features. We have seven; the config surface matches.

Why we built it (and why now)

The honest answer: because it was 60% already built. The host-monitoring side of Netwarden has had a security findings pipeline for almost a year — the agent reports installed packages, the platform pulls Ubuntu USN, Debian DSA, and Red Hat OVAL feeds, the matcher joins those snapshots against advisories, and the notifier dispatches findings via email and push. That's the whole shape of "your openssl is one CVE behind, here's the fixed version" — and it's the same shape as "your next is one CVE behind, here's the fixed version."

The deltas between the host wedge and the Apps wedge turn out to be small. A new snapshot type for app dependencies. A new matcher reading OSV.dev instead of distro advisory feeds. A new finding type — module_vulnerable — that goes through the same evaluator, the same notifier, the same auto-resolve-on-fix logic, the same weekly digest email. Roughly 60% reuse, ~5,400 lines of net-new code, fourteen-to-seventeen engineer-weeks total. That's a different cost calculus than starting from a blank repo, and a meaningful part of why we can ship this at $9.

The error-tracking surface is the other half. Errors are a different shape from findings — high-volume, fingerprint-grouped, decorated with breadcrumbs and user context — but the dispatch layer is the same one we already shipped for security alerts. By the time we sat down to scope Apps, "build a Sentry" stopped being the right framing. The right framing was "extend the pipeline we already run, with two new ingestion paths and one new UI."

If we were starting from zero, this would be a year-long project. Because we built the pipeline once already, it's a quarter.

The wedge, by example

Here's the user story that built the case for shipping Apps in the first place.

A solo dev ships a Next.js app on Vercel. [email protected] is in their lockfile because that's what was current the day they ran create-next-app. Three weeks later, [email protected] ships with a patch for a server-side path-traversal in middleware. The advisory lands as GHSA-xxxx-xxxx-xxxx, gets a CVSS score of 9.1, and propagates to OSV.dev within a day.

The dev finds out about it six weeks later. Maybe from a Hacker News thread, maybe from a Bluesky post, maybe — worst case — from an unrelated bug report that turns out to be exploitation. They had no Dependabot, because their code isn't in a public GitHub repo. They had no Snyk, because they've never heard of Snyk. Sentry didn't tell them. PostHog didn't tell them. Their hosting provider didn't tell them, because hosting providers don't.

We tell them, on the day the advisory ships, in one email that reads:

[email protected] (your-vercel-app) — GHSA-xxxx-xxxx-xxxx, severity high. Patched in 16.0.5. Update available.

Patch instructions:

npm install [email protected]

That's the entire wedge. There's no SCA dashboard to set up. No SBOM ceremony. No license auditing. Just: "your next is critical-CVE'd, here's the version that fixes it, here's the command." Sentry doesn't do this. Highlight doesn't do this. PostHog doesn't do this. Bugsnag doesn't do this.

Dependabot does, but only for code in a GitHub repo where someone reads the PRs. Snyk does, but at enterprise volumes for enterprise prices. Apps does it free-with-the-product, scoped to what your SDK already reports, routed through the alert preferences you already configured for hosts.

If you have both products, the dependency findings from your apps appear in the same /security/findings list as the SSH-misconfiguration findings from your hosts. One inbox.

The SDKs

Two at alpha.

@netwarden/apps is the JavaScript / Node package. One npm install, dual-target browser and Node, zero peer dependencies, MIT-licensed. It hooks window.onerror and unhandledrejection in browsers, process.on('uncaughtException') in Node, and Next.js's instrumentation.ts and middleware hooks if it detects them — that last one is the difference between a Next.js app working in three lines and not working at all.

import { init } from "@netwarden/apps";

init({ dsn: process.env.NETWARDEN_DSN });

netwarden-apps is the Python alpha. Flask, FastAPI, and Django middlewares included; same dsn shape; same track() API.

from netwarden_apps import init

init(dsn=os.environ["NETWARDEN_DSN"])

Both SDKs report the project's resolved manifest on init — that's the dependency wedge's input. Both batch up to 100 events into a single POST. Both expose track(name, props) for custom events. Both are alpha quality on day one, which means: they work, they're tested, and they will get bugs filed against them. Please file bugs.

We are deliberately not shipping mobile SDKs. iOS and Android need dSYMs / ProGuard handling, OS-version treadmills, and offline buffering — different engineering disciplines from the web SDK and a different audience from our buyer. When we add a third SDK, it'll be React Native, because we already ship a React Native app and the symbolication overlap is real.

Self-hosted

Same Bun binary as the host monitor. The Apps surface — error ingestion, the OSV.dev matcher, the events pipeline, the dashboards — ships in the single netwarden Bun-compiled binary you can run yourself. Bring your own SQLite or Postgres, point your DSN at it, ship.

There is no feature gate. The "Apps Free" tier in our hosted product corresponds, in self-hosted, to "you ran the binary." Every advisory feed runs on your machine. Every event lands in your database. The CLI for source-map upload is the same binary in two-letter mode (netwarden upload-maps).

If you're already running Netwarden self-hosted today, the upgrade path to enable Apps is one binary version bump and one new APPS_DSN env var. The migration script that creates the events_ts, issues, project_manifests, and module_advisories tables runs once on first boot.

What we don't do

Section eight of the features page has the full list, but the short version: no session replay, ever. No feature flags. No distributed tracing in v1. No profiling, ever. No mobile SDKs in v1. No log aggregation, ever. No heatmaps, no surveys, no AI session summaries.

Each of those "no"s is deliberate. Replay is the most expensive feature in observability and at odds with our self-hosted brand — even cheap replay storage is more per-MAU than our entire intended Apps subscription. Feature flags are a different product (LaunchDarkly, Statsig, PostHog Flags). Distributed tracing is a six-month project on its own, and the buyer doesn't have a distributed system to trace. Profiling either doesn't work on serverless or isn't readable by the buyer who'd subscribe.

We pick the seven features our buyer actually uses, and ship those well. If you need replay, Highlight is the right answer. If you need flags, LaunchDarkly is the right answer. If you need cohort analysis with retention curves, PostHog is the right answer. We're not trying to be them.

Pricing — and the deliberate absence of per-event billing

The four tiers, fixed monthly:

• Apps Free — 1 project, 50,000 events / month, 7-day retention, dependency findings included, $0.
• Apps Solo — 3 projects, 250,000 events, 30-day retention, $9/mo.
• Apps Studio — 10 projects, 1,000,000 events, 60-day retention, $29/mo.
• Apps Agency — unlimited projects (fair-use 50), 5,000,000 events, 90-day retention, $79/mo.

The cap on every tier is soft. Exceeding it pauses ingestion for 24 hours and emails you. Nothing auto-charges. There is no "metered overage" line on any invoice. There never will be one.

This is a deliberate choice, not a hedge. Per-event pricing is the psychological reason vibe coders refuse to use Sentry — every shipped bug feels like it costs money. Our positioning is "you will never get a bill that surprises you," and that doesn't survive a metered overage clause. The first time someone proposes a per-event upgrade path internally, we point them at this paragraph.

If you're an existing Netwarden Pro tenant for hosts, Apps Solo is bundled into your subscription at no extra charge. Three projects, 250,000 events, 30-day retention, included. Upgrade to Studio or Agency as an add-on if you outgrow it. Same tenant, same dashboard, same invoice — the conversion path I want is "I have hosts on Netwarden" → "I have apps on Netwarden too" without a second checkout.

For the why I built Netwarden reasoning behind the bundling, that's its own post.

Where we are honest about being thin

This is alpha. Some of what Sentry has, we don't, and we'll look thin in side-by-side reviews for a while.

Sentry's JavaScript SDK has eight years of polish. Our v1 will be worse on day one. Cloudflare Workers edge cases, Next.js middleware quirks, framework version matrix coverage — Sentry has fixed every variant. We have not. Expect six months of "found a bug, switched to Sentry" churn while we close the gap. The mitigation is scope discipline: seven features instead of forty leaves engineering budget to make those seven actually work.

Source-map handling is hard. Build-tool integrations, runtime filename matching, chunked maps, maps the user forgot to upload. v1 ships Vercel deploy-hook auto-upload as the supported path; everything else is "run netwarden upload-maps after your build." Other platforms get hooks in subsequent phases.

The Python SDK is in earlier shape than the JS one. Flask and FastAPI work today; Django works for synchronous code paths and is iffier on async views. We'll close that gap during alpha.

The dependency wedge ships the four ecosystems on day one (npm, PyPI, RubyGems, Go). Maven, Cargo, NuGet, and Composer are explicitly v2 — the ranking was user-impact divided by engineering cost, and Java's range syntax alone is a quarter of the wedge.

If any of those gaps are blocking for you, please tell us — alpha is the right time to file requests. The roadmap is in the wedge design doc summary; the long-form planning lives in our internal docs and we're happy to share if you ask.

Closing — install, kick the tires, file issues

If you want to try Apps:

1. Sign up at app.netwarden.com. Free tier covers one project.
2. Read the getting-started guide for SDK install steps.
3. Drop the SDK into your app, set NETWARDEN_DSN, ship.
4. Wait for your first error or your first dependency finding. Whichever comes first.

If you want to read the technical companion:

• The Apps features page has the long-form capability tour.
• The security wedge post walks through the existing findings pipeline that Apps reuses.
• The why I built Netwarden post explains the broader product strategy this fits into.

If you find a bug — and you will, this is alpha — file it in the GitHub issue tracker linked from the dashboard. We read every one. The closer the SDK gets to the seven features actually working, the cleaner this gets to graduate from alpha.

Thanks for reading. Now go install it.

— Thiago