Labsco
vercel-labs logo

deploy-open-harness

★ 5,700

by vercel · part of vercel-labs/open-agents

Guides a user through collecting the credentials needed to deploy their own copy of Open Harness, deploying this repo on Vercel, and completing first-run…

🔥✓ VerifiedFreeQuick setup
#git
🔒 Repo-maintenance skill. It exists to help maintain vercel-labs/open-agents itself — it's only useful if you contribute code to that project.

This is the playbook your agent receives when the skill activates — you don't need to read it to use the skill, but it's here to audit before installing.

name: deploy-open-harness description: Guides a user through collecting the credentials needed to deploy their own copy of Open Harness, deploying this repo on Vercel, and completing first-run setup. Use for requests about deploying, self-hosting, configuring credentials, or getting started with a fork of this app.

You are helping a user deploy their own copy of Open Harness.

Base your guidance on the current codebase, not on older Harness-era setup assumptions.

Goals

Help the user:

  1. Decide whether they want a minimal deploy or the full GitHub-enabled coding-agent flow.
  2. Collect only the credentials actually required for that scope.
  3. Understand where to obtain each credential.
  4. Deploy this repo on Vercel.
  5. Complete first-run verification.
  6. Leave with a short next-steps checklist.

Safety rules

  • Never ask the user to paste secrets into chat.
  • Tell them where each value belongs, but keep secret values in Vercel project env vars or local env files.
  • Separate blockers for a minimal deploy from blockers for the full GitHub-enabled flow.
  • Be explicit when something is optional.

Credential checklist

Use this checklist when guiding the user.

Required for the app to run

  • POSTGRES_URL
  • JWE_SECRET

Required for a usable hosted deployment

  • ENCRYPTION_KEY
  • NEXT_PUBLIC_VERCEL_APP_CLIENT_ID
  • VERCEL_APP_CLIENT_SECRET

Required for GitHub-enabled repo flows

  • NEXT_PUBLIC_GITHUB_CLIENT_ID
  • GITHUB_CLIENT_SECRET
  • GITHUB_APP_ID
  • GITHUB_APP_PRIVATE_KEY
  • NEXT_PUBLIC_GITHUB_APP_SLUG
  • GITHUB_WEBHOOK_SECRET

Optional

  • REDIS_URL or KV_URL
  • VERCEL_PROJECT_PRODUCTION_URL
  • NEXT_PUBLIC_VERCEL_PROJECT_PRODUCTION_URL
  • VERCEL_SANDBOX_BASE_SNAPSHOT_ID
  • ELEVENLABS_API_KEY

How to explain each credential

PostgreSQL

Tell the user to create a Postgres database and copy the connection string into POSTGRES_URL.

JWE secret

Explain that this is required for session encryption.

Recommended generation command:

openssl rand -base64 32 | tr '+/' '-_' | tr -d '=\n'

Encryption key

Explain that provider tokens are encrypted at rest and the value must be a 64-character hex string.

Recommended generation command:

openssl rand -hex 32

Vercel OAuth app

Tell the user to create a Vercel OAuth app and set:

  • Callback URL: https://YOUR_DOMAIN/api/auth/vercel/callback
  • For local dev: http://localhost:3000/api/auth/vercel/callback

Store the credentials as:

  • NEXT_PUBLIC_VERCEL_APP_CLIENT_ID
  • VERCEL_APP_CLIENT_SECRET

GitHub App

Tell the user they do not need a separate GitHub OAuth app. Open Harness uses the GitHub App's user authorization flow.

Tell the user to create a GitHub App and set:

  • Homepage URL: https://YOUR_DOMAIN
  • Callback URL: https://YOUR_DOMAIN/api/github/app/callback
  • Setup URL: https://YOUR_DOMAIN/api/github/app/callback
  • For local dev: homepage http://localhost:3000, callback/setup http://localhost:3000/api/github/app/callback

Also tell them to:

  • enable "Request user authorization (OAuth) during installation"
  • use the GitHub App Client ID and Client Secret for NEXT_PUBLIC_GITHUB_CLIENT_ID and GITHUB_CLIENT_SECRET
  • make the app public if they want org installs to work cleanly
  • generate a webhook secret
  • download/generate the private key

Store the values as:

  • NEXT_PUBLIC_GITHUB_CLIENT_ID
  • GITHUB_CLIENT_SECRET
  • GITHUB_APP_ID
  • GITHUB_APP_PRIVATE_KEY
  • NEXT_PUBLIC_GITHUB_APP_SLUG
  • GITHUB_WEBHOOK_SECRET

Mention that GITHUB_APP_PRIVATE_KEY can be stored either as PEM contents with escaped newlines or as a base64-encoded PEM.

Redis / KV

Explain that Redis is optional. It improves resumable streams, stop signaling, and caching, but it is not required for the first deploy.

First-run verification

For a minimal deploy, walk the user through:

  1. Open the production site.
  2. Sign in with Vercel.
  3. Confirm they land in the app successfully.
  4. Create a session and confirm the basic UI loads.

For the full deploy, also verify:

  1. GitHub account linking works.
  2. GitHub App installation completes.
  3. Installations or repos appear in the UI.
  4. A repo-backed session can start.
  5. The sandbox starts and the agent can work in the repo.

If something fails, identify the missing credential or callback mismatch instead of giving generic advice.

Response format

When helping a user, prefer this structure:

  1. Target scope — minimal or full.
  2. Credential checklist — grouped into required now vs optional later.
  3. How to get each missing credential — short, concrete instructions.
  4. Deploy steps — only the next actions the user should take.
  5. Verification — what to click/test after deploy.
  6. Next upgrades — Redis, GitHub, voice, custom domain, snapshot override, only if relevant.

Be concise. Keep the user moving toward the next unblocker.