Build 1 publisher2 min readPublished September 20, 2026 at 4:43 AM PDT

Epure's self-hosted ingest accepts the official Sentry SDK after a one-line DSN change

A dev.to walkthrough runs error ingest on two containers, keeps @sentry/browser pinned at 7.120.0 and edits only the DSN. The 202 it expects means auth and schema were accepted, ahead of any write to Issues.

The Engineer · Build desk

Illustration accompanying Epure's self-hosted ingest accepts the official Sentry SDK after a one-line DSN change

What happened

A dev.to walkthrough says self-hosted Sentry-compatible ingest needs no forked client: keep @sentry/browser or @sentry/node, keep the same init options, and replace only the dsn value.
The host runs from docker compose up as two services, the app image and postgres:16-alpine, with no Redis and no separate worker fleet on the laptop path described.
The walkthrough pins the official SDK at 7.120.0 for both the browser and Node installs rather than tracking the latest release.
A successful POST from the SDK, or from the raw store and envelope curls, returns HTTP 202 with a JSON body containing an id.

Compiled by The EngineerSomething wrong?How this is made

Why it matters

decision Trying the self-hosted lane costs an edit to one init key and a compose up, so a team can test the keep-paying question without scheduling client work.
constraint Anyone depending on traces, replay, profiles or mobile keeps a second bill, because this host answers for exceptions and nothing else.
exposure A deploy check that treats the 202 as delivery confirmation will report success while the Issues table stays empty, because the accept is non-blocking.
capability The raw store curl gives operators a two-call test that pins a failure on client wiring or host ingest before anyone opens SDK source.

The DSN carries the routing and the credential. `http://{public_key}@localhost:8080/{project_id}` gives the client a scheme, a host, a port, a project id and a public key ^[5]. From there the SDK posts to `/api/{project_id}/envelope/`, or to `/api/{project_id}/store/` on the legacy JSON path, with an `X-Sentry-Auth` header holding `sentry_version=7` and the key ^[6].

A 202 answers two questions: did auth pass, and did the schema parse ^[8]. Its body is a JSON id ^[7]. The write into Issues happens behind that accept, so the first debugging step in the dev.to walkthrough is to wait and refresh, because the accept runs ahead of the worker ^[11]. The empty-feed copy is `0 UNRESOLVED EXCEPTIONS`, and the walkthrough says that seeing it is not by itself proof of failure ^[13].

The browser example sets seven keys: `dsn`, `environment`, `release`, and four sample rates at zero ^[9]. One of the seven is the migration ^[1]. The other four exist to stop the SDK shipping transactions, session replay and profile payloads that an exception-only host discards on arrival ^[10].

Two checklist items are about stale state. `EPURE_PORT` and `EPURE_PUBLIC_URL` have to be set together in `.env`, and the app container has to be recreated after the edit ^[4]^[11]. The other is a leftover `dsn` or a second `Sentry.init` later in boot, still pointed at SaaS ^[11]. A working host paired with a client that never left the hosted plan is the expensive outcome of this exercise.

The bisect is the part I would keep. If the raw `store` curl returns 202 and the SDK path does not, the fault is in the client; if neither gets a 202, the walkthrough sends you to `docker compose logs` on the app service, the health endpoint and the DSN key ^[12]. Two calls, and the failure is localised without reading SDK source.

None of this adds up to a migration plan. The seed script is marked local smoke only, never production ^[15], and the walkthrough does not include retention, throughput or storage figures. For the 202 to mean anything in your codebase, your client has to be a 7.x SDK posting exception envelopes at the same two routes ^[2]^[6]. Anything further up the product line stays where it is: the walkthrough is explicit that APM, session replay, profiling, the log product and mobile SDKs should not be expected to work merely because the DSN looks familiar ^[14].

What to watch

Whether the project publishes throughput, retention or storage figures for a non-laptop deployment with a worker tier.
Whether the two ingest routes accept envelopes from SDK majors past 7.120.0. That decides how long the pin holds.
Whether transaction, replay or profile envelope items move from discarded to stored. If they do, the sample-rate advice changes.

Claim ledger

Ranked by verification strength, evidence, and original report placement.

