The New Relic npm package, published as newrelic, is the official Node.js APM agent maintained by New Relic, and it is safe to use as long as you handle its license key correctly and keep the agent current. It's a legitimate, actively maintained first-party package, not a community fork or a look-alike, and that distinction matters more than it sounds. The bigger security questions with the newrelic npm package aren't about the code being malicious; they're about credential handling, dependency footprint, and the fact that an APM agent instruments deep into your running application.
If you're evaluating whether to add newrelic to a Node.js service, here's what a security review actually looks at.
What the newrelic package is
The newrelic package is New Relic's application performance monitoring agent for Node.js. You install it, require it at the very top of your entry point, and it hooks into common frameworks and libraries to collect transaction traces, error rates, database timings, and custom metrics, then ships that telemetry to New Relic's platform. It's a mature package, published under the newrelic scope on the npm registry, with the major-version line in the 14.x range as of late 2025 and frequent releases. Roughly 900 other npm packages depend on it, which is a decent proxy for its legitimacy and maintenance.
Installation is the usual:
npm install newrelic
The first thing to confirm on any install is that you typed it right. newrelic is a prime typosquatting target precisely because it's popular and its name is easy to fumble. Verify the package name, the publisher, and the download count before adding it, and pin the version in your lockfile.
The license key is the real security surface
An APM agent authenticates to the vendor with a license key, and that key is a secret. The most common way teams get this wrong is committing the key into newrelic.js (the agent's config file) or into source control. Don't. Configure the agent through environment variables instead:
export NEW_RELIC_LICENSE_KEY="your-key-here"
export NEW_RELIC_APP_NAME="my-service"
The agent reads NEW_RELIC_LICENSE_KEY and NEW_RELIC_APP_NAME from the environment, which keeps the secret out of your repo and out of your image layers. If you do use newrelic.js, make sure it references process.env values rather than literals, and add it to a secret-scanning check in CI. A leaked New Relic license key lets an attacker send junk telemetry, inflate your bill, and in some configurations query account data.
Also think about what telemetry you're sending. APM agents can capture request parameters, SQL statements, and error payloads. Review the agent's attribute and high-security-mode settings so you're not shipping PII, tokens, or full SQL with literal values to a third party. New Relic offers a high-security mode and attribute exclusion rules for exactly this.
Install behavior and dependency footprint
A fair question for any npm dependency is whether it runs code at install time. The newrelic agent's risk here is low; it's the agent's runtime instrumentation, not an install script, that does the interesting work. Still, apply the same defaults you'd use for anything: run npm ci in CI for lockfile-exact installs, and consider --ignore-scripts with an allowlist across your whole install if your policy requires it.
The larger footprint concern is transitive. Like most substantial packages, newrelic pulls in a set of its own dependencies, and those are where an unpatched CVE would most likely surface, not in New Relic's own code. This is ordinary supply-chain hygiene: an SCA tool such as Safeguard can flag when something in the agent's transitive tree has a known vulnerability, so you can bump or override it. Keep the agent itself current too. Older agent major versions eventually drop support for older Node.js runtimes and stop receiving fixes, so track the release notes and upgrade on a schedule rather than pinning it and forgetting.
Because the agent instruments deeply, trust matters
APM agents monkey-patch core modules and popular libraries to capture timings. That deep integration is the point, but it also means the agent runs with your application's full privileges and sees a lot. This is an argument for sourcing it only from the official newrelic package, verifying it, and treating an agent upgrade with the same care as any other production change: read the changelog, test in staging, and watch error rates after deploy. A compromised or spoofed monitoring agent would be an ideal foothold, which is exactly why using the genuine, verified package is the whole security story here.
For the same reason, be deliberate about which environments run the agent. Many teams enable newrelic in production and disable it in local development via NEW_RELIC_ENABLED=false, which reduces both noise and the surface where a misconfiguration could leak local secrets to the telemetry pipeline.
Safe-usage checklist
Pulling it together, using the New Relic npm package safely comes down to a handful of habits. Verify you installed the genuine newrelic package, not a typosquat, and pin it in your lockfile. Supply the license key through environment variables, never in committed config or image layers. Review what attributes and SQL the agent captures so you don't ship PII to a third party. Keep the agent and its transitive dependencies patched and scanned. And treat agent upgrades as production changes with staging validation. Do those, and newrelic is a well-maintained, trustworthy dependency.
The general lesson applies beyond this one package: a first-party, actively maintained npm package from a known vendor is one of the lower-risk dependencies you can add, provided you handle its secrets and keep its tree current. The risk was never the New Relic code; it's the license key you might leak and the transitive CVE you might ignore.
FAQ
Is the newrelic npm package official and safe?
Yes. The newrelic package on npm is New Relic's official, actively maintained Node.js APM agent. It's safe to use provided you avoid typosquats, keep it updated, and handle the license key as a secret through environment variables.
How do I configure the New Relic npm package without exposing the license key?
Set NEW_RELIC_LICENSE_KEY and NEW_RELIC_APP_NAME as environment variables rather than hardcoding them in newrelic.js or committing them to source control. Add secret scanning to CI to catch accidental key commits.
Does the newrelic package send sensitive data to a third party?
It can, since APM agents capture request parameters, SQL, and error payloads. Review the agent's attribute settings and consider high-security mode to exclude PII, tokens, and literal SQL values before telemetry leaves your infrastructure.
Should I keep the New Relic Node.js agent updated?
Yes. Newer agent versions receive security fixes and drop support for end-of-life Node.js runtimes over time. Track the release notes, scan the agent's transitive dependencies, and upgrade on a schedule instead of pinning an old version indefinitely.