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. That stops new sessions being issued; credentials already issued stay valid until they expire, and 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, GCP project or Azure subscription. 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 customer-managed encryption key in your account — KMS on AWS, Cloud KMS on GCP, Key Vault on Azure. The deployment identity Nango uses only has encrypt permissions on that key — it cannot decrypt anything with it. That key 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 or Azure Monitor; CloudTrail, Cloud Audit Logs or the Azure Activity Log) 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, GCP and Azure.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 at any time, 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. On Azure the guardrail is narrower and worth stating precisely: a condition stops the identity granting itself Owner, User Access Administrator or Role Based Access Control Administrator, and it holds no directory permissions at all, but it can assign the other roles its own deployments need.Can we audit what Nango does?
Can we audit what Nango does?
Yes — every action taken through the assumed role, impersonated identity or service principal is attributable in your own AWS CloudTrail, GCP Cloud Audit Logs or Azure Activity Log. Many customers alert on sensitive calls (
SetIamPolicy, CreateServiceAccount) made by the Nango identity specifically. Note that the Azure Activity Log records control-plane operations; data-plane calls such as reading a Key Vault secret are captured only if you enable diagnostic settings on the resource.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, GCP and Azure.
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).