Installation
The SDK package is errorcore.
Install the package
npm install errorcore
pnpm add errorcore
yarn add errorcore
bun add errorcoreNode.js 20 or newer is recommended.
Install with a coding agent
One prompt covers this whole page and the setup that follows it: install, environment variables, initialization, a controlled test route, and verification. Paste it into a coding agent running in your backend repo and it completes the setup in a single pass.
Install and configure the errorcore SDK in this repository, end to end, in one pass.
Step 1. Inspect before editing.
Identify the package manager from the lockfile, the web framework, the server entrypoint, how environment variables are loaded, and any existing error middleware. If errorcore is already initialized somewhere, update that setup instead of duplicating it.
Step 2. Install the latest SDK.
Use the command that matches the lockfile:
npm install errorcore@latest
pnpm add errorcore@latest
yarn add errorcore@latest
bun add errorcore@latest
Step 3. Add server-side environment variables.
Write these into the server env file this repo already uses (.env or .env.local), and confirm that file is gitignored first. Keep the placeholders; never invent real values:
ERRORCORE_API_KEY="<ingestion API key from the errorcore console, starts with ec_live_>"
ERRORCORE_DEK="<64-hex payload encryption key from the errorcore console>"
ERRORCORE_ENVIRONMENT="production"
ERRORCORE_RELEASE="<full-git-commit-sha>"
ERRORCORE_INGEST_URL="https://api-production-7ecf.up.railway.app/v1/ingest"
Both keys are server-side only. Never expose them to browser code and never use a public env prefix such as NEXT_PUBLIC_ on any errorcore variable.
Set ERRORCORE_RELEASE from the deployment platform's full commit SHA. The SDK's .git/HEAD lookup is only a local convenience and is commonly unavailable in production containers.
Step 4. Initialize errorcore early.
In the server entrypoint, before database clients, HTTP clients, queues, or workers are created:
import { init } from "errorcore";
init({
service: "<short service name, for example core-api>",
deploymentEnv: process.env.ERRORCORE_ENVIRONMENT,
transport: {
type: "http",
url: process.env.ERRORCORE_INGEST_URL,
apiKey: process.env.ERRORCORE_API_KEY,
},
encryptionKey: process.env.ERRORCORE_DEK,
});
Framework notes: Express registers expressMiddleware() from "errorcore". Fastify registers fastifyPlugin from "errorcore". Hono registers honoMiddleware() from "errorcore/hono". Next.js initializes from instrumentation via "errorcore/nextjs" and wraps route handlers with withErrorcore(). NestJS has no dedicated adapter: initialize before the Nest app is created and, on the default Express platform, register expressMiddleware() through app.use(). Do not add SDK calls beyond the documented init(), captureError(), flush(), shutdown(), and getHealth() surface.
Step 5. Add one controlled test route.
Add a temporary GET /errorcore-test route that calls captureError(new Error("errorcore test error")), awaits flush(), and returns HTTP 202. Keep the route private when possible and remove it after the first event arrives. Do not make the errorcore console call this route.
Step 6. Verify.
Run the repo's typecheck and build scripts if they exist and fix anything your changes broke. Then start the app and call the route from a shell that can reach it. For a local app:
curl --request GET --url "http://localhost:3000/errorcore-test"
Adjust the port to this repo's dev server. For a deployed private app, run the same command inside its service network with the real internal origin. For a public app, use its real HTTPS origin.
Step 7. Report.
List every changed file, where initialization runs, which placeholders in the env file still need real values, and anything you could not verify. Finish by telling me to fill in the env values and watch the event arrive on the errorcore console Setup page.
Keep the diff minimal and do not commit secrets.The agent leaves placeholders for ERRORCORE_API_KEY and ERRORCORE_DEK; fill those in from the console Setup page when it finishes. The full walkthrough is in Setup with an AI agent.
For a production deployment, also set:
ERRORCORE_ENVIRONMENT=production
ERRORCORE_RELEASE=<full-git-commit-sha>Populate ERRORCORE_RELEASE from the CI or deployment platform's predefined commit SHA. The SDK's .git/HEAD lookup is a local convenience fallback and is commonly unavailable in production containers.
Initialize from a server entrypoint
import { init } from "errorcore";
init({
service: "core-api",
deploymentEnv: process.env.ERRORCORE_ENVIRONMENT,
transport: {
type: "http",
url: process.env.ERRORCORE_INGEST_URL ?? "https://api-production-7ecf.up.railway.app/v1/ingest",
apiKey: process.env.ERRORCORE_API_KEY,
},
encryptionKey: process.env.ERRORCORE_DEK,
});Initialization must happen in server code, before database clients, HTTP clients, queues, or workers are created. The SDK never runs in a browser bundle.
Attach request context
Initialization alone captures errors. To attach the request that triggered them, register the adapter for your framework:
| Framework | Export | Import from |
|---|---|---|
| Express | expressMiddleware() | errorcore |
| Fastify | fastifyPlugin | errorcore |
| Hono | honoMiddleware() | errorcore or errorcore/hono |
| Koa | koaMiddleware() | errorcore |
| Hapi | hapiPlugin | errorcore |
| Next.js | withErrorcore() | errorcore/nextjs |
Raw node:http | wrapHandler() | errorcore |
| AWS Lambda | wrapLambda() | errorcore |
NestJS has no dedicated adapter. On its default Express platform, use expressMiddleware(); see the NestJS guide.
Adapters attach request context. Express, Fastify, NestJS, and raw Node applications must also call captureError(error) from the error handler where handled failures terminate. Hono and withErrorcore() capture errors that escape their wrapped handlers.
Local development transports
For local work you do not need the hosted ingest endpoint. transport: { type: 'stdout' } prints packages, and transport: { type: 'file', path: '.errorcore/events.ndjson' } writes them to disk. See local development.