Nango is a well-engineered integration infrastructure platform for engineering teams who want code-level ownership of their entire integration layer. If your team includes dedicated integration engineers, writes TypeScript natively, and values the ability to read, modify, and own every line of sync logic - Nango is the most developer-controlled option in this category. Its 10,700+ GitHub stars, 194 releases, and growing AI agent compatibility reflect sustained, genuine development momentum.
The evaluation changes for teams without integration engineering bandwidth. Nango provides the runtime for integrations - not the integrations themselves. When a vendor says "900+ APIs supported," that means authentication and proxying infrastructure for 900+ APIs, not 900 pre-built, maintained, normalized data connectors. Teams expecting the latter will find Nango more demanding than anticipated. Both realities are covered in full below.
What Nango Does
Nango is best understood as an integration infrastructure platform - a layer between your application and external APIs that handles operational concerns so your team can focus on business logic. The platform is built around three core primitives:
- Auth - Managed OAuth 1.0/2.0, API key handling, and automatic token refresh for 800+ APIs. Authentication is handled at the platform level: no per-provider OAuth implementation, no token storage logic, no refresh scheduling.
- Proxy - An authenticated request layer that resolves the provider, injects credentials, normalizes rate-limit responses, and handles retries. Your application sends requests to Nango's proxy; Nango handles the provider-specific complexity.
- Functions - A TypeScript-based runtime where teams deploy custom integration logic. Functions run in Nango's cloud infrastructure (or your own) with built-in observability, per-tenant isolation, scheduled execution, and persistent storage.
What Nango does not provide by default: opinionated, pre-built data schemas. There is no out-of-the-box "Employee" object that normalizes differences between BambooHR, Workday, and HiBob into a single API surface. Your team writes the TypeScript that defines what normalization means for your specific use case. Nango provides the infrastructure; your engineers provide the logic.
This is a defensible architectural decision - it gives teams flexibility that managed platforms cannot match - but it requires clear expectations at evaluation time.
Architecture Deep Dive
Understanding how Nango is architected reveals why it excels for some teams and creates friction for others.
The Code-First Runtime Model
Teams using Nango author integration logic as TypeScript "sync scripts" - functions that run on Nango's distributed runner infrastructure on a schedule or in response to triggers. These scripts pull data from external APIs, transform it, and write it to Nango's storage layer, where your application consumes it via Nango's REST API or MCP server.
Nango ships approximately 250+ TypeScript script templates as starting points across common APIs. These are community-maintained starting points - useful scaffolding, but not production-ready connectors. Real-world implementations require field mapping, pagination handling, error boundary logic, and tenant-specific customization. The templates accelerate the starting point; your engineering team owns the finishing line.
This architecture is fundamentally different from managed unified API platforms, where the vendor maintains connector logic and your team calls normalized endpoints.
Self-Hosted vs. Cloud
Nango Cloud - Fully managed infrastructure with usage-based billing. Nango handles scaling, uptime, and security. Synced record data is cached in Nango's Postgres infrastructure for up to 60 days. SOC 2 Type II, GDPR, and HIPAA certifications apply to this deployment model.
Self-Hosted - You provision and operate Nango on your own infrastructure. The minimum production-grade setup requires:
- Five Node.js services (Server, Persist, Runner, Jobs, Orchestrator) - 1 CPU and 2 GB RAM each
- Postgres - 2 CPU, 8 GB RAM, 128 GB storage
- Redis - 128 MB
- Elasticsearch - 2 vCPU, 1 GB RAM, 30 GB storage
- Object storage - less than 500 MB
This is a non-trivial infrastructure footprint. Critically, production self-hosting - including Functions, Webhooks, and the MCP server - requires an Enterprise plan subscription. The "free self-hosted" option available to teams covers only a subset of platform capabilities. Engineers evaluating Nango for $0 total cost should validate which specific features their production use case requires against the feature matrix before committing.
Licensing Reality
Nango is released under the Elastic License 2.0, not MIT or Apache 2.0. This is an important distinction for procurement teams: the Elastic License permits internal use, self-hosting for your own organization, and modification. It prohibits reselling Nango as a hosted service to external customers without a commercial agreement. For the vast majority of SaaS teams using Nango internally, this restriction does not apply - but it should be reviewed for platform engineering use cases.
How It Differs from Unified APIs
A schema-normalized unified API (Merge, Knit, Apideck) presents a consistent API surface across multiple underlying providers. Your code calls /hris/employees and receives a normalized response regardless of whether the customer runs Workday, BambooHR, or Personio. The vendor maintains that normalization layer.
Nango gives you the infrastructure to build that normalization layer yourself. If you need custom schemas that precisely fit your data model - common in vertical SaaS or multi-category products - Nango's approach is architecturally superior. If your requirements are standard HRIS or CRM sync patterns, rebuilding normalization from scratch means duplicating work that managed platforms have already done and continuously maintain.
Integration Coverage
Nango's catalog covers 800-900+ APIs at the authentication and proxy layer, with TypeScript sync script templates for approximately 250+ of those. The breadth is genuine: the list extends well beyond the HRIS/ATS/CRM verticals that dominate managed unified API catalogs, including developer tooling, vertical SaaS, marketing platforms, and consumer APIs that managed platforms rarely prioritize.
What "Coverage" Actually Means
The critical distinction for evaluation purposes:
- Authentication coverage (800-900+ APIs): Nango can authenticate your application against these APIs. This is fully managed and production-ready.
- Proxy coverage (800-900+ APIs): Nango's proxy layer handles rate limiting, retries, and credential injection for these APIs.
- Sync script templates (~250+ APIs): Nango ships starting-point TypeScript logic for data syncing. These require customization for production deployment.
A managed unified API platform listing 100 connectors has typically invested significantly more engineering effort per connector - including edge case handling, pagination normalization, schema maintenance, and ongoing updates when APIs change. Comparing API count between code-first and managed platforms conflates infrastructure coverage with connector maturity.
AI Agent Integration Capabilities
One of Nango's most distinctive recent developments is native support for AI coding agents as integration builders. The platform integrates with 18+ coding agents - including Claude Code, Cursor, Codex, and Gemini CLI - enabling these agents to research an API, write a TypeScript integration function, and deploy it to Nango's runtime, all within a single session without requiring a local project.
The built-in MCP server at https://api.nango.dev/mcp exposes every deployed action as a deterministic tool call over both REST and MCP protocols. This makes Nango distinctly interesting for AI-native engineering teams: rather than maintaining a catalog of pre-built integrations, teams can provision integrations on demand through agent-driven development.
In practice, coding agents writing TypeScript sync scripts still benefit from human review before production deployment. The value is acceleration and reduction of boilerplate - not elimination of engineering oversight. But for teams already running AI-assisted development workflows, Nango's agent compatibility creates real productivity leverage.
Pricing
Nango's current pricing structure (verify at nango.dev for the most current rates):
The free tier provides a functional evaluation environment with meaningful limitations on integration count. The Starter-to-Growth gap is substantial in absolute terms but competitive relative to the managed alternatives landscape - Merge's entry pricing is typically reported at $650/month for comparable team-level access.
Total Cost of Ownership: The Full Picture
Cloud subscription cost is only one component of Nango's total cost of ownership. For honest evaluation, engineering teams should model:
- Initial integration development: Writing, testing, and deploying TypeScript sync scripts for each integration your customers require. For a typical B2B SaaS product supporting 10-15 integrations, this represents weeks to months of engineering time.
- Ongoing maintenance: API providers deprecate fields, change pagination, introduce breaking schema changes. Every change requires a sync script update. At scale - 30, 50, or more provider integrations - this maintenance burden is significant.
- Self-hosting infrastructure: For data residency requirements, the DevOps overhead of operating Nango's five-service stack adds ongoing operational cost beyond the Enterprise subscription.
Teams that compute engineering time at market rates frequently find that Nango's total cost of ownership converges with or exceeds managed alternatives for standard integration categories. The calculus reverses for non-standard, high-customization scenarios where managed platforms cannot serve the use case.
Developer Experience
The developer experience on Nango is strong within its design constraints - and appropriately demanding outside them.
Where Nango Shines
Authentication is a solved problem. This is Nango's clearest strength. OAuth implementation, token storage, refresh scheduling, and multi-tenant credential isolation are handled correctly, transparently, and at scale. The engineering time this saves is real.
Full code ownership and auditability. Integration logic lives in your repository, reviewed in your PRs, versioned in your git history, and deployed through your existing CI/CD pipeline. For teams with strong engineering culture around code ownership, this is a real advantage.
Deep observability in every plan. Unlike platforms that reserve logging and tracing for Enterprise tiers, Nango includes full request/response observability in all paid plans, with OpenTelemetry export available from the Growth tier. This is a better default than competitors.
Active development and community. With 10,700+ GitHub stars, 1,100+ forks, and a sustained release cadence averaging multiple releases per month through mid-2026, Nango is actively maintained. The open codebase means issues can be diagnosed and contributed to by the community.
Coding agent compatibility. For teams using AI coding assistants as primary development tools, Nango's native agent integrations are a useful accelerator. The engineering interface is designed for agent-assisted development, not bolted on.
Where It Becomes a Burden
Maintenance at scale compounds over time. Managing 20, 30, or 50 TypeScript sync scripts - each with provider-specific quirks around pagination, rate limits, and field naming - grows from "acceptable overhead" to "significant operational burden" as the integration catalog expands.
Custom tenant requirements require code changes. When an enterprise customer requires a custom field mapping or tenant-specific data transformation, Nango requires a code change and deployment rather than a configuration update. For high-volume, highly customized enterprise SaaS, this creates deployment pressure.
Webhook reliability constraints. Nango's webhook processing system has a 20-second timeout and a maximum of two retry attempts. For event-driven pipelines where event delivery guarantees matter, teams must implement compensating idempotency logic and evaluate whether these constraints fit their reliability requirements.
Self-hosting is operationally demanding. Teams that select self-hosting for data sovereignty reasons frequently underestimate the ongoing DevOps investment. Auto-scaling is not provided out of the box; capacity planning requires understanding Nango's architecture deeply enough to tune Runner scaling and Postgres performance independently.
Compliance and Security
Nango's compliance posture is credible for enterprise evaluation.
Certifications (cloud): SOC 2 Type II, GDPR compliance, and HIPAA with BAA available on Enterprise plans. These credentials support regulated industry deployment and enterprise security review.
Self-hosted data sovereignty: In self-hosted deployments, customer API credentials remain in the organization's own Postgres database, encrypted with an encryption key that Nango never holds. Authentication tokens never leave the organization's infrastructure. For teams with strict data residency requirements - healthcare, financial services, government - this is a real control worth evaluating.
Source auditability: Nango publishes its full platform source under the Elastic License 2.0. Security teams can audit credential storage, encryption implementation, token refresh logic, and runner isolation without relying on vendor attestations. This transparency became more notable following the May 2026 Composio breach, which demonstrated the risks inherent to centralized, opaque credential storage in closed-source platforms.
Cloud data handling: In Nango-managed cloud deployments, synced record data is cached in Nango's Postgres infrastructure. Teams with zero-tolerance for third-party data storage should evaluate the proxy-only deployment mode or self-hosting, and should explicitly validate what data Nango persists versus passes through in their specific implementation.
Honest Limitations
These constraints are not disqualifiers for the right team. They are accurate conditions that must be understood before making a purchasing decision.
The "900 APIs" Distinction
Nango's API catalog breadth is frequently the first number cited in evaluations - and the most commonly misread. It is technically accurate. It does not indicate 900 pre-built, continuously maintained, schema-normalized data connectors.
To evaluate real connector depth for your use case: request a live demo against the specific providers your customers use. Examine the TypeScript sync script templates for those providers. Understand what customization they will require before production deployment. The answers to these questions determine whether Nango's catalog breadth translates into reduced integration engineering effort for your specific needs.
Engineering Overhead Is the Architecture, Not a Side Effect
The central architectural premise of Nango - that integration logic should be code your team owns - makes engineering overhead structural and permanent. Every new integration requires engineering investment. Every API change requires an engineering response. Teams that do not plan for this correctly at the outset will face a difficult recalibration once the integration backlog grows beyond a few providers.
Production Self-Hosting Requires Enterprise Subscription
Free self-hosting covers basic auth management. Production-grade self-hosting - including Functions, Webhooks, MCP server, RBAC, and advanced observability - requires an Enterprise plan. This is a legitimate business model, but teams selecting Nango specifically for $0 cost must verify the complete feature matrix against their production requirements.
No Normalized Unified Schema by Default
Nango is not a unified API in the sense that Merge, Knit, or Apideck are. It provides infrastructure to build one. For teams whose integration needs map cleanly onto standard categories (HRIS, ATS, CRM, Ticketing, Accounting), the question is whether building and maintaining your own normalization layer is the highest-value use of your engineering team's time.
Who Nango Is Best For
- Engineering-led product teams with one or more dedicated integration engineers who are comfortable owning and maintaining TypeScript sync logic at scale.
- Teams with non-standard integration requirements where managed platforms' fixed schemas do not accommodate the data model or the specific providers needed.
- Open-source-preference organizations that require auditability, self-hosting capability, or the ability to contribute to and modify the platform itself.
- AI-native engineering teams using coding agents as primary development tools, where Nango's agent-compatible integration model and built-in MCP server create real workflow advantages.
- Companies building for vertical or niche APIs not covered by managed unified API catalogs - developer tools, regional SaaS, industry-specific platforms.
Who Should Evaluate Alternatives
- Teams without dedicated integration engineers. Nango's operational model assumes integration engineering capacity. Without it, the platform creates a maintenance burden that cannot be sustainably managed.
- Product teams expecting pre-built, managed connectors. If the expectation is a vendor-maintained connector library that your team configures rather than codes, Nango does not match that operational model.
- Teams requiring zero third-party data storage. In cloud mode, Nango caches synced record data. Teams in regulated industries or with contractual zero-storage obligations need to evaluate carefully.
- Teams needing normalized schemas across standard categories. For standard HRIS, ATS, CRM, Ticketing, or Accounting integration patterns, managed unified API platforms have already invested the engineering effort your team would need to replicate with Nango.
- Fast-moving teams without integration engineering bandwidth. If integrations are a product requirement but not a core engineering investment area, the ongoing maintenance obligation Nango creates will compete with product roadmap priorities.
Alternatives Worth Considering
On architectural differences: Knit and Nango serve opposite operational models. Nango provides infrastructure for teams to build and own their integration logic - high control, high engineering investment. Knit provides a fully managed, stateless integration layer where customer data is never cached: webhook-first delivery, 100+ pre-built connectors across 13 categories (HRIS, ATS, CRM, Accounting, Ticketing, and more), MCP server support, and an AI connector builder that ships new integrations within two days. Teams that want to write integrations should evaluate Nango. Teams that want to ship integrations without writing or maintaining sync code should evaluate Knit. These are different operational bets, not better-or-worse on an absolute scale.
FAQ
Is Nango truly open source?
Nango is source-available under the Elastic License 2.0. This permits internal use, self-hosting, and modification within a single organization. It does not qualify as OSI-approved open source, and it prohibits offering Nango as a hosted service to third parties. For most SaaS teams using Nango for their own product integrations, these restrictions do not apply. For platform engineering teams building multi-tenant hosted services, the license should be reviewed before committing.
How many pre-built, production-ready integrations does Nango provide?
Nango provides authentication and proxying infrastructure for 800-900+ APIs, and TypeScript sync script templates for approximately 250+ of those. These templates are starting points, not production-ready connectors. They commonly require field mapping customization, pagination handling, and edge-case logic before deploying to production. Evaluate the specific template for each API your customers use - the quality and completeness varies by provider.
What does it cost to self-host Nango in production?
Self-hosting Nango at production scale requires five Node.js services, Postgres (2 CPU/8 GB RAM/128 GB storage), Redis, Elasticsearch, and object storage. Full feature availability - including Functions, Webhooks, and the MCP server - requires an Enterprise plan subscription. DevOps overhead for maintaining this infrastructure should be factored explicitly into total cost of ownership alongside the subscription cost.
How does Nango support AI agent use cases?
Nango ships a built-in MCP server exposing every deployed action as a deterministic tool call over REST and MCP protocols. It integrates natively with 18+ coding agents including Claude Code, Cursor, and Codex. Coding agents can research an API, write the integration function, and deploy it to Nango's runtime. This positions Nango as infrastructure for building agentic integrations - teams write custom tool definitions and data syncs; Nango manages the runtime. For teams wanting to consume pre-built AI-ready integrations without writing code, managed platforms with native MCP support are a better fit.
What are Nango's webhook reliability constraints?
Nango's webhook processing system has a 20-second timeout per event and a maximum of two retry attempts. For high-throughput or high-reliability event pipelines, teams should implement idempotency guarantees in their own application layer and validate whether these constraints meet their SLA requirements. Applications that cannot tolerate missed webhook events need compensating architecture.
How does Nango compare to Knit for teams building AI-native SaaS?
Nango and Knit address AI-native integration from opposite architectural directions. Nango gives coding agents the tools to build custom integration logic on demand - a strong fit for teams that want code-level control and have the engineering capacity to sustain it. Knit provides a fully managed, stateless layer with pre-built connectors across 13 categories, MCP server support, and zero integration engineering overhead - a strong fit for teams that want to ship integrations quickly without maintaining sync code. The right choice depends on whether integration ownership is a core product investment for your team or an operational requirement to fulfill efficiently.
Pricing, feature availability, API counts, and certification status are current as of August 2026 and subject to change. Verify directly at nango.dev before making procurement decisions.
Knit is a unified API platform covering 13+ integration categories with a webhook-first, zero-storage architecture and MCP server support for AI agent workflows. SOC 2 Type II and ISO 27001 certified. G2 rating: 4.9/5 for Ease of Integration.
