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.

​

Recommended configuration

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