Deploy Harvey
AI sales dashboard for prospecting, outreach, and reply review
Just deployed
/app/data
Deploy and Host Harvey on Railway
Harvey is an autonomous sales workspace that discovers prospects, organizes company signals, drafts personalized outreach, and manages replies. Its browser dashboard brings pipeline review, approval queues, discovery tools, and usage visibility together. This single-container deployment provides a protected dashboard and persistent SQLite storage, ready for your own sales configuration.
About Hosting Harvey on Railway
Railway runs one prebuilt Docker image with HTTPS on port 5555 and a volume at /app/data. No PostgreSQL, Redis, source build, or separate frontend is required. The dashboard launches immediately; autonomous sales tasks require your own provider authentication, product training, and mailbox setup. The custom image derives from Harvey upstream at commit f851026f876dad9ea665f2164b5ef73d01432349.
Tech Stack
- Python 3.12, FastAPI, and Uvicorn
- SQLite with asynchronous access
- HTML, CSS, and JavaScript dashboard
- Playwright and Chromium
- Claude Code CLI for subscription-backed model calls
Why Deploy Harvey on Railway
Deploy a private sales workspace without maintaining a server. Railway supplies HTTPS, generated secrets, restart controls, logs, and persistent storage. This template uses only xiaosong233/harvey-railway:latest, with no GitHub source dependency and no Railway start-command override.
Common Use Cases
- Review sales signals and organize prospect cohorts.
- Explore discovery providers and inspect company/contact data.
- Approve outreach drafts and review conversations after configuring your mailbox.
- Host a small team's single-operator sales dashboard.
Deployment Notes
Open the generated HTTPS domain. Copy HARVEY_DASHBOARD_TOKEN from Railway Variables and paste it into the dashboard's Unlock field. Authentication is token-only; there is no initial username or password. Each deployment generates a new token; keep it private.
| Variable | Default | Purpose |
|---|---|---|
PORT | 5555 | Public routing to the dashboard/API process; keep the image's fixed port. |
HARVEY_PUBLIC_DASHBOARD | 1 | Explicitly enables public binding and same-origin HTTPS access in this custom image. |
HARVEY_DASHBOARD_TOKEN | ${{secret(64)}} | Generated bearer token; minimum 43 URL-safe characters. |
HARVEY_PUBLIC_URL | https://${{RAILWAY_PUBLIC_DOMAIN}} | Public dashboard URL. |
SMTP_PORT | 587 | Integer SMTP submission-port default. |
IMAP_PORT | 993 | Integer IMAP-port default. |
HUNTER_MONTHLY_SEARCHES | 25 | Optional Hunter discovery budget; requires your own Hunter key to use. |
The image adds opt-in public dashboard support, environment-token authentication, automatic volume ownership initialization, a dashboard-specific container healthcheck, and a corrected dashboard Start command. Existing bearer-token, content-type, and browser-origin protections remain active. The dashboard token is not printed in startup logs. Its initializer briefly runs as root to initialize the mount, then launches Harvey as UID 1000 with /home/harvey as its home.
Only /app/data persists: database, signals, outbox, logs, and provider token files located there. /app/.env, /app/harvey.yaml, /app/harvey.local.yaml, generated files in /app/skills, and /home/harvey/.claude are outside the volume and may be lost on redeploy. Back them up and restore them deliberately. There is one replica and one volume; do not scale SQLite horizontally.
Before starting autonomous work, connect Claude using your own subscription credentials, train your product, configure a mailbox, and confirm discovery signals. Use python -m harvey.cli inside the container because the upstream Dockerfile does not install a harvey console command. For SSH administration, run commands as the app user, for example railway ssh --service harvey -- runuser -u harvey -- python -m harvey.cli train https://your-company.example. Interactive authentication/training is user setup, not completed by this template. The upstream setup checklist may mention a missing virtualenv; Python dependencies are already installed in this image.
Provider credentials are not generated placeholders: supply real Gmail OAuth credentials (GMAIL_CLIENT_ID, GMAIL_CLIENT_SECRET), Microsoft IDs (M365_CLIENT_ID, M365_TENANT_ID), or SMTP/IMAP credentials (SMTP_HOST, SMTP_USERNAME, SMTP_PASSWORD, IMAP_HOST, IMAP_USERNAME, IMAP_PASSWORD) for your chosen provider. Select the matching provider in the YAML configuration. Other integrations are optional and configured only when used. The container ships Claude CLI only; Codex-provider support is not included. Mail sending remains approval-gated by upstream defaults; no email was sent during verification.
Verified deployment: Harvey dashboard. Retrieve the deployment-specific token from Railway Variables.
Verification covered Railway SUCCESS, clean startup, HTTP 200 for the page/assets and authenticated data APIs, real-browser token login with no JavaScript errors, 401 without a token, 403 for foreign origins, writable non-root storage, SQLite integrity, restart persistence of all 23 signals, and 218 passing dashboard-authentication tests (4 skipped). No live model generation or mailbox delivery was tested.
Dependencies for Harvey on Railway
The dashboard has no additional Railway services. Autonomous operation additionally depends on user-supplied Claude subscription authentication, a configured mail provider, and product/targeting configuration. Optional discovery and verification providers require their own accounts and credentials.
Deployment Dependencies
| Service | Image | Port | Volume |
|---|---|---|---|
| harvey | xiaosong233/harvey-railway:latest | 5555 | /app/data |
Template Content
