vercel-labs/open-agents

deploy-open-harness

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.

First seen Apr 23, 2026

Installation

$ npx skills add vercel-labs/open-agents --skill deploy-open-harness

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from vercel-labs/open-agents · top by installs.

npx skills add vercel-labs/open-agents

Browse all from vercel-labs/open-agents

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 5.8K
License LICENSE.md
Default branch main
Open issues 34
Status Active

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 6,803 B
  • docs SUMMARY.md 304 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 101 installs

SKILL.md

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.

First rule: verify current requirements from the repo

Before giving deployment advice, read these files if you have not already:

  • README.md
  • apps/web/.env.example
  • apps/web/lib/db/client.ts
  • apps/web/lib/jwe/encrypt.ts
  • apps/web/lib/crypto.ts
  • apps/web/app/api/auth/signin/vercel/route.ts
  • apps/web/app/api/auth/vercel/callback/route.ts
  • apps/web/app/api/github/app/install/route.ts
  • apps/web/app/api/github/app/callback/route.ts
  • apps/web/lib/github/app-auth.ts
  • apps/web/lib/redis.ts
  • apps/web/lib/sandbox/config.ts

If the code and the docs disagree, trust the code and say so.

Do not rely on scripts/setup.sh.

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.

Scope the deployment first

Start by determining which path the user wants:

1) Minimal deploy

A working hosted app where the user can deploy it, sign in with Vercel, and use the product without GitHub repo access.

2) Full deploy

Everything in the minimal deploy, plus GitHub account linking, GitHub App installation, private repo access, pushes, and PR creation.

If the user is unsure, recommend minimal deploy first, then layer on GitHub.

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
  • NEXTPUBLICVERCELAPPCLIENT_ID
  • VERCELAPPCLIENT_SECRET

Required for GitHub-enabled repo flows

  • NEXTPUBLICGITHUBCLIENTID
  • GITHUBCLIENTSECRET
  • GITHUBAPPID
  • GITHUBAPPPRIVATE_KEY
  • NEXTPUBLICGITHUBAPPSLUG
  • GITHUBWEBHOOKSECRET

Optional

  • REDISURL or KVURL
  • VERCELPROJECTPRODUCTION_URL
  • NEXTPUBLICVERCELPROJECTPRODUCTION_URL
  • VERCELSANDBOXBASESNAPSHOTID
  • ELEVENLABSAPIKEY

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:

  • NEXTPUBLICVERCELAPPCLIENT_ID
  • VERCELAPPCLIENT_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 NEXTPUBLICGITHUBCLIENTID and GITHUBCLIENTSECRET
  • 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:

  • NEXTPUBLICGITHUBCLIENTID
  • GITHUBCLIENTSECRET
  • GITHUBAPPID
  • GITHUBAPPPRIVATE_KEY
  • NEXTPUBLICGITHUBAPPSLUG
  • GITHUBWEBHOOKSECRET

Mention that GITHUBAPPPRIVATE_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.

Deployment flow

Guide the user through this sequence:

  1. Fork the repo.
  2. Import it into Vercel at the repo root.
  3. Add the baseline env vars:

- POSTGRESURL - JWESECRET - ENCRYPTION_KEY

  1. Deploy once to get a stable production URL.
  2. Create the Vercel OAuth app using that production URL.
  3. Add NEXTPUBLICVERCELAPPCLIENTID and VERCELAPPCLIENTSECRET.
  4. Redeploy.
  5. If the user wants the full GitHub flow, create the GitHub App using the production URL, add the GitHub env vars, and redeploy again.
  6. Optionally add Redis/KV and the production URL vars.

If the user already has a custom domain ready, it is fine to use that domain from the start instead of the default vercel.app production URL.

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.