Self-Managed

With Self-Managed, you deploy Tenklo yourself and are responsible for operating it — upgrades, scaling, and on-call — on your own infrastructure, any cloud or on-prem. This gives you the most flexibility over infrastructure, at the cost of running it.

See Self-Hosting overview for the architecture, and BYOC if you'd rather have Tenklo deploy and operate it inside your cloud account for you.

QuickstartCopy Anchor Link

Custom deployments (e.g., ECS instead of Kubernetes) are possible with our guidance — reach out if the Helm chart isn't the right fit for your infrastructure.

What leaves your accountCopy Anchor Link

Nothing. Self-hosted instances don't send any telemetry, logs, or data back to Tenklo automatically. You're the only one with visibility into your instance, unless you choose to export metrics to your own monitoring tool, or share something with us directly when asking for support.

Where your data livesCopy Anchor Link

Everything runs on your infrastructure, configured by you:

See Data storage on the overview page for more, and Security for how credentials are encrypted at rest.

Who's responsible for whatCopy Anchor Link

In short: budget for a platform team that can run Kubernetes in production. Tenklo ships the images and the chart; you run them.

Encryption & credentialsCopy Anchor Link

Encryption is entirely in your hands. At minimum, set NANGO_ENCRYPTION_KEY yourself; if you'd rather not manage it as a flat secret, you can wrap it with your own KMS instead.

The most sensitive thing Tenklo stores is your end users' connection credentials (OAuth tokens, API keys) for the integrations you connect — encrypted at rest once you've set a key, inside your own Postgres. See Security for the full model.

Observability & supportCopy Anchor Link

Everything is visible to you, and only you — the dashboard, the audit trail, your logs, your metrics. Tenklo has no visibility into your instance unless you choose to share something with us.

Support follows your contract's SLA. Reach out through your support channel with what you're seeing (logs, dashboard state, error messages) — we can't look at your instance ourselves.

UpdatesCopy Anchor Link

You pull and apply updates yourself. Notifications about new releases are available by subscribing to the NangoHQ/managed-image-releases repository:

• GitHub: watch the repository, select Custom, and enable Releases.
• RSS/Atom: subscribe to https://github.com/NangoHQ/managed-image-releases/releases.atom, which can be wired into Slack, Microsoft Teams, RSS readers, or internal automation.

Each release includes the managed image tag, application version, source commit hash, release date, Docker pull reference, a GitHub compare link to the previous managed release, and a generated changelog of changes since the previous managed release.

Image tagsCopy Anchor Link

Managed image tags follow this format:

nangohq/nango:managed-{managed-release-version}-{application-version}-{commit-sha}

• managed-release-version: Semantic version for the managed image lifecycle (major = breaking, minor/patch = features/fixes)
• application-version: Semantic version of the Tenklo application baked into the image
• commit-sha: Full Git commit hash of the released source

For example, pull a release from Docker Hub with:

docker pull nangohq/nango:managed-1.5.4-0.70.4-0fe07a6d83aea0becc4cea382c5cead2f555718d

Pin your CLI version to the application-version specified in the tag for compatibility.

Versions and policyCopy Anchor Link

You can find the latest version in managed-manifest.json on managed-image-releases (mirrored from NangoHQ/nango on each release). The in-repo CHANGELOG.md tracks release history.

Each managed release maps to a specific source commit, and published image tags are never changed after release. Stay reasonably current with managed image releases. See the full changelog for details on each release.

Cloud provider supportCopy Anchor Link

Self-Managed supports all major cloud providers (AWS, GCP, Azure) and on-prem Kubernetes, since you're the one operating it.

Configuration referenceCopy Anchor Link

Everything below is what you configure directly to run a production instance — env vars, secrets, and the hardening options available to you.

Minimum environment variablesCopy Anchor Link

Minimum secretsCopy Anchor Link

Encryption keyCopy Anchor Link

