Environments

Environments help you segment your integration configuration and customer data across different stages of your development lifecycle.

OverviewCopy Anchor Link

Each environment in your Tenklo account is completely isolated with its own:

• Integration configurations
• Functions
• Connections
• Environment-specific settings

Production environmentsCopy Anchor Link

Any environment can be designated as a production environment. This affects how team members interact with it based on their role.

To mark an environment as production:

1. Open the environment settings (gear icon in the top navigation)
2. Toggle the Production environment switch

By default, the prod environment created with your account is already marked as production.

Engineering collaborationCopy Anchor Link

Use a shared non-production environment (usually dev) for day-to-day engineering work. The team shares integrations and the baseline function set. For local webhook testing, each engineer creates their own connections with a webhook URL override (see below).

Local webhooks on a shared environmentCopy Anchor Link

Keep the environment webhook URL pointed at your shared app (or staging backend). To receive webhooks from Tenklo locally, create connections with a per-connection webhook_url override pointing at your local webhook endpoint (for example via ngrok).

One convenient pattern is to read the override from an optional env var, so the same connect-session code works locally and when the var is unset. For example, set NANGO_CONNECTION_WEBHOOK_URL in your local .env to that URL and leave it unset elsewhere:

const webhookUrl = process.env.NANGO_CONNECTION_WEBHOOK_URL; // e.g. https://<you>.ngrok.app/webhooks-from-nango

const session = await nango.createConnectSession({
    tags: {
        end_user_id: '<END-USER-ID>'
    },
    allowed_integrations: ['<INTEGRATION-ID>'],
    ...(webhookUrl && { webhook_url_override: webhookUrl })
});

When the var is set, new connections from that session route webhooks to your machine without changing the environment webhook URLs.

Local function deploys on a shared environmentCopy Anchor Link

A full nango deploy reconciles every function in the environment. On a shared collaborative environment, that can overwrite teammates' deploys. Deploy only what you changed:

nango deploy --sync <name> <env>
nango deploy --action <name> <env>
nango deploy --integration <id> <env>   # all functions for one integration, including event functions

Reserve full deploys for environments where the repo is the sole source of truth (for example staging or prod). See the CI/CD guide.

One environment per engineerCopy Anchor Link

You can give each engineer their own environment for full isolation. You then need to recreate integrations, connections, and settings in each environment yourself; that also means more API keys to manage and config that tends to drift over time. A shared dev environment avoids that overhead for most teams.

Best practicesCopy Anchor Link

Mirror your application environments

We recommend creating Tenklo environments that match your application's deployment stages. For example:

• Development / local → dev environment
• Staging → staging environment
• Production → prod environment
• Demo → demo environment

Deploy to specific environments

When you deploy Functions, you always target a specific environment. This ensures changes are tested before reaching production.

Related guidesCopy Anchor Link

• API keys - scope keys per environment.
• Create an environment - create environments via API.
• CI/CD - deploy functions safely across environments.
• Webhooks from Tenklo - environment and per-connection webhook URLs.