How access works
Nango never receives a long-lived credential to your account. Instead, you create a role or service account that Nango can temporarily act as, and Nango authenticates with a short-lived session every time it needs to deploy or manage your instance.- AWS
- GCP
- Azure
You create an IAM role from a CloudFormation template Nango provides. Nango assumes that role using a shared external ID, which protects against the confused deputy problem — the role can only be assumed by presenting a secret only you and Nango know.
You review the CloudFormation template before creating the stack, and can revoke Nango’s access at any time by removing the trust relationship — this cuts Nango off immediately, while anything already deployed keeps running.
What leaves your account
Only operational telemetry — nothing else. Nango’s team monitors your instance’s health via Datadog, so we can catch and respond to issues before you have to file a ticket. That’s the only data that leaves your AWS account or GCP project. Nothing else leaves your account.Where your data lives
Everything else — all of it — stays inside your account:
Nango does not keep a separate copy of any of this anywhere. See Encryption & credentials below for how it’s protected at rest, and Security for the full model.
Who’s responsible for what
In short: with BYOC, your team’s ongoing workload is reviewing what Nango proposes and owning the cloud account it runs in — not running the platform day to day.
Encryption & credentials
Nango provisions a KMS Customer Master Key (CMK) in your account. The deployment identity Nango uses only has encrypt permissions on that CMK — it cannot decrypt anything with it. That CMK wraps the data-encryption key (DEK) that actually encrypts your credentials and synced records; only the running application’s workload identity inside your cluster can unwrap it. The most sensitive thing Nango stores is your end users’ connection credentials (OAuth tokens, API keys) for the integrations you connect — encrypted at rest using that DEK, inside your own Postgres. See Security for the full encryption model.Observability & support
You keep full visibility into your own instance: the dashboard, the audit trail, your own logs (ElasticSearch/OpenSearch, which you own), and your cloud provider’s monitoring and audit logs (CloudWatch/Cloud Monitoring, CloudTrail/Cloud Audit Logs) for anything the deployment identity does. Nango additionally watches instance health via Datadog — see What leaves your account — so we can catch problems on our end too. Reach us through your dedicated Slack channel; response times follow your contract’s SLA.Updates
Nango applies updates for you, delivered via GitOps once your infrastructure is provisioned — you don’t need to pull or apply anything yourself. Managed image updates are published on a two-month cadence, with occasional hotfixes as needed; see the full changelog.Cloud provider support
BYOC supports AWS and GCP today. Azure isn’t generally available yet, but we’ve deployed it for customers who needed it — talk to us if that’s you.FAQ
What would it look like to have you manage it within our environment? That feels challenging from a compliance perspective.
What would it look like to have you manage it within our environment? That feels challenging from a compliance perspective.
It’s the model described above: a role or service account you create, one Nango identity we name (never our whole org), short-lived sessions, and guardrails that stop us from widening our own access. You keep the ability to revoke access instantly, full audit logging in your own CloudTrail / Cloud Audit Logs, and sign-off on the Terraform plan before every apply. We’ll walk your security team through the exact IAM policy before you commit to anything.
What stops Nango from doing more than intended?
What stops Nango from doing more than intended?
Deny-by-default guardrails on the role or service account itself: it cannot modify its own permissions, create IAM users or long-lived keys, or touch organization/billing settings. On AWS these are explicit
Deny statements (DenySelfModification, DenyIamUsersAndFederationChanges, DenyAccountAndOrganizationControl); on GCP they’re the roles we deliberately don’t request.Can we audit what Nango does?
Can we audit what Nango does?
Yes — every action taken through the assumed role or impersonated identity is attributable in your own AWS CloudTrail or GCP Cloud Audit Logs. Many customers alert on sensitive calls (
SetIamPolicy, CreateServiceAccount) made by the Nango identity specifically.Can we leave BYOC later?
Can we leave BYOC later?
Yes. Revoking Nango’s access cuts us off immediately. The infrastructure itself is ordinary Terraform-provisioned resources in your account, not a black box, so you keep it either way.
Do you hold any compliance certifications?
Do you hold any compliance certifications?
Yes — Nango is SOC 2 compliant.
Which clouds does BYOC support today?
Which clouds does BYOC support today?
AWS and GCP. Azure isn’t generally available yet, but we’ve deployed it for customers who needed it — talk to us if that’s you.
Does Nango deploy the whole stack with Terraform?
Does Nango deploy the whole stack with Terraform?
No — Terraform provisions the infrastructure only (VPC, database, cache, cluster). The Nango application itself is deployed and kept up to date separately, via GitOps (FluxCD, installed into your cluster during setup).