You must provide your own encryption key via the NANGO_ENCRYPTION_KEY environment variable to enable encryption at rest. It encrypts credentials in the control-plane database as well as data in the records cache. Without this key, credentials are stored unencrypted.

The records cache always requires this key. If you run sync functions that persist records, the persist and records services fail to store or retrieve records when NANGO_ENCRYPTION_KEY is not set—they do not fall back to plaintext.

openssl rand -base64 32

If you'd rather not manage NANGO_ENCRYPTION_KEY as a flat secret, wrap it with your own KMS and set NANGO_ENCRYPTION_KEY_WRAPPED instead, plus exactly one wrapping-key variable:

Credentials come from the environment (IAM role, workload identity or managed identity), and Tenklo needs permission to unwrap with that key. On Azure, use an RSA key and include its version in the identifier.

Data retentionCopy Anchor Link

The default retention period for deleted connections is 31 days. You can configure this via the CRON_DELETE_OLD_CONNECTIONS_MAX_DAYS environment variable.

Audit trailCopy Anchor Link

The audit trail records control-plane activity — who created a connection, changed an integration, rotated an API key or signed in, from which IP, and whether it succeeded. Self-hosted instances keep it in Postgres, and teammates read it from Audit trail in the dashboard.

Enable it on the server:

FLAG_AUDIT_TRAIL_ENABLED=true
NANGO_AUDIT_POSTGRES_DATABASE_URL=postgresql://user:password@host:port/dbname
NANGO_AUDIT_POSTGRES_SSL=true

Without a database there is nowhere to keep entries, so the trail stays off rather than showing a page that never fills. Set NANGO_AUDIT_POSTGRES_SSL=true when the database is external, as with the main one. The URL can point at the database Tenklo already uses or at a separate one, and the server creates the schema on startup along with the rest of it when NANGO_MIGRATE_AT_START=true.

Entries are kept for a year by default, and the server removes expired ones for you:

NANGO_AUDIT_POSTGRES_RETENTION_DAYS=365

Feature flagsCopy Anchor Link

Tenklo gates some behavior behind feature flags. Flags are served by the provider set in NANGO_FLAG_PROVIDER, which defaults to noop, so every flag uses its built-in default.

To serve flags from environment variables instead, set NANGO_FLAG_PROVIDER=env, then set one variable per flag, named after the flag key uppercased with dashes replaced by underscores and prefixed with NANGO_FEATURE_FLAG_:

NANGO_FLAG_PROVIDER=env
NANGO_FEATURE_FLAG_PROXY_FORWARD_ALL_RESPONSE_HEADERS=true

This serves true for the proxy-forward-all-response-headers flag on every account on the instance. Flags with no variable set keep their built-in default. Boolean flags accept true or false. A value that doesn't match the flag's type is ignored, and the flag keeps its default.

The variables apply to the whole process, so there is no per-account targeting or gradual rollout. Set them on every service that evaluates the flag, and note that each service reads them at startup.

Two-factor authenticationCopy Anchor Link

Two-factor authentication is behind the mfa flag, which only the server evaluates. Set these on the server service to enable it:

NANGO_FLAG_PROVIDER=env
NANGO_FEATURE_FLAG_MFA=true

Once the server restarts, users can turn it on from their profile settings by pairing an authenticator app and saving their backup codes. Tenklo then asks them for a code at login.

OAuth state cookie enforcementCopy Anchor Link

When an OAuth flow starts, Tenklo sets a cookie in the user's browser that is tied to that flow. By default, a callback that arrives without this cookie is still accepted. To reject it instead, so the flow can only be completed by the browser that started it, set these on the server service:

NANGO_FLAG_PROVIDER=env
NANGO_FEATURE_FLAG_OAUTH_STATE_COOKIE_ENFORCEMENT=true

With the flag on, a callback forwarded from your backend or sent by a fetch request without the state cookie fails with a state_cookie_err error. Make sure the callback reaches Tenklo as a redirect in the same browser that opened the authorization page.

