​
Architecture diagram

Nango's infrastructure components

​
Infrastructure components

Nango consists of several core services, each handling specific responsibilities:
  • Server (Node service): Powers the dashboard, API, proxy requests, and incoming/outgoing webhooks.
  • Orchestrator (Node service): Manages task scheduling and state tracking.
  • Jobs (Node service): Processes tasks and dispatches them to the Runner.
  • Runner (Node service): Executes integration code and interacts with external APIs.
  • Persist (Node service): Stores synced records and logs.
  • Postgres: Stores data for the control plane, API credentials, scheduled tasks, and synced records.
  • Object Storage (e.g. S3): Stores compiled integration code for execution by the Runner.
  • ElasticSearch: Stores execution data.
  • Redis: Caches system data, including socket information, token refresh locks, and rate limits.

​
Cloud vs. self-hosted architecture

The Nango architecture is largely the same for both Cloud and Enterprise self-hosting. This ensures self-hosted instances benefit from continuous dogfooding and load testing. The primary differences are:
  • In the Cloud version, the Runner service runs as isolated instances per customer.
  • The Postgres database is segmented by use case (control plane, task scheduling, synced records).

​
Email service

Nango uses emails for account verification, password reset, and sending invitations, etc… Any SMTP server can be configured to be used by Nango for these email communications.
Questions, problems, feedback? Please reach out in the Slack community.