Nango offers an Enterprise Self-Hosted deployment option for customers who need full control over their infrastructure. This guide covers deployment, scaling, updates, and other key operational details.

​
Features

All paid features available on Nango Cloud are also included in the Enterprise self-hosted edition.

​
Plan requirement

An Enterprise plan subscription is required.

​
Intended users

Optimized for large, regulated enterprises.

​
Deployment

By default, Nango is deployed using Helm charts. Custom deployments (e.g., ECS) are possible with our guidance. We don’t provide a CloudFormation template or AWS CDK script at this time, but we could if you need it.

​
Updates

Managed image updates are published on a two-month cadence, with occasional hotfixes as needed. Notifications about new releases will be posted to your dedicated Nango Slack channel. Managed image tags follow this format: 
nangohq/nango:managed-{managed-release-version}-{application-version}-{commit-sha}
  • managed-release-version: Semantic versioning for the image lifecycle (major = breaking, minor/patch = features/fixes)
  • application-version: Semantic version of the Nango application baked into the image
Customers should pin their CLI version to the application-version specified in the tag for compatibility. You can find the latest version by checking the managed-manifest.json. See the full changelog for details on each release.

​
Cloud provider support

Supports all major cloud providers (AWS, GCP, Azure).

​
Infrastructure components

See the detailed infrastructure components here.
  • 5 Node services (Server, Persist, Runner, Jobs, Orchestrator): 1 CPU, 2GB RAM per service
  • Postgres database: 2 CPU, 8GB RAM, 128GB storage
  • Redis data store: 128MB
  • ElasticSearch data store: 2 vCPU, 1GB RAM, 30GB storage
  • Object storage (e.g. S3): less than 500MB of storage

​
Scaling

The default configuration supports 1M+ sync/action executions per day (assuming ~2s execution time per action/sync). Auto-scaling is not provided out-of-the-box yet, but the default configuration scales far. We can guide you on configuring auto-scaling when needed. Bottlenecks mostly depend on:
  • Action/sync execution time: solved by scaling the Runner service vertically, then horizontally.
  • Cached records & size (for syncs only): solved by scaling Postgres vertically.

​
Data storage

  • 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.

​
Using existing data stores

Yes, Nango is flexible with data store setups. However, we recommend a separate instance for independent scaling.

​
Internet access requirements

  • Server: Required for proxy requests, credential management, and incoming/outgoing webhooks (inbound & outbound traffic).
  • Runner: Required for reading/writing data from external APIs during sync and action executions (outbound traffic only).

​
Multi-AZ support

Multi-AZ deployments are not automated but can be manually configured. Helm chart support is planned.

​
Exporting billing metrics

For usage-based billing, certain anonymous metrics must be exported to Nango. This can be done automatically or manually, depending on your preference. We’ll coordinate with your team during setup.

​
Exporting metrics & logs

Yes, metrics and logs can be exported to any monitoring tool using our OpenTelemetry Export add-on. Additional metrics and logs can be added upon request.
If you are interested in the Enterprise self-hosting version, please get in touch with us in the community or book a demo.