The check covers OAuth 2 based flows, including MCP OAuth. It does not apply to App, OAuth 1, or plugin install flows.

Server URL, callback URL, and custom domainsCopy Anchor Link

Add server environment variables for the instance URL and port in the .env file or directly in your hosting provider:

NANGO_SERVER_URL=<INSTANCE-URL>
SERVER_PORT=<PORT>

The resulting OAuth callback URL is <INSTANCE-URL>/oauth/callback.

If you front one Tenklo process with two ingresses (a public host for OAuth callbacks and webhooks, an internal host for the dashboard), set:

NANGO_DASHBOARD_API_URL=/

/ keeps dashboard API requests on whichever host served the page. Callback and webhook URLs still use NANGO_SERVER_URL. Set an absolute URL instead if the dashboard is hosted separately from the API.

Management MCP serverCopy Anchor Link

The Management MCP server runs as part of the main Tenklo server. To enable it, configure a dedicated hostname and route traffic for that hostname to the Tenklo server:

NANGO_MANAGEMENT_MCP_SERVER_URL=https://mcp.example.com

The hostname must be different from the hostname in NANGO_SERVER_URL. Tenklo uses the request hostname to distinguish Management MCP traffic from the public API. Restart the Tenklo server after setting the environment variable; the Management MCP endpoint is then available at https://mcp.example.com/mcp.

Agent PlaygroundCopy Anchor Link

The Agent Playground lets you try an AI agent on your integrations from the dashboard, before writing any code. It runs on agent sessions, so the agent reaches Tenklo's pre-built tools the same way your own agent would. It is off by default on self-hosted instances.

To turn it on, set these on the server service:

NANGO_FLAG_PROVIDER=env
NANGO_FEATURE_FLAG_AGENT_PLAYGROUND=true
NANGO_FEATURE_FLAG_TOOLS_CATALOG=true
OPENAI_API_KEY=<your-openai-api-key>
# Optional, defaults to gpt-6-luna
NANGO_AGENT_PLAYGROUND_MODEL=<openai-model-id>

Set NANGO_FLAG_PROVIDER=env and NANGO_FEATURE_FLAG_TOOLS_CATALOG=true on the jobs service as well, because jobs runs the catalog actions the agent calls.

The tools-catalog flag lets the agent run Tenklo's pre-built actions without deploying them first. The agent runs on OpenAI, so OPENAI_API_KEY is required, and messages from the chat are sent to OpenAI with that key. Without the key, the dashboard shows the playground as unavailable.

Connect UICopy Anchor Link

Tenklo Connect is available for self-hosted deployments in the main Docker image.

FLAG_SERVE_CONNECT_UI=true
NANGO_CONNECT_UI_PORT=3009
NANGO_PUBLIC_CONNECT_URL=<INSTANCE-URL>

Tenklo Connect is available by default at http://localhost:3009.

Hosting under a base pathCopy Anchor Link

Connect UI works under any base path, for example behind a reverse proxy that routes services by path. Set NANGO_PUBLIC_CONNECT_URL to the full URL including the path:

NANGO_PUBLIC_CONNECT_URL=https://example.com/nango/connect

Tenklo uses this URL when generating links to Connect UI and in the dashboard's security headers, so it must match what end users load in the browser.

Your reverse proxy must strip the base path prefix before forwarding to Connect UI: a request for /nango/connect/assets/app.js must reach Connect UI as /assets/app.js.

Connect UI is a single-page app: the server must respond with index.html for any path that isn't a built asset, including the base path without a trailing slash. Tenklo's static file server handles this out of the box; if you serve the built dist from your own static host, enable its SPA fallback.

See Auth for the end-user connection flow.

Persistent storageCopy Anchor Link

If you deploy with Docker Compose, the bundled database uses local container storage. This is not appropriate for production.

