Self-Host Nango Only When the Connection Meter Bites

The verdict. If you are the technical founder of a micro-SaaS selling three to five integrations, start with hosted Nango or do nothing while you validate the workflow; do not adopt a home-lab obligation just because three containers look cute. Self-host Nango when your measured connection count multiplied by the vendor’s actual per-connection price exceeds your recorded operating cost and you have kept the stack unattended for 30 days; compare Merge only after verifying its current commercial shape and connector fit.

Integration plumbing is not one decision. It is a bundle: provider coverage, customer OAuth completion, credential custody, token refreshes, support tickets, and a service that shares a host with everything else you thought was more important. The useful question is not “can I run Nango?” We did. The question is whether owning that bundle costs less than being someone else’s customer.

This is a receipts-first operator report from a live Nango deployment checked on 21 August 2026. It does not claim a price, SLA, throughput, or universal connector catalog that the receipts do not support. For the same discipline on infrastructure that looks cheap until it gets hot, read our local LLM field guide.

1. The operator and the leak: paying twice for integration work

Picture Priya: a technical founder with a small B2B product and an integration shortlist, not a “connect everything” fantasy. Her first customers ask for GitHub, an everyday SaaS tool, and one niche system. Each new connection can mean OAuth application setup, a callback, encrypted credentials, token refresh behavior, API-version drift, and a support thread when a customer cannot finish consent.

The leak is not the OAuth redirect by itself. It is the recurring choice between three kinds of cost:

• a hosted connector vendor’s recurring billing meter;
• engineering time spent recreating provider plumbing; and
• the operating work of running connector infrastructure yourself.

Our deployment demonstrates the third option at its smallest credible shape: Nango server, PostgreSQL, and Redis on an existing AI workstation. It does not establish that self-hosting is cheap for Priya. The host already serves LLM, GBrain, and other workloads; its ports are a shared resource, not an empty playground. Existing services own ports including 5432, 3000, 8000, and 3131 according to the Nango operating runbook; that is exactly why an additional stack has to earn its place.

2. How self-host Nango actually works: one stack, three auth boundaries

The live compose receipt is deliberately boring. On 21 August, docker ps --filter name=nango reported nango-server using nangohq/nango-server:hosted, nango-db using postgres:16.0-alpine, and nango-redis using redis:7.2.4. The server was up for about 15 hours; Redis for about 30 hours; the server was bound to the workstation LAN address on ports 3003 and 3009. That proves the deployment was running at the time of inspection, not its reliability over a month.

The actual compose file at /home/kit/projects/nango/docker-compose.yaml names those same three services. PostgreSQL and Redis have persistent local bind mounts; the server depends on both; all three use a dedicated Docker network. The server’s source image is named hosted, not a version pin. The compose comment says to pin a released tag before public exposure. Treat that as a change-control item, not harmless decoration.

The important mechanism is the auth seam. The active remote compose sets FLAG_AUTH_ENABLED: "false", so this single-user deployment uses HTTP Basic auth for the dashboard and private management API rather than email login. A private environment-scoped call also needs ?env=dev; omit it and the runbook records an invalid_env response. Public /integrations, /connections, and proxy calls take a different credential: a Bearer Environment API key.

That is not ceremony. It is the boundary between someone administering the Nango environment and an agent or application performing an integration call. The local mirror at /Users/kit/projects/infra-setup/nango/docker-compose.yaml still shows FLAG_AUTH_ENABLED: "true"; it is therefore a useful warning, not evidence of the active auth mode. The live remote compose is the receipt for this article’s Basic-auth statement.

The supplied helper closes the loop without exposing a key. /home/kit/projects/nango/bootstrap-nango.sh creates a dedicated hermes-agent environment key with environment:* scope through the private, Basic-auth, ?env=dev route. It writes the resulting key to ~/.nango/apikey.hermes with mode 0600, then makes a Bearer GET /integrations verification. /home/kit/projects/nango/nango_api.py reads that local file and wraps public integration, connection, credential, and proxy calls. No secret value belongs in a decision article; the flow is the evidence.

One trap matters when you test endpoints: the runbook records that an unknown API path can return dashboard HTML with HTTP 200. A 200 is not success until the response is authenticated and JSON-shaped as expected. That is the kind of small operational fact hosted service customers get to ignore and self-hosters do not.

3. Choose the approach before you choose the logo

The comparison is about who carries the work, not which homepage feels better. “Do nothing first” is a real row because a customer request that has not repeated is not integration strategy.

