Build an integrations hub with Nuxt and Vercel Connect

Give your users one place to connect the third-party tools your app depends on, and act on them through their own accounts. This starter is a minimal integrations gub built with Nuxt and Vercel Connect. A user authorizes a provider over OAuth, sees its connection status, and verifies it with a one-click test. No provider secrets live in your environment, and no OAuth refresh tokens live in your database.

GitHub and Linear ship with the template, and adding another provider takes one entry in a config file. Deploy the template now, or read on for how it works.

If you work with an AI coding agent like Claude Code or Cursor, clone the template and hand off the setup with this prompt:

I want to build an integrations hub using Nuxt and Vercel Connect.

Clone the template repo at https://github.com/vercel-labs/nuxt-connect-starter, install dependencies with pnpm, then walk me through linking it to a Vercel project and pulling environment variables.

Help me create and attach the GitHub and Linear connectors with the Vercel CLI, then run the dev server and verify each integration from the hub. When searching for information, check for applicable skill(s) first and review local documentation.

Turn your agent into a Vercel expert with this plugin. It provides your coding agent with up-to-date knowledge of the Vercel products this template uses, including Vercel Connect. The plugin is optional; it's not required to use the template or for this guide.

npx plugins add vercel/vercel-plugin

• A Vercel account
• Vercel CLI installed (npm i -g vercel)
• Node.js 20+ and a package manager (e.g., pnpm)
• For the Linear connector, a Linear workspace you can authorize
• For the GitHub connector, a GitHub organization or account

Deploy the template with one click, or clone and deploy from the CLI:

git clone https://github.com/vercel-labs/nuxt-connect-starter.git
cd nuxt-connect-starter
pnpm install
vercel

To scaffold a fresh copy under your own name instead, use giget:

npx giget@latest gh:vercel-labs/nuxt-connect-starter my-connect-app
cd my-connect-app
pnpm install

Link your local directory to the Vercel project, then pull its environment variables:

vercel link
vercel env pull

vercel env pull writes a .env.local file containing a short-lived VERCEL_OIDC_TOKEN. The @vercel/connect SDK uses this token to authenticate with Vercel Connect during local development, so there is no API key to configure. Re-run vercel env pull if you see authentication errors. When you deploy to Vercel, this token is injected and refreshed for you.

The template uses two connectors: Linear as a Custom OAuth connector, and GitHub as a managed connector.

Create the Linear connector from the CLI. Vercel opens your browser to complete the Linear OAuth flow. Then attach it to the linked project:

vercel connect create mcp.linear.app --name linear
vercel connect attach mcp.linear.app/linear

Create the GitHub managed connector in the Vercel dashboard, then attach it:

vercel connect attach github/nuxt-connect-starter

Confirm your connector UIDs:

vercel connect list

Each entry in server/connectors.ts becomes one card in the hub, so the connector UID in the registry must match the connector you attached. Update it if yours differ:

connector: 'github/nuxt-connect-starter',  // GitHub
connector: 'mcp.linear.app/linear',        // Linear

Start the dev server:

pnpm dev

The server starts at http://localhost:3000. Open the hub, click Connect on a card to authorize the provider, then click Test to verify the integration works. The test makes a real API call through Connect, such as creating a Linear issue, and reports the result inline.

To set a canonical production URL for SEO, add NUXT_PUBLIC_SITE_URL in your Vercel project settings or .env.local:

NUXT_PUBLIC_SITE_URL=https://your-app.vercel.app

The hub is driven by a single config registry. Each connector is one object in server/connectors.ts, and the UI and API routes iterate that registry to render a card with connect, status, test, and revoke actions. Adding a provider means adding an entry, not wiring up new pages.

Authorization and tokens are handled by Vercel Connect rather than your own backend. When a user clicks Connect, Vercel Connect runs the provider's OAuth flow and stores the resulting grant, keyed by the connector and the subject, which is the identity you act as. The demo identifies each subject with an anonymous cookie, which you replace with your authenticated user id in production.

Your app never stores OAuth refresh tokens. It requests a fresh, short-lived token at request time instead:

User connects → Connect stores the grant keyed by (connector, subject.id)
Later → getToken() returns a short-lived token (refresh is automatic)

Because Connect holds the grant and refreshes tokens automatically, your environment holds no provider secrets, and your database holds no long-lived credentials.

The interesting parts of the template are small. Here are the pieces that matter.

server/connectors.ts is the source of truth for the hub. Each object names a connector by its UID and provides a test.run() function that exercises the integration:

connector: 'github/nuxt-connect-starter',  // GitHub
connector: 'mcp.linear.app/linear',        // Linear

One object equals one card. The UI composables (useConnectors, useConnector) and the API routes under server/api read this registry, so you do not touch component or route code to add a provider.

The Connect helpers live in server/utils/connect.ts and wrap the @vercel/connect SDK. To act on a provider, you mint a token for a specific user, then call the provider's API. This is the pattern the test route (server/api/test.post.ts) uses:

const token = await mintUserToken(connector, userId, status.installationId)
await createLinearIssue(token, body)

mintUserToken requests a short-lived token from Connect for the given connector and user. The SDK authenticates with the OIDC token from your environment, so there is no provider secret to manage. On a multi-tenant connector such as GitHub, the installationId selects which organization the token acts on.

Connections persist in Vercel Connect, so your app only needs a stable user id to mint fresh tokens. You do not store OAuth refresh tokens in your own database.

Replace the anonymous cookie in server/utils/user.ts with your authenticated user id, then reuse the token pattern from the test route. With a real user id in place, each user authorizes a provider once, and your app mints tokens that act as that user for as long as the grant is valid. The same approach works for an app-level subject when you want a bot or service account rather than a specific user.

• Vercel Connect documentation
• Vercel Connect quickstart
• Vercel Connect concepts
• @vercel/connect SDK reference
• vercel connect CLI reference
• Nuxt Connect Starter on GitHub
• Nuxt documentation
• Nuxt UI