Nango (self-host)

The self-host path keeps every login on your own server. You run Nango, and your logins stay in your database, on infrastructure you control. Nothing about a connection leaves your systems. This is the private option, for when you would rather hold your own keys than hand them to a managed vault.

Where your login lives

Before you connect, DorkOS shows you this:

You're connecting through your own Nango server. The keys to this connection are stored in your database, on infrastructure you control. Nothing about this connection leaves your systems.

DorkOS never stores the login tokens for a self-host connection. It holds only two things: your Nango secret key, kept in its encrypted secret store, and the address of your Nango server. The tokens themselves live in your Nango database.

Before you start

You need a running, self-hosted Nango. The free version (the Docker Compose setup) gives you what this connector uses: OAuth sign-in and a secure proxy. That is all DorkOS needs. DorkOS never uses Nango's paid features.

The one rule you cannot skip: set an encryption key

Nango only keeps your logins safe if you give it an encryption key. You must set NANGO_ENCRYPTION_KEY on your Nango server. It is a 256-bit key, written in base64. Without it, Nango stores your logins in plain text, and the "your keys stay yours" promise is not true.

Make a key like this:

openssl rand -base64 32

Set that same value in two places:

1. On your Nango server, as NANGO_ENCRYPTION_KEY, so Nango encrypts what it stores.
2. In DorkOS, as NANGO_ENCRYPTION_KEY, so DorkOS can confirm you set one.

DorkOS checks the key you give it. It must decode from base64 to exactly 32 bytes. If the key is missing or the wrong size, DorkOS refuses to start the self-host connector and tells you why. That refusal is on purpose. It stops a silent, unsafe setup where your logins would sit unencrypted. The exact reason shows on the Nango card of the Connections page, so you can fix it without reading a log file.

Point DorkOS at your Nango

Two more values:

• NANGO_BASE_URL: the address of your Nango server, for example http://localhost:3003. A malformed address fails at startup with a clear message instead of failing later.
• Your Nango secret key: open Connections in the sidebar, scroll to the Composio & Nango section, paste it into the Nango card, and click Save key. It lands in DorkOS's encrypted secret store, so it never sits in a plain config file. Saving it turns the connector on right away; no restart.

When the base URL, the secret key, and a valid NANGO_ENCRYPTION_KEY are all set, the self-host connector is on. When any of them is missing, DorkOS leaves it off and the Nango card says what is missing. Nothing breaks.

How your agent uses a self-host account

Once an account is connected and attached to a session, the agent gets one tool for it: a request tool that can call the service's API through your self-hosted Nango. Nango adds the sign-in to each request from your own database, so the agent can act for you while the keys never leave your systems. It is one honest, low-level tool per account, not a polished catalog of service-specific tools. That richer catalog may come later.

Connecting works the same as every other path: click Connect on a service, read the custody sentence, sign in through your own Nango, and the account appears with its custody marked as self-host. You can hold more than one account for the same service, and disconnect any of them.

Other ways to connect

If you want a managed setup instead, use Composio. If you already run your own tool server, point DorkOS at a raw MCP server.