Where Hud runs

Hud runs inside your backend services, in whichever environments you choose, such as production, staging or local. Production is where it adds the most, because that's where your code meets real traffic. You add the SDK to each service, and Hud tracks everything from the service down to its individual functions.

What Hud covers

• Runtimes: Node.js 18, 20, 21, 22, 24 and 26, Python 3.8+ and Java 8, 11, 17, 21 and 25. Each language's Compatibility page lists the supported frameworks and versions.
• Entry points: HTTP APIs (REST and GraphQL), gRPC services (not yet in Java) and queue consumers, such as Kafka, RabbitMQ and Google Cloud Pub/Sub. For an entry point Hud doesn't detect on its own, you can mark the code as a flow.
• Hosting: containers and VMs on Kubernetes, AWS, GCP, Azure and DigitalOcean.

What Hud doesn't cover

• Frontend and browser code.
• Third-party code, such as node_modules and site-packages. Hud tracks only the functions in your own code.
• Most serverless platforms. AWS Lambda is in closed beta for Node.js, and Vercel and Netlify have partial Node.js support. Next.js is in a private beta.
• Windows hosts, Bun, and GraalVM native images for Java.

One SDK per service

Add the SDK to every service you want Hud to cover. Each service reports with:

• A service name, set when you start the SDK.
• An API key for its environment, from the API Keys page in Hud. Each environment has its own key.
• Optionally, a deployment ID for the code version, so you can tell one rollout from the next. The Java SDK doesn't take one yet.

Every instance that reports the same service name counts as one service, however many pods or replicas you run.

From service to function

Hud organizes what it sees in three levels.

Service Groups bundle services, for example by team, to filter what you see and route Slack alerts. They don't change how Hud collects data.