BYOC
Nango-managed, in your cloud.
With BYOC, Tenklo's team deploys and operates your instance, but every resource — the database, cache, compute, load balancers, encryption keys — lives inside your own AWS account, GCP project or Azure subscription, under your own IAM controls. You keep infrastructure ownership and data residency; we keep the on-call pager.
See Self-Hosting overview for the architecture, and Self-Managed if you'd rather deploy and operate Tenklo yourselves.
How access works
Tenklo never receives a long-lived credential to your account. Instead, you create a role or service account that Tenklo can temporarily act as, and Tenklo authenticates with a short-lived session every time it needs to deploy or manage your instance.
You create an IAM role from a CloudFormation template Tenklo provides. Tenklo 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 Tenklo know.
| Trusted identity | One specific Tenklo IAM role you name (NangoPrincipalArn), not the whole Tenklo AWS account |
| Session length | Up to 4 hours per assumed-role session (a first deploy provisions EKS and Aurora and can exceed one hour) |
| Region-locked | Denied outside your chosen deployment region, plus us-east-1 (required only for CloudFront/ACM, which are global services) |
| Resource-scoped | S3 and CloudTrail access limited to resources whose names start with an agreed prefix |
| Can't self-escalate | Explicit deny on modifying its own role/policies, creating IAM users or access keys, and touching AWS Organizations or billing |
You review the CloudFormation template before creating the stack, and can revoke Tenklo'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.
That access provisions the underlying infrastructure only — the VPC, database, cache, and Kubernetes cluster. Tenklo then installs FluxCD into your cluster, which deploys and keeps the Tenklo application itself current via GitOps, independent of any further Terraform runs.
The full IAM policy, CloudFormation template or Terraform configuration, and exact resource list are shared and reviewed with your security team during onboarding — this page describes the model, not the runbook.
What leaves your account
Only operational telemetry — nothing else. Tenklo'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:
| Store | Holds |
|---|---|
| Postgres | Control-plane data, your end users' connection credentials, scheduled tasks, synced records |
| Object storage (S3 / GCS / Blob Storage) | Compiled integration code for the Runner |
| ElasticSearch / OpenSearch | Tenklo Logs |
| Redis / Valkey / Azure Managed Redis | Cache — socket info, token refresh locks, rate limits |
Tenklo 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
| Area | Tenklo | You |
|---|---|---|
| Infrastructure provisioning (VPC, database, cache, cluster) | Provisions it, via Terraform, using the access you grant | Own the underlying cloud bill |
| Application deployment & updates | Deploys and updates it, via GitOps (FluxCD) | — |
| Scaling | Handles it | — |
| Incident response / on-call | Handles it | — |
| Granting & maintaining access | — | Create and maintain the IAM role or service account; revoke it whenever you want |
| DNS & custom domains | Returns the addresses and hostnames to point at | Create the DNS records |
| Application configuration (integrations, syncs, auth settings) | — | Configure it, same as on Cloud |
In short: with BYOC, your team's ongoing workload is reviewing what Tenklo proposes and owning the cloud account it runs in — not running the platform day to day.
Encryption & credentials
Tenklo provisions a customer-managed encryption key in your account — KMS on AWS, Cloud KMS on GCP, Key Vault on Azure. The deployment identity Tenklo 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 Tenklo 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.
Tenklo 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
Tenklo 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-week 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.
It's the model described above: a role or service account you create, one Tenklo 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 Tenklo 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 Tenklo 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 Tenklo 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?
Yes. Revoking Tenklo'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?
Yes — Tenklo is SOC 2 compliant.
Which clouds does BYOC support today?
AWS, GCP and Azure.
Does Tenklo deploy the whole stack with Terraform?
No — Terraform provisions the infrastructure only (VPC, database, cache, cluster). The Tenklo application itself is deployed and kept up to date separately, via GitOps (FluxCD, installed into your cluster during setup).