Approach	Good for	Cost shape	Catch
Hosted Nango	Early connector validation	Monthly bill; verify current pricing	Vendor controls the ops layer
Self-hosted Nango (our run)	Proven repeat demand	Host resources plus operator time	You own auth, upgrades, and ports
Merge (vendor)	Catalog fit needs verification	To be verified from merge.dev/pricing, fetched 2026-08-21	Do not assume coverage or price
Keep writing raw OAuth	One narrow, stable provider	Engineering and maintenance time	You recreate credential lifecycle work
Do nothing first	Unproven customer demand	$0 until evidence arrives	A real buyer may still need a manual path

Hosted Nango is the default when Priya has only a few integrations and no measured monthly crossover. The decision is not “hosted is better forever.” It is “do not turn an unproven integration request into a stack you must patch at night.” Nango’s current commercial price is not quoted here because no live vendor-pricing receipt was captured for this article.

Self-hosted Nango becomes attractive when integration connections are a repeatable part of the product and Priya can name the bill she is avoiding. Our running stack gives the operational baseline, not a financial conclusion: a 21 August docker stats --no-stream receipt showed the server at 364.5 MiB, PostgreSQL at 32.99 MiB, and Redis at 3.609 MiB on a host reporting a 60.76 GiB memory limit. That is a point-in-time footprint. It does not include host acquisition, backups, alerts, upgrade time, outage handling, or the cost of capacity contention with the rest of the workstation.

Merge belongs in the comparison as a vendor option, not as a made-up price comparison. Its exact pricing is to be verified from merge.dev/pricing, fetched 2026-08-21. Until that receipt exists, reason about its billing shape only as vendor pricing that may grow with connected customers; do not put invented dollars into a spreadsheet and call it a decision.

Raw OAuth looks free because the first redirect is easy. Then you own app registrations, client-secret rotation, callback correctness, authorization-state handling, refresh-token failures, provider-specific API quirks, and an audit trail. It can be right for one stable provider that is core to the product. It is a poor default for a widening integration catalog.

Do nothing first means collect evidence before any integration architecture: count customer requests, name the provider, record the business action it enables, and see whether a manual export, CSV, or one-time assisted setup solves the immediate need. “Integration” requests are often workflow requests wearing a technical hat. Our Workflow Decision Lab primer is useful when the tool request needs separating from the actual operational leak.

The catalog is big; your gap still wins

The GBrain research record sessions/digest/2026-08-20 says the self-hosted catalog exposed 973 providers on 20 August 2026. It verified common communication and analytics SaaS integrations and GitHub PAT; its setup notes also say several requested crypto and broker-specific connector categories were absent. That is enough evidence to reject the phrase “every SaaS connects.”

The correct buying sequence is therefore backwards from most vendor demos: list the providers you must ship, test those providers and auth modes, then decide whether the catalog is a fit. GitHub PAT is a useful zero-registration smoke path in the runbook because it uses API-key credentials rather than an OAuth app. It is not proof that the customer’s hard provider will work.

4. Price the operator cost, not the container screenshot

A screenshot of three healthy containers does not produce a self-hosting price. It produces a ledger entry. Use the following accounting model with your own dated inputs; every blank is intentionally unpriced rather than guessed.

Monthly self-host cost = incremental host cost
                        + backup and monitoring cost
                        + (operator hours × loaded hourly cost)
                        + incident and upgrade time

Monthly hosted cost = current vendor base fee
                    + (active connections × current per-connection fee)

For our run, the measured resource row is transparent:

Component	Memory, 21 Aug 2026	Receipt	What it does not prove
Nango server	364.5 MiB	docker stats --no-stream	A steady monthly average
PostgreSQL	32.99 MiB	docker stats --no-stream	Backup or recovery readiness
Redis	3.609 MiB	docker stats --no-stream	Peak load behavior

Do not convert those MiB figures into dollars without a host-cost receipt. This system is a home-lab AI workstation already carrying other work, so the incremental resource cost is not the same thing as a dedicated production server cost. Nor should you allocate every 60.76 GiB of the reported limit to Nango; the live reading says what the containers used in one sample, nothing more.

The crossover formula is simple but only becomes honest after you fill it with evidence:

connection crossover = monthly self-host cost
                       ÷ verified vendor per-connection price

If a vendor has a base fee, subtract it from the self-host side only after confirming both plans cover the same things: environments, provider catalog, retention, support, compliance requirements, and any connection minimum. This is why “N connections at $X” without a captured pricing page is worse than no calculation. The variable that surprises founders is usually not RAM; it is their own time during the first failed OAuth flow or emergency upgrade.

5. Failure modes: the boring stack fails in named ways

The live setup is viable precisely because its failure modes are legible. Here are the ones that should appear in Priya’s runbook before a customer is routed through it.

