Node.js Installation
Integrate Hud Node.js SDK for enhanced observability in your application in a few simple steps
Prerequisites for Hud IntegrationBefore integrating Hud, please make sure your application meets the requirements.
1. Install SDK package
Run the installation command according to your package manager.
npm install hud-sdkyarn add hud-sdkpnpm add hud-sdk2. Create the Initialization File
Set up Hud by creating an initialization file. This file should register the SDK and initiate a session.
// hud-init.js
import * as hud from 'hud-sdk/setup';
// Add internal packages names from node_modules using glob patterns (e.g., '@your-org/*').
// Hud does not auto-instrument anything inside node_modules unless specified.
hud.register({
includeModules: [],
});
void hud.initSession(<hud_api_key>, <your_service_name>);
// hud-init.js
const hud = require('hud-sdk/setup');
// Add internal packages names from node_modules using glob patterns (e.g., '@your-org/*').
// Hud does not auto-instrument anything inside node_modules unless specified.
hud.register({
includeModules: [],
});
void hud.initSession(<hud_api_key>, <your_service_name>);
// hud-init.ts
import * as hud from 'hud-sdk/setup'
// Add internal packages from node_modules using glob patterns (e.g., '@your-org/*').
// Hud does not auto-instrument anything inside node_modules unless specified.
hud.register({
includeModules: [],
});
void hud.initSession(<hud_api_key>, <your_service_name>);
- Replace
<your_service_name>with your service's name. - Replace
<hud_api_key>with your Hud API key.
Tag your deployment (recommended)Pass a deployment ID so Hud attributes data to a specific code version. You can then filter every page in the web app (and MCP) by version using the Filters menu in the top-right corner.
Set it via the
deploymentIdinit option:void hud.initSession(<hud_api_key>, <your_service_name>, { deploymentId: 'v2.4.1' });Alternatively, you can set the
HUD_DEPLOYMENT_IDenvironment variable.Use a value that is unique per version but low cardinality — e.g. a semantic version (
v2.4.1), CI build number (build-1847), or git tag (release-2026-04-06). Avoid high-cardinality values such as a deployment timestamp.
register() and initSession() Configuration Options
register() Options
register(options) accepts a configuration object with the following keys:
includeModules-
Hud monitors all of your code by default, excluding external dependencies (node_modules). Use includeModules to specify internal modules names you want Hud to monitor. Accepts an array of glob patterns.
Example:['@org/*','internal-package'] excludeDirs-
Exclude specific directories or files from instrumentation. Accepts an array of strings that are matched as substrings against the deployed file path. Any file whose path contains a matching string won't be instrumented by Hud.
Example:['tests', 'seed.js'] verbose- Enables verbose logging for development and debugging purposes.
useAsyncEsmHooks-
Set to
truewhen your app loads as ESM and also runs OpenTelemetry, so Hud's loader can co-reside with OpenTelemetry's async loader. Not needed with dd-trace, which already matches Hud's loader. (Supersedes theHUD_USE_ASYNC_ESM_HOOKSenvironment variable.)
Type:boolean
Example:
hud.register({
includeModules: ['@org/*'],
excludeDirs: ['tests', 'seed.js'],
verbose: true,
useAsyncEsmHooks: true
});
initSession() Options
initSession(key, service, options?) takes the following parameters:
key- Your API token from Hud. Use the key for the correct environment to ensure metrics are tagged appropriately.
service- Unique name used to identify your service in Hud.
tags(optional)-
Key-value metadata attached to every metric sent from this session. Use tags to slice your data in the Hud web app and MCP tools (e.g., by region, environment, or job). Pass as a field on the 3rd argument:
{ tags: { region: 'us-east' } }. See Tagging and Filtering Your Data in Hud for details.
Type:Record<string, string> deploymentId(optional)-
Identifies the code version running in this session, so Hud data is attributed to a specific deployment. Pass it on the 3rd argument:
{ deploymentId: 'v2.4.1' }(alternatively, set theHUD_DEPLOYMENT_IDenvironment variable). Deployment IDs flow into your session tags, so every page in the Hud web app (and MCP) can be filtered by version. This lets you pinpoint which version caused a regression, compare performance across versions, and track canary deployments.
Use a value that is unique per version but low cardinality — e.g. a semantic version (v2.4.1), CI build number (build-1847), or git tag (release-2026-04-06). Avoid high-cardinality values such as a deployment timestamp.
Type:string
Example:
hud.initSession(
'local_f47da...3eb',
'main-service',
{
tags: {
region: 'us-east',
env: 'production',
},
deploymentId: 'v2.4.1',
}
);
Need to load secrets before initSession()?
hud.initSession() at that later stage or from a separate file.
3. Load the init file as early as possible
Load Hud Before Anything ElseHud's SDK needs to be imported as early as possible in your code to make sure it instruments any forthcoming modules' functions. Best practices on how to do it can be found here.
Option A - preferred: preload with --import
--import--import loads Hud before your application and instruments both ES Modules (ESM) and CommonJS (CJS) in the same process. Use it for every app.
node --import ./hud-init.js [YOUR_ENTRY_POINT].jsnpx ts-node --transpileOnly --import ./hud-init.ts [YOUR_ENTRY_POINT].tsnest start --exec "node --import ./hud-init.js"// NOTE: Next.js is not fully supported yet, endpoints data will not be collected
// Create a file called instrumentation.ts with the following code:
export async function register() {
await import('./hud-init.js');
}//project.json
"my-app": {
"targets": {
"serve": {
"executor": "@nx/js:node",
"options": {
"runtimeArgs": ["--import", "./hud-init.js"],
//...
},
},
}
}// If using `npm run`, check your package.json and modify the relevant script that runs your backend:
"scripts": {
"dev": "node --import ./hud-init.js index.js"
}If your app and all its dependencies are CommonJS-only, --require ./hud-init.js also works. Use --import if any of your code or dependencies load as ESM.
Using ESM together with OpenTelemetry?If your app loads ESM modules and you also run OpenTelemetry, pass
useAsyncEsmHooks: truetoregister():hud.register({ useAsyncEsmHooks: true });OpenTelemetry installs an async ESM loader, while Hud defaults to the sync loader on recent Node versions — mixing the two triggers a known import-in-the-middle issue where one tool's ESM instrumentation silently stops firing. The option switches Hud to the async loader so both match.
dd-trace uses the sync loader, same as Hud, so it works without this option — don't set it with dd-trace, as that would re-introduce the mismatch.
Option B - simple import
Add the import at the very top of your entrypoint:
require('./hud-init.js'); // must come before any other imports
// …rest of your appimport './hud-init.ts'; // must come before any other imports
// …rest of your appNote: Functions in the same file won't be instrumented, and this form does not install Hud's ESM loader. Use option A (
--import) for full coverage.If your app loads as ESM, use option A. Static
importstatements run before the rest of your entry file, so Hud would load after your frameworks and report only partial data.
4. Using a Bundler, Transpiler, or Minifier?
Hud uses source maps to reconstruct the original code in your production traces so you get clear, accurate visibility into what ran, where. Hud automatically picks up any source maps you deploy alongside your code.
Chat with our support team or email us at [email protected] and we’ll help you find the best fit.
What are source maps?Source maps connect your minified or transpiled JavaScript back to the original source code.
They're essential when using tools like Webpack, TSC, or Terser to ensure Hud can display the correct file and function names.
These files typically end with .map (e.g., bundle.js.map) and are stored alongside your built JavaScript.
5. Run your service and trigger it!
Start your service and trigger the functions you want to measure - metrics collection will begin automatically.
How to Know If Your Integration WorkedHud logs success or failure directly to stdout, look for the following logs on success:
Hud: Hud session startedHud: First code mapping sent successfullyHud: First invocation sent successfullyHud: Your service is sending data successfully
Then, head over to the web app to explore your data live, or install the IDE extension to view it directly alongside your code.
Self-hosted: send data to your own collector (OTLP)
With Hud self-hosted, the SDK sends its metrics and forensics over OTLP to your own OpenTelemetry collector, not to Hud. Install the SDK with steps 1 to 5 above, then turn on OTLP mode as shown here. It needs hud-sdk 1.12.0 or later, and only the Node.js SDK supports it.
The SDK still opens a session with Hud, so it needs your Hud API key, as in step 2. Your metrics and forensics don't go to Hud.
Turn on OTLP mode
Set the exporter to otlp and give the URL of your collector, with environment variables or in the init file:
HUD_EXPORTER=otlp
OTEL_EXPORTER_OTLP_ENDPOINT=<your-collector-url>hud.register({
exporter: 'otlp',
otlp: { endpoint: '<your-collector-url>' },
});Replace <your-collector-url> with the base URL of your collector's OTLP/HTTP endpoint, for example http://my-collector:4318. The SDK adds /v1/metrics and /v1/logs itself. With no URL set, it sends to http://localhost:4318.
The SDK exports delta metrics, which Prometheus doesn't accept, so your collector needs the deltatocumulative processor before its Prometheus exporter.
Settings
The SDK also reads the standard OTEL_EXPORTER_OTLP_* variables, so settings your app already has for OpenTelemetry apply to Hud too. To give Hud its own settings, use the same variables with the HUD_OTLP_ prefix instead, such as HUD_OTLP_PROTOCOL, or the otlp option. Both win over the standard variables.
| Setting | otlp option | Default |
|---|---|---|
| Collector URL | endpoint | http://localhost:4318 |
Protocol, http/protobuf or http/json | protocol | http/protobuf |
Compression, gzip or none | compression | gzip |
Headers, as key=value,key=value | headers | None |
| Timeout in milliseconds | timeoutMs | 10000 |
| Metrics export interval in milliseconds | exportIntervalMs | 60000 |
Resource attributes, as key=value,key=value | resourceAttributes | None |
Resource attributes tie your data to a release and a commit, so set them when you deploy. For example:
OTEL_RESOURCE_ATTRIBUTES="service.version=1.4.2,deployment.environment.name=production,vcs.repository.url.full=https://github.com/org/repo,vcs.ref.head.revision=$GIT_SHA,vcs.ref.head.name=main"Hud refuses these settings: gRPC, TLS certificates and client keys, any temporality other than delta, any histogram other than base2 exponential, an export timeout (OTEL_METRIC_EXPORT_TIMEOUT) and OpenTelemetry config files (set HUD_OTLP_IGNORE_CONFIG_FILE=true to ignore one). OTLP mode doesn't work with customForensicsStorage or in AWS Lambda.
If the SDK doesn't start
Hud prints an error code. For these errors, the SDK shuts itself down, and your app keeps running.
| Code | What it means | What to do |
|---|---|---|
| E1151 | The exporter value isn't hud or otlp. | Fix the value. |
| E1153 | OTLP mode doesn't run in AWS Lambda. | Use Hud managed on Lambda. |
| E1154 | A setting is invalid, for example a collector URL that isn't http or https, or that has a query string. | Fix the setting the message names. |
| E1156 | A setting the SDK read isn't supported yet. Often your app's own OTEL_EXPORTER_OTLP_PROTOCOL=grpc. | Unset it, or override it for Hud only, for example HUD_OTLP_PROTOCOL=http/protobuf. |
| E1158 | customForensicsStorage is set. | Remove it. |
| E1161 | Hud's own OTLP settings are set without exporter: the otlp option or a HUD_OTLP_* variable. OTEL_* variables alone leave Hud running. | Set exporter to otlp (for example HUD_EXPORTER=otlp) to send data to your collector, or to hud to send data to Hud. |
Warnings
Hud prints these and keeps running.
| Code | What it means | What to do |
|---|---|---|
| E1157 | Some settings were invalid and the SDK ignored them. | Fix the settings the message names. |
| E1162 | The otlp option or a HUD_OTLP_* variable is set while exporter is hud, so Hud ignores those settings. | Set exporter to otlp to send data to your collector. |
If an export fails
Hud prints each of these once per process, then keeps exporting. The data from failed exports is lost, and your app keeps running. The URL in the message leaves out user info and the query string.
| Code | What it means | What to do |
|---|---|---|
| E1159 | The collector rejected an export. This is an HTTP status under 500, other than 429. The message includes the status and, when the collector sent a JSON message, that reason. | Check the collector URL and headers. |
| E1160 | Hud couldn't reach the collector, or the collector was unavailable: a network error, HTTP 429, or a status of 500 or above. | Check that the collector is running at the URL in the message. |
Updated 3 days ago