Connect Tenklo to an external Postgres database by setting the database environment variables:

NANGO_DB_USER=<REPLACE>
NANGO_DB_PASSWORD=<REPLACE>
NANGO_DB_HOST=<REPLACE>
NANGO_DB_PORT=<REPLACE>
NANGO_DB_NAME=<REPLACE>
NANGO_DB_SSL=true

You can also use a database URL:

NANGO_DATABASE_URL=postgresql://user:password@host:port/dbname

Special characters in NANGO_DATABASE_URL must be URL encoded.

Records saved by sync functions can be persisted in a dedicated database. To use a dedicated records database, set RECORDS_DATABASE_URL:

RECORDS_DATABASE_URL=postgresql://user:password@host:port/dbname

Special characters in RECORDS_DATABASE_URL must be URL encoded. If it is not specified, records are stored in the main database.

External RedisCopy Anchor Link

The bundled Redis is fine for local use but not for production. Connect Tenklo to an external Redis (or Valkey) with either a full URL or discrete variables:

NANGO_REDIS_URL=rediss://:<password>@<host>:<port>
# or
NANGO_REDIS_HOST=<host>
NANGO_REDIS_PORT=<port>
NANGO_REDIS_AUTH=<password>

Use the rediss:// scheme (or discrete variables, which default to TLS) to enable in-transit encryption.

IAM / short-lived token authenticationCopy Anchor Link

Managed Redis with IAM authentication (for example GCP Memorystore for Valkey) uses a short-lived token as the password and requires the token to be refreshed before it expires. Instead of a static NANGO_REDIS_AUTH, point Tenklo at a file that an external process (such as a sidecar) keeps up to date:

NANGO_REDIS_HOST=<host>
NANGO_REDIS_PORT=<port>
NANGO_REDIS_AUTH_TOKEN_FILE=/path/to/token   # re-read on every (re)connect
NANGO_REDIS_USERNAME=<username>              # optional; defaults to "default"

Tenklo reads the token file on every connection and reconnection, so a rotated token is always picked up without a restart. This is cloud-agnostic: anything that writes the current token to the file works. The writer must update the file atomically — write a temporary file and rename() it into place — so a reconnect never reads a half-written token and fails authentication. When NANGO_REDIS_AUTH_TOKEN_FILE is set, do not embed credentials in NANGO_REDIS_URL.

The runner boundary has the same set of variables prefixed with NANGO_CUSTOMER_REDIS_ (for example NANGO_CUSTOMER_REDIS_AUTH_TOKEN_FILE); it falls back to the system Redis when unset.

Securing your instanceCopy Anchor Link

Proxy base URL override hardeningCopy Anchor Link

The proxy can send authenticated requests to external APIs. Some proxy calls accept a base URL override (HTTP header Base-Url-Override, SDK baseUrlOverride, or an integration custom.baseUrl) to target a host that differs from the provider's default API base URL.

Because the proxy makes outbound HTTP requests from your Tenklo server (and from the runner for sync and action scripts), a caller with permission to use the proxy could use an override to reach hosts that were not meant to be exposed—such as cloud metadata services or localhost on the host making the request. This is a classic SSRF risk.

By default, Tenklo keeps base URL override enabled and blocks override targets and redirect hops whose hostnames match a built-in denylist (cloud metadata and loopback addresses). Configure these environment variables and restart the server and runners after changes:

NANGO_PROXY_BASE_URL_OVERRIDE_ENABLED=true
NANGO_PROXY_BASE_URL_OVERRIDE_DENYLIST='["169.254.169.254","metadata.google.internal","localhost","127.0.0.1","[::1]"]'

Operator guidance:

• Production: keep the default denylist. Add environment-specific hosts if your deployment exposes additional internal endpoints.
• Legitimate localhost overrides (dev only): set NANGO_PROXY_BASE_URL_OVERRIDE_DENYLIST='[]' to restore fail-open behavior.
• No overrides at all: set NANGO_PROXY_BASE_URL_OVERRIDE_ENABLED=false.

