new-term-radar
신규 AI 용어를 매일 추적, X·Hugging Face·GitHub 등에서 모델·제품·레포 이름을 빠르게 수집
nvoke는 회사를 찾아 웹사이트를 읽고 메일 서버로 모든 이메일을 검증한다
nvoke finds companies, reads their own websites and checks every email with the mail server. In your browser, nothing to install, and as nvoke Desktop for Windows, macOS and Linux.
마케팅TypeScript · CSSGitHub @Mopra온라인운영자 미확인
써 보셨어요? 한 번만 눌러 주세요. 로그인은 필요 없어요.
개인 계정의 공개 저장소 소유자는 GitHub로 로그인해 운영자를 확인하고 소개를 직접 관리할 수 있습니다. 관리자 승인은 필요하지 않습니다.
로그인한 뒤 확인 파일을 만들어 이 저장소의 기본 브랜치에 30분 안에 커밋해 주세요. 다른 브랜치나 포크의 파일은 인정하지 않습니다. 파일을 올린 뒤 아래에서 확인하면 관리자 승인 없이 관리할 수 있습니다. 자격을 유지하려면 파일을 남겨 두세요.
로그인이 필요하면 로그인 화면으로 이동합니다. 로그인 후 이곳으로 돌아와 원하는 확인 버튼을 다시 눌러 주세요.
프로젝트 폴더에서 /nomorevibe verify를 실행하면 소유권을 확인하고 소개를 직접 관리할 수 있습니다.
1분 만에 확인하기메이커가 쓴 소개는 위의 한 줄이 전부입니다. 더 자세한 내용은 저장소 README에서 읽을 수 있습니다. 저장소 README ↗
README 전체를 불러오는 중입니다.
README 전문 보기 ↗A lead finder: a prospecting research tool. Users find companies and the contact details they publish on their own websites, in the web app at nvoke.run/app (nothing to install) or in nvoke Desktop, the native app with the power tools. The research runs on a Node backend on a VPS.
apps/
desktop/ Electron app (electron-vite, React, Tailwind v4, shadcn/ui)
server/ Fastify API and a separate worker process, Postgres via postgres.js
site/ Next.js: marketing site and the web app at /app (Vercel, root directory apps/site)
packages/
shared/ zod schemas and types shared by desktop and server
theme/ theme.css with the shadcn tokens used by desktop and site
deploy/ systemd units for the API and worker on the VPS
.github/
workflows/ ci.yml (typecheck, lint, test, build; Postgres service for the
database tests) and release.yml (installers on tag)
Node 24 and pnpm 10 (corepack enable picks up the pinned version).
pnpm install
cp apps/server/.env.example apps/server/.env # fill in Clerk keys, DATABASE_URL
cp apps/desktop/.env.example apps/desktop/.env # VITE_API_URL, VITE_SITE_URL
cp apps/site/.env.example apps/site/.env.local # Clerk keys, NEXT_PUBLIC_API_URL
pnpm migrate # applies apps/server/migrations to DATABASE_URL
pnpm dev:api # API on http://localhost:3000, GET /health
pnpm dev:worker # worker process
pnpm dev:desktop # Electron app with hot reload
pnpm dev:site # site on http://localhost:3001
The API boots without a database or Clerk keys, so /health works on a clean
checkout. Routes behind auth answer 503 until CLERK_SECRET_KEY is set.
apps/site serves the web app at /app (Clerk sign-in, then the same /v1
API the desktop app uses, called from the browser with the Clerk session
JWT). Run pnpm dev:api, pnpm dev:worker and pnpm dev:site, then open
http://localhost:3001/app. The API must allow the site origin in
CORS_ORIGINS. Details in CLAUDE.md, "Web app".
Sign in opens the site's /desktop/sign-in page in the system browser. After
Clerk sign-in the page hands a one-time code back to the app through
nvoke://auth/callback, and the app trades it (with a PKCE verifier) for a
device token that it keeps encrypted on disk. Run the API and the site
alongside the desktop app to try it locally. Details in CLAUDE.md.
| Command | What it does |
|---|---|
pnpm typecheck | tsc --noEmit in every package |
pnpm lint | ESLint plus the punctuation check |
pnpm test | Vitest across the workspace |
pnpm build | Builds shared, server (dist/), desktop (out/) and site (.next/) |
pnpm migrate | Applies apps/server/migrations/*.sql to DATABASE_URL |
pnpm dist:desktop | Builds an installer for the current OS into apps/desktop/release/ |
The worker runs searches as Postgres jobs (find, then crawl per company,
then verify per email). See docs/SPEC.md for the behaviour and
apps/server/.env.example for the settings.
src/leads: source adapters (sources/), crawler, robots.txt, email
extraction, verifier (verify/), quotas, CSV and the queries behind the API.src/worker: the job queue (FOR UPDATE SKIP LOCKED), handlers and runner.src/api/routes/leads.ts: the /v1 routes. The auth preHandler
(src/api/auth.ts, device token or Clerk JWT) sets request.userId and
creates the account; the routes guard with requireUser (src/api/user.ts).To run the API, worker, site and desktop app together against a local
database, start one with pnpm --filter @nvoke/server cli db (embedded
Postgres in apps/server/.pgdata, migrations applied, URL printed), put that
URL in DATABASE_URL in apps/server/.env, then run pnpm dev:api,
pnpm dev:worker, pnpm dev:site and pnpm dev:desktop.
Try a search end to end against a local database (never the shared one):
pnpm --filter @nvoke/server cli search local "dentists" "Copenhagen" --limit 5
pnpm --filter @nvoke/server cli search launches "email" --days 3 --limit 10 --no-smtp
The CLI starts an embedded Postgres with its data in apps/server/.pgdata
(the embedded-postgres package ships real Postgres binaries, so no Docker
is needed, Windows included) and applies the migrations to it.
Tests do the same in a temp directory: pnpm test starts one Postgres, builds
a template database with all migrations, and gives every database test file
its own copy. Set TEST_DATABASE_URL to use an existing Postgres instead.
/opt/nvoke. No Docker.
See deploy/README.md.apps/site.deploy/README.md.Bump apps/desktop/package.json version, then push a tag such as v0.1.0.
The release workflow builds an NSIS installer (Windows), a dmg (macOS) and an
AppImage (Linux) and attaches them to a GitHub Release. Builds are not code
signed yet.