[1]
The dev.to walkthrough states that a forked Sentry SDK is not needed: keep @sentry/browser or @sentry/node, change only dsn, and when migrating from Sentry SaaS keep the same init options and replace only dsn.
ReportedSupportedSource: dev.to walkthroughView cited source
[2]
The walkthrough installs a pinned official SDK at 7.120.0: npm install @sentry/[email protected] for a browser SPA, or @sentry/[email protected] for a Node API or worker.
ReportedSupportedView cited source
[3]
docker compose up from the epure-sh/epure repo root starts two services, the app image and postgres:16-alpine, with no Redis and no separate worker fleet on this laptop path.
ReportedSupportedView cited source
[4]
GET http://localhost:8080/health returns the body {"status":"ok"}; if port 8080 is taken, set EPURE_PORT and EPURE_PUBLIC_URL together in .env and then recreate the app container.
ReportedSupportedView cited source
[5]
The DSN shape is http://{public_key}@localhost:8080/{project_id}, created from Settings, SDK connection in the dashboard.
ReportedSupportedView cited source
[6]
The ingest routes are /api/{project_id}/store/ for legacy store JSON and /api/{project_id}/envelope/ for the envelope path with Content-Type application/x-sentry-envelope, both authenticated by an X-Sentry-Auth header carrying sentry_version=7, sentry_key and sentry_secret.
ReportedSupportedView cited source
[7]
A successful SDK or store/envelope POST returns HTTP 202 with a body such as { "id": "660e8400-e29b-41d4-a716-446655440001" }.
ReportedSupportedView cited source
[8]
The walkthrough states that 202 means auth and schema were accepted, that it is non-blocking, and that it does not mean the row is visible in Issues yet; ingest accepts before the Issues row appears.
ReportedSupportedView cited source
[9]
The browser Sentry.init example sets dsn, environment, release, tracesSampleRate: 0, profilesSampleRate: 0, replaysSessionSampleRate: 0 and replaysOnErrorSampleRate: 0.
ReportedSupportedView cited source
[10]
Transactions, session replay and profiles are discarded on an exception-only host, and zeroing those sample rates stops the SDK from sending work that will never appear in Issues.
ReportedSupportedView cited source
[11]
When the feed stays empty after a 202 the checklist is: wait and refresh because accept is ahead of the worker; match the UI environment chip to environment in Sentry.init; check for a project/DSN mismatch; check EPURE_PUBLIC_URL or EPURE_PORT drift after a .env change without recreating the app container; and check for an SDK still talking to SaaS via a leftover dsn or a second Sentry.init later in boot.
ReportedSupportedView cited source
[12]
If the store curl returns 202 but the SDK path does not, the walkthrough says to debug the client; if both miss 202, debug the host using docker compose logs on the app service, health and the DSN key.
ReportedSupportedView cited source
[13]
The empty feed copy reads 0 UNRESOLVED EXCEPTIONS, and the walkthrough says that alone is not proof of failure.
ReportedSupportedView cited source
[14]
The walkthrough describes an exception-only lane and says not to expect APM, session replay, profiling, a log product or mobile SDKs to just work because the DSN looks like Sentry's.
ReportedSupportedView cited source
[15]
./scripts/seed-dev.sh is described as for local smoke only, never production.
ReportedSupportedView cited source
[16]
The verification sequence is: clone and docker compose up, confirm GET /health returns {"status":"ok"}, install the pinned official SDK, call Sentry.init with the new DSN and zeroed sample rates, then captureException and expect a 202 followed by an Issues row.
ReportedSupportedView cited source
[d1]
Of the seven keys in the browser Sentry.init example, one (dsn) is the value a SaaS migration changes and four are sample rates set to 0.
DerivedSupported1 source— sign in to open

Sources

Publishers with included, body-backed reporting in this cluster.

dev.to
1 article · September 20, 2026
Point the official Sentry SDK at self-hosted ingest (DSN only)

Ask Clarity

Have a question this piece left open? The answer comes from its reporting and claim ledger — nothing else.

Try

Clarity analysis

How the coverage leans and what the record actually supports. Read the methodology

Perspective Coverage

How much of the coverage speaks to builders, operators and investors. It measures emphasis, not whether the story is right.

The delta is one line: keep @sentry/browser, replace dsn, leave the rest of Sentry.init as it was. The pin matters because Epure's CI fixtures are 7.120.0; on Sentry JS 8.x the FAQ offers 'often yes' plus setting enableTracing: false where the option exists, and tells you to confirm with a real throw instead of a green install. The 202 matters because it is non-blocking and only confirms auth and schema, so an Issues feed that is still empty a second after a successful send is not a failure signal. When it is genuinely broken, the raw store curl is the bisect: a 202 from curl and nothing from the SDK puts the fault in your client.

Reality

Evidence, adoption, hype gap, incentives and confidence, each read independently from the current record on the scale shown beneath it. How these are measured.

Evidence45

0100

One reproducible post, no second run

Every fact here comes from a single hands-on post on dev.to by an author working on the project. What lifts it above a launch announcement is that almost all of it is falsifiable in ten minutes: the repo is public, and the health body, DSN shape, route paths, auth header and 202 either reproduce or they do not. Nobody in our coverage has run the commands, and Sentry has not commented on its SDKs pointed at a third-party endpoint.

AdoptionInsufficient

Quickstart shipped, adoption unverified

The post documents a compose path and fixtures pinned to 7.120.0. The only install described is the reader's own laptop, and it hands production off to an overlay it does not demonstrate. Without a single deployment, user or issue-tracker signal, there is nothing here to score.

Hype gap−10

Topics and entities

Follow any of these and your For You feed starts watching them — no settings page required.

Topics

Entities

build
Next.js standalone builds move the Sentry source-map upload onto your own build machine
1 publisher
build
Path normalization strands the local storage backend under a root-owned /app
1 publisher
build
Every declared Compose dependency on this eight-server fleet ends in :false
1 publisher
build
The five-minute grep: what `synchronize: true` tells a reviewer before your tests do
1 publisher

What happened

Why it matters

What to watch

Claim ledger

Sources

Let Clarity write the post for you.

Topics and entities

Topics

Entities

Related stories

Claim ledger

Let Clarity write the post for you.

Topics and entities

Topics

Entities

Perspective Coverage

Reality

Related stories

Sources