Denylist matching is hostname-based and applies to redirect hops as well as the initial override target.

Outbound URL policy (DNS rebinding, private IPs, redirects)Copy Anchor Link

Beyond the hostname denylist, Tenklo routes every outbound connection on the proxy, customer webhook delivery, and uncontrolledFetch paths through DNS-pinning agents that re-validate the resolved IP address — closing DNS-rebinding and redirect-to-internal-address SSRF holes. The behavior is controlled by NANGO_OUTBOUND_URL_POLICY, a JSON object (applied on top of the denylist). It propagates automatically to runners.

The mode field selects how hostnames are filtered:

• denylist (default): every destination is reachable except hostnames on the denylist (plus the IP-based protections below). This is the out-of-the-box mode, since the denylist always carries the secure defaults.
• allowlist: only hostnames in allowlist are reachable (a leading . matches subdomains); everything else is rejected. The denylist and the IP-based protections still apply on top, so allowlist is strictly more restrictive — a listed hostname that resolves to a blocked IP is still rejected.
• permissive: no hostname-based filtering (the IP-based protections below still apply). You only reach this mode deliberately — either by emptying the server denylist with no explicit mode (see below), or by setting mode: "permissive".

# Block private/link-local IPs (default) and cap redirects at 3
NANGO_OUTBOUND_URL_POLICY='{"blockPrivateIps":true,"blockLinkLocal":true,"maxRedirects":3}'

# Allowlist mode: only the listed hostnames (and their subdomains) are reachable
NANGO_OUTBOUND_URL_POLICY='{"mode":"allowlist","allowlist":[".hubspot.com","api.github.com"]}'

Each resolved address (including on every redirect hop) is validated; in allowlist mode, only listed hostnames are reachable regardless of IP.

The same DNS-pinning protection also covers OAuth/token flows (token exchange, refresh, AWS STS, and JWT-bearer token endpoints). These use a separate overlay, NANGO_OUTBOUND_URL_POLICY_OAUTH, applied on top of NANGO_OUTBOUND_URL_POLICY but with the same JSON shape. The only difference is the default: blockPrivateIps is false for OAuth so self-hosted integrations whose token endpoints live on a private network keep working. Loopback and unspecified addresses stay blocked regardless. Link-local/metadata addresses (including the cloud-metadata IP 169.254.169.254) stay blocked by default through blockLinkLocal, but that check is disabled if you set blockLinkLocal:false. Lock OAuth down to public hosts only by setting blockPrivateIps:

NANGO_OUTBOUND_URL_POLICY_OAUTH='{"blockPrivateIps":true}'

Securing the dashboardCopy Anchor Link

By default, the dashboard of your Tenklo instance is open to anyone who can access your instance URL.

You can secure it with Basic Auth by setting the following environment variables and restarting the server:

FLAG_AUTH_ENABLED=false
NANGO_DASHBOARD_USERNAME=<PICK-A-USERNAME>
NANGO_DASHBOARD_PASSWORD=<PICK-A-PASSWORD>

Internal mTLSCopy Anchor Link

If you terminate mutual TLS between Tenklo services at a load balancer or service mesh, Tenklo can present a client certificate on its service-to-service calls (server to orchestrator, jobs to orchestrator, jobs to runner, runner to jobs, runner to persist, runner to server).

Tenklo does not terminate TLS itself. Enforcement stays with your load balancer; these variables only control the certificate Tenklo sends as a client.

Provide each asset inline, as raw PEM or base64-encoded PEM:

NANGO_INTERNAL_TLS_CERT=<CLIENT-CERTIFICATE-CHAIN-PEM>
NANGO_INTERNAL_TLS_KEY=<CLIENT-PRIVATE-KEY-PEM>
NANGO_INTERNAL_TLS_CA=<INTERNAL-CA-PEM>