• Auth-mode mismatch. Basic dashboard credentials are not email-login credentials. If the deployment flags do not match the intended mode, private calls fail in confusing ways. Keep the active compose configuration and the management flow together; do not rely on an old local mirror.
• Missing environment scope. Private environment API routes need ?env=dev in this deployment. A script that works against one route and quietly omits the environment on another becomes a support incident, not a minor typo.
• A fake success response. The documented SPA catch-all can answer an unknown path with dashboard HTML and HTTP 200. Verify authenticated JSON bodies, not status codes alone.
• Port and project collision. The Nango runbook records multiple compose files under the same project name and a possible 5432 collision if the wrong compose file is brought up. This multi-service workstation already has port ownership to respect. The safe response is explicit compose-file selection and state inspection, not random container deletion.
• A provider-shaped hole in the catalog. The 973-provider research record still lacked several requested crypto and broker categories. Do not close a customer deal on a provider name until its exact connection mode has been tested.
• A stack that is “up” but not usable. Containers running does not prove an OAuth callback, refresh, proxy call, or customer consent flow. The runbook’s end-to-end pattern is integration, connection, and a real provider proxy response, not a green Docker row.

6. When not to use it: skip the infrastructure first

Do not self-host Nango yet when any of these statements is true:

• You cannot name the three to five integrations customers repeatedly request; start with a request ledger and a manual workaround.
• Your required provider lives in the catalog gap; validate the provider before committing to any connector layer.
• You have no owner for updates, backups, credential rotation, and an incident. “The founder will notice” is not an operating model.
• Your stack needs external availability or a security/compliance posture you have not designed. A LAN-bound home-lab service is not automatically a customer-facing production service.
• You have not measured the hosted bill you would avoid. At that point, hosted Nango, raw OAuth, or doing nothing can all be cheaper because you have not priced your own work.

The $0 move is not “ignore integrations.” It is to make the workflow visible: record customer, provider, requested action, revenue at risk, setup time, and whether a manual route solved it. After a few repeated requests, the decision has inputs instead of vibes.

7. Run the 30-day test before you call the crossover real

Run one connector path with a named owner for 30 days. Record the baseline on day zero, repeat the same measures on day 30, and attach the raw log or export to the decision record. The targets below are measurements, not performance promises.

Metric	Day-zero baseline	Day-30 record	Receipt
Active integration connections	N = ____	N = ____	Connection inventory export
OAuth flows completed without support tickets	M = ____	M = ____	Support and connection log
Token-refresh latency p50	unverified	____ ms	Your stack’s refresh trace
Operator hours	____ h/month	____ h/month	Time ledger and incident log

Use a real test cohort, not a synthetic “all providers” exercise. For each flow, record whether it used OAuth or an API key, whether the customer completed it without help, and whether the subsequent proxy request returned the expected provider data. For the operational ledger, include backups, upgrade checks, broken callbacks, and time spent proving a 200 was actual JSON. Those are self-hosting costs even when no invoice arrives.

Decision rule: if active connection count × verified vendor per-connection price > documented self-host operating cost and the stack stays alive unattended for 30 days, keep self-hosting; otherwise use hosted Nango, reconsider Merge after a current pricing check, or delay the integration. “Alive” here must mean the tested connection and refresh path worked, not merely that Docker says Up.

8. Bottom line: buy the boring option until the meter says otherwise

For the founder with three to five integrations, hosted Nango, or no integration work until demand repeats, is probably cheaper than self-hosting because it avoids the operator time this receipt makes visible. Our deployment proves self-host Nango can be a modest, readable stack: three running containers, separate management and application auth flows, a measured point-in-time memory footprint, and a catalog large enough to be useful but not universal.

Self-host only when your own ledger shows the connection meter has crossed the line and the 30-day test shows you can operate the auth seam, refresh path, host contention, and provider gaps without babysitting them. If you cannot fill in the vendor price or the operator-hours line with a receipt, you do not have a crossover yet, you have a hunch.

---

More on this decision, three ways to look at it:

Sources

• Observed 21 August 2026: ssh kit@pc 'docker ps --filter name=nango' and docker stats --no-stream for the three Nango containers.
• Active deployment: /home/kit/projects/nango/docker-compose.yaml (read 21 August 2026; environment values redacted).
• Auth and helper receipts: /home/kit/projects/nango/bootstrap-nango.sh and /home/kit/projects/nango/nango_api.py (read 21 August 2026; no secret values reproduced).
• Local inspection mirrors: /Users/kit/projects/infra-setup/nango/docker-compose.yaml, bootstrap-nango.sh, and nango_api.py (read 21 August 2026).
• Catalog record: GBrain sessions/digest/2026-08-20, catalog research dated 20 August 2026.
• Operational gotchas: nango-selfhosted-ops Hermes skill, read 21 August 2026; cross-checked against the active compose and helper scripts.
• Merge price: to be verified from merge.dev/pricing, fetched 2026-08-21.