Or point at mounted files, which is usually easier with Kubernetes secrets:

NANGO_INTERNAL_TLS_CERT_FILE=/etc/nango/tls/tls.crt
NANGO_INTERNAL_TLS_KEY_FILE=/etc/nango/tls/tls.key
NANGO_INTERNAL_TLS_CA_FILE=/etc/nango/tls/ca.crt

Operator guidance:

• Set the variables on every service. Each one is both a client and a server in this topology.
• Runners started at runtime by the jobs service inherit the configuration automatically, as resolved PEM, regardless of which form you used on jobs itself. On Kubernetes the assets go into a per-runner Secret named <runner>-internal-tls, created and deleted alongside the runner's deployment, so the pod references the key instead of carrying it in its spec. This needs secrets permissions in the jobs role, which the Helm chart grants by default.
• Point the internal service URLs at your TLS listeners: ORCHESTRATOR_SERVICE_URL, JOBS_SERVICE_URL, PERSIST_SERVICE_URL, SERVER_SERVICE_URL, PROVIDERS_URL, and RUNNER_SERVICE_URL all need https:// values. Set NANGO_RUNNER_URL_SCHEME=https so runner URLs generated at runtime match.
• Setting a cert without a key (or the reverse), setting both the inline and _FILE form of the same asset, pointing _FILE at an unreadable path, or supplying a wrong passphrase or a mismatched cert/key pair all fail at startup rather than silently falling back to plain TLS.
• NANGO_INTERNAL_TLS_KEY_PASSPHRASE is used exactly as given, including any leading or trailing whitespace, since that whitespace may be part of the passphrase. Surrounding whitespace is stripped from the other variables, where it is never significant.
• Prefer ECDSA P-256 over RSA-2048. The per-handshake signature is roughly an order of magnitude cheaper, which matters on the jobs-to-runner path.
• Certificates are read once at startup, including _FILE paths. Rotation requires a restart.

CLI access through public mTLSCopy Anchor Link

Internal mTLS only covers service-to-service calls. If the load balancer in front of the public API also requires a client certificate, the Tenklo CLI needs its own cert or nango deploy, dryrun, and pull will fail.

Set these in the nango-integrations/.env file (or the environment that runs the CLI):

NANGO_CLI_TLS_CERT=/path/to/client.pem

A PEM that contains both the certificate and private key is enough. Use a separate key or CA when the files are split:

NANGO_CLI_TLS_CERT=/path/to/client.crt
NANGO_CLI_TLS_KEY=/path/to/client.key
NANGO_CLI_TLS_CA=/path/to/ca.pem
NANGO_CLI_TLS_KEY_PASSPHRASE=

NANGO_CLI_TLS_CA is only needed when the public API uses a private CA. Set NANGO_CLI_TLS_KEY_PASSPHRASE if the private key is encrypted. These variables are independent of NANGO_INTERNAL_TLS_*.

Internal service authCopy Anchor Link

Orchestrator, jobs, and runner HTTP APIs accept an Authorization: Bearer credential except GET /health, which stays open for probes. Enforcement is off until you set NANGO_INTERNAL_AUTH_REQUIRED=true. Shipping the image with no new variables is a no-op.

New tokens are EdDSA JWTs with the same shape on every hop. The kid header selects the verifying key. Service tokens are minted by the caller (iss and sub are service:jobs or service:server) and last 5 minutes. Jobs mints sub: task:<id> or node:<id> for two hops: jobs → runner uses aud: runner and lasts 5 minutes; the runner carries aud: jobs back, where a task token lasts 25 hours by default, or the task lifetime, and a node token lasts a year. Runners never receive a private key.

Until you set a private key, callers keep minting the previous credentials, and every receiver still accepts them:

• Static bearer (NANGO_INTERNAL_AUTH_TOKEN): server and jobs calling orchestrator.
• Task and node HMAC JWTs (NANGO_INTERNAL_AUTH_SIGNING_KEY): runner calls back to jobs. Task tokens last 25 hours by default, or the task lifetime. Node tokens last a year.
• Derived Ed25519 dispatch JWTs: jobs calls the runner. The private key is derived from the HMAC signing key and never leaves jobs.

Set the new keys in this order so a rolling deploy keeps accepting in-flight tokens:

1. Deploy server, jobs, and orchestrator. Runners pick up the new image the next time jobs starts them.
2. Set the public keys, and do not set private keys yet. Set NANGO_INTERNAL_AUTH_JOBS_PUBLIC_KEYS on orchestrator and jobs, and NANGO_INTERNAL_AUTH_SERVER_PUBLIC_KEYS on the server and orchestrator. Jobs copies the jobs public keys onto new runners and still injects the legacy derived public key.
3. Recycle runners so every live runner can verify both shapes.
4. Set the server private key, then the jobs private key. Jobs then mints service and workload JWTs. In-flight HMAC task tokens (up to 25 hours) and node tokens on runners that have not been recycled still verify.

To rotate a key, append the new entry to the public-key JSON array and deploy the verifiers before you switch the minter's key id and private key.

NANGO_INTERNAL_AUTH_JOBS_PUBLIC_KEYS: |
  [
    {
      "kid": "jobs-2026-09",
      "publicKey": "<base64url of the raw 32-byte key>"
    },
    {
      "kid": "jobs-2026-10",
      "publicKey": "<base64url of the next key>"
    }
  ]

Custom websockets pathCopy Anchor Link

The Tenklo server serves websockets from / by default for use by @nangohq/frontend during the login flow.

To isolate websockets from the dashboard, set NANGO_SERVER_WEBSOCKETS_PATH:

NANGO_SERVER_WEBSOCKETS_PATH=</YOUR-WEBSOCKETS-PATH>

If you set a custom path, configure websocketsPath when initializing the Nango object in the @nangohq/frontend SDK:

import Nango from '@nangohq/frontend';

let nango = new Nango({ host: 'https://<YOUR-NANGO-INSTANCE>', websocketsPath: '</YOUR-WEBSOCKETS-PATH>' });

Connect UI discovers the custom path on its own (from the connect session), so websocketsPath only needs to be configured for direct nango.auth() calls. If Tenklo is served behind a reverse proxy under a sub-path, direct nango.auth() needs the full public path in websocketsPath (e.g. /<API-BASE-PATH></YOUR-WEBSOCKETS-PATH>) because the SDK resolves it from the origin, while Connect UI composes the public path automatically from the apiURL base path and NANGO_SERVER_WEBSOCKETS_PATH.

Proxy timeoutsCopy Anchor Link

Both apply to the API and to runners, and are passed to Kubernetes and Lambda runners automatically.

TelemetryCopy Anchor Link

Self-hosted instances do not automatically send telemetry back to Tenklo. Operational metrics and logs stay within your own infrastructure and are only exported if you configure the OpenTelemetry Export add-on.

LogsCopy Anchor Link

Tenklo stores execution logs and powers the logs UI with either Elasticsearch or OpenSearch. To keep lightweight deployments lighter, this stack is optional.

To enable logs:

• Host an Elasticsearch or OpenSearch cluster.
• Set NANGO_LOGS_ENABLED=true.
• Configure the relevant NANGO_LOGS_ES_* environment variables (these apply to both providers).

Tenklo uses Elasticsearch by default. To use OpenSearch instead, set:

NANGO_LOGS_PROVIDER=opensearch

Elasticsearch hosting options include:

• Local: uncomment the service in docker-compose.yaml and run docker-compose up.
• Elastic Cloud: use elastic.co.
• Render: deploy an Elasticsearch instance with Render.

If NANGO_LOGS_ENABLED is false, logs are sent to stdout and can be viewed in your host logs.

FAQCopy Anchor Link