freehire:聚合320个来源的开源求职搜索引擎
给求职者用的开源职位搜索引擎,抓原始ATS职位并去重,不只是聚合招聘网站。
GitHub strelov1/freehire 更新 2026-10-22 分支 main 星标 2.4K 分叉 244
Go SvelteKit 2 PostgreSQL Meilisearch pgvector 求职搜索 Docker Compose MIT License

🧭 决策指南

适合,如果你

  • 你要用Go、PostgreSQL和Meilisearch搭建可自托管的职位目录。
    README 的“Why freehire?”和“Stack”章节说明项目采用Go、PostgreSQL、Meilisearch,并支持self-hostable部署。
  • 你需要从Workday、Greenhouse或Lever抓取原始职位并合并转载。
    README 的“Why freehire?”章节列出Workday、Greenhouse、Lever等ATS,并说明使用稳定键去重。
  • 你希望通过无密钥HTTP API读取职位数据。
    README 的“API”章节明确写出GET https://freehire.me/api/v1/jobs needs no credential。
  • 你要把职位抓取、LLM enrichment和Meilisearch索引拆成定时worker。
    README 的“Workers”章节说明crawler、enrichment、indexing和notifications均为run-once worker。

不适合,如果你

  • 你只想运行一个不依赖PostgreSQL、Redis和Meilisearch的单体程序。
    README 的“Quick start”和“Stack”章节要求Docker Compose启动api、web、postgres、meilisearch、redis和s3。
  • 你的环境无法提供Docker Compose或持久化Postgres卷。
    README 的“Quick start”使用make up构建Docker整套服务,并将migrations挂载到Postgres初始化目录。
  • 你需要在没有LLM配置的情况下运行enrich或Telegram职位提取。
    README 的“Workers”章节说明go run ./cmd/enrich needs LLM_* config,tg-extract也使用LLM-extract。

前置条件

  • README 的“Quick start”要求使用Docker Compose,并提供make up启动整套服务。
  • README 的“Local development”明确写出JWT_SECRET is required for the server to start。
  • 每个worker都需要DATABASE_URL,并会在失败时以非零状态退出。
  • 运行enrich需要LLM_*配置;OAuth和LLM credentials未设置时对应功能保持禁用。
  • README 的“Quick start”默认使用8080端口,也提供HIRE_HOST_PORT=8090 make up切换端口。

第一步命令(README 原文)

make up        # build + start the whole stack in Docker:

要注意

  • 修改已有迁移后,必须重建Postgres卷或执行make migrate。
    README 的“Quick start”说明changing a migration does not re-apply to an existing volume。
  • make reindex会从Postgres重建完整Meilisearch索引。
    README 的“Commands”将make reindex定义为rebuild the Meilisearch index from Postgres。
  • worker不硬删除职位,只执行soft-close生命周期。
    README 的“Workers”章节明确写出No worker hard-deletes jobs。

替代方案

  • freehire.me hosted site:不想本地部署Docker Compose整套api、web、Postgres和Meilisearch时,直接使用README提到的hosted site。
    Why freehire?

材料未说明

  • README没有说明Docker Compose整套服务的最低CPU、内存和磁盘要求。
  • README没有给出337万条职位的抓取周期、更新延迟或单次worker处理时长。
  • README没有说明Meilisearch在3.3M+职位规模下的索引容量和查询性能。
  • README没有说明Go、PostgreSQL、Redis、Docker Compose及S3兼容存储的最低版本。
  • README没有说明10位贡献者对应的维护分工和生产支持承诺。

💡 深度解析

6
适合 我正在用 Claude Desktop 或 Claude Code 接入职位搜索,希望通过 MCP 调用 freehire,同时不维护 API key 鉴权;这个项目能直接满足我的集成约束吗?
适合读者: 正在为 Claude Desktop 或 Claude Code 接入职位数据、希望避免自建鉴权服务的 AI 工具开发者

适合,README 同时提供 MCP server 和无密钥公开职位 API,正好覆盖 Claude Desktop 与 Claude Code 的接入方式。

  • Beyond the catalogue 直接列出 MCP server,目标客户端包括 Claude Desktop 和 Claude Code。
  • API 章节说明目录通过公开、无 key 的 HTTP API 提供,GET https://freehire.me/api/v1/jobs 不需要凭据,适合先验证数据访问。
  • API 响应格式固定为 data、meta 或 error,职位和公司通过 public slug 访问,降低了客户端解析复杂度。
  • 但无密钥不等于无限制:项目洞察指出公开 API 仍需关注限流、缓存、服务稳定性以及职位数据的使用许可;README 没有给出 MCP 工具清单、调用配额或错误重试策略。

所以,作为 Claude 工具的数据入口是合适的;如果你需要稳定配额、私有职位目录或严格的企业级 SLA,现有 README 信息还不足以确认。

  • Beyond the catalogue:A keyless public API、an MCP server for Claude Desktop and Claude Code
  • API:`GET https://freehire.me/api/v1/jobs` needs no credential
  • API:All responses use `{"data": ...}`、`{"data": ..., "meta": {...}}` or `{"error": msg}`
curl localhost:8080/api/v1/jobs
材料未说明:README 未列出 MCP server 的具体工具名称、参数和分页行为。;README 未说明公开 API 的请求配额、限流阈值和服务等级。
适合 我主要找远程 IT 职位,需要跨 124 个 ATS 和 97 个 Telegram 渠道搜索,并用保存搜索、摘要和申请看板跟踪结果;freehire 能覆盖这条工作流吗?
适合读者: 每天处理大量远程 IT 职位、希望用保存搜索、Telegram 摘要和申请看板减少重复操作的高频求职者兼自动化开发者

适合,freehire 覆盖从远程职位发现到申请跟踪的连续流程,但职位状态和结构化字段仍不能替代原始招聘页面核验。

  • README 宣称聚合 3.3M+ unique live postings,覆盖 124 ATS platforms、97 Telegram channels 和 320 sources,满足跨来源检索的规模约束。
  • 搜索支持 region、work mode、seniority、skills 和 salary 的分面全文检索,且字段来自 curated dictionaries,而不是直接猜测。
  • Beyond the catalogue 列出 saved searches with email/Telegram digests、shared boards、application board、mail inbox 关联、事件账本和 reminders,覆盖发现、提醒与进度管理。
  • 项目洞察指出职位采用软关闭和周期性抓取,状态可能延迟;薪资、技能、工作模式和资历也可能缺失,提交申请前仍要回到原始公司页面确认。

因此,它适合作为高频求职工作台和自动化数据入口;如果你的要求是保证每个远程岗位实时有效或字段完整,README 无法承诺。

  • Why freehire?:3.3M+ unique live postings、124 ATS platforms、97 Telegram channels、320 sources
  • Why freehire?:Faceted full-text search over region, work mode, seniority, skills and salary
  • Beyond the catalogue:saved searches with email/Telegram digests、application board、mail inbox、reminders
  • 项目洞察:职位关闭采用软关闭和周期性抓取;结构化字段可能缺失
curl localhost:8080/api/v1/jobs
材料未说明:README 未说明远程职位在不同国家、语言和行业中的覆盖比例。;README 未给出 Telegram 摘要的配置步骤、发送频率和失败重试行为。
视情况 我想自托管 freehire 的 3.3M+ 职位目录,并用 Docker Compose 同时运行 PostgreSQL、Meilisearch、Redis 和 S3;它适合做我的完整职位搜索基础设施吗?
适合读者: 需要自托管 3.3M+ 职位目录、使用 Docker Compose 管理 PostgreSQL、Meilisearch、Redis 和 S3 兼容存储的个人开发者

视情况,项目提供完整自托管栈,但运行 3.3M+ 职位目录并不是轻量级单体部署。

  • README 的 Quick start 明确支持 make up,会启动 api、web、postgres、meilisearch、redis 和 s3,适合快速验证完整链路。
  • Stack 章节说明 PostgreSQL/pgvector 负责存储和向量,Meilisearch 负责全文与分面搜索,Redis 负责限流和实时分发,S3 负责简历等文件;这些组件都需要一起运维。
  • 项目数据称目录覆盖 3.3M+ unique live postings、470,000+ companies 和 320 sources,重建索引或运行完整管道会带来明显存储与计算需求。
  • README 还说明迁移变更不会自动作用于已有卷,错误执行 docker compose down -v 可能删除现有数据。

因此,它适合有容器、数据库和索引运维能力的自托管者;若只是需要少量职位查询,完整栈可能过重。

  • Quick start:`make up # build + start the whole stack in Docker`
  • Stack:PostgreSQL + pgvector、Meilisearch、Redis、S3-compatible object storage、Docker Compose
  • Why freehire?:Aggregating 3.3M+ unique live postings from 470,000+ companies、320 sources
  • Quick start:Changing a migration does not re-apply to an existing volume
make up
材料未说明:README 未给出运行 3.3M+ 职位目录所需的 CPU、内存、磁盘和索引耗时。;README 未说明完整目录的数据库、向量和 Meilisearch 索引实际占用量。
适合 我需要为简历适配、职位匹配和面试演练接入 OpenAI 兼容模型,并希望有跨供应商回退和调用追踪;freehire 是否符合这个 LLM 架构约束?
适合读者: 使用 OpenAI 兼容端点、希望在 langchaingo、Bifrost 和 Langfuse 之间切换模型供应商的 AI 功能开发者

适合,项目的 LLM 接入层明确围绕 OpenAI 兼容端点、供应商回退和调用观测设计,但具体模型质量与成本仍取决于你的端点配置。

  • Stack 章节写明 langchaingo 通过任意 OpenAI-compatible endpoint 访问 LLM,没有把应用绑定到单一厂商。
  • Bifrost 提供 per-user virtual keys、cross-provider fallback 和 spend tracking,适合同时管理多个模型供应商与预算。
  • Langfuse 用于 LLM call tracing and observability,可追踪调用链路,而 README 的功能表还列出 AI fit analysis、CV tailoring 和 interview rehearsal。
  • OAuth 与 LLM 凭据是可选项;未配置时,README 说明由这些凭据控制的功能会保持禁用。

因此,架构层面满足你的约束;但 README 没有给出支持的具体模型、各功能的 token 消耗、延迟、质量阈值或回退触发条件,不能据此保证某个模型能胜任简历生成。

  • Stack:langchaingo — LLM access over any OpenAI-compatible endpoint
  • Stack:Bifrost — per-user virtual keys, cross-provider fallback, spend tracking
  • Stack:Langfuse — LLM call tracing and observability
  • Local development:OAuth and LLM credentials are optional;the features they gate stay disabled when unset
make up
材料未说明:README 未列出已验证的模型名称、上下文窗口和各功能的调用成本。;README 未说明 Bifrost 的回退条件、超时设置和模型路由配置方式。
适合 我需要把 Workday、Greenhouse 或 Lever 接入 freehire,并坚持用 Go 和 sqlc 维护类型安全查询;新增来源的扩展路径是否符合我的约束?
适合读者: 想把 Workday、Greenhouse 或 Lever 职位接入统一目录、主要使用 Go 和 sqlc 而不引入 ORM 的数据管道开发者

适合,README 把来源采集、统一模型和 SQL 类型安全访问作为明确的架构边界,与你的 Go 与 sqlc 约束一致。

  • Why freehire? 列出 Workday、Greenhouse、Lever、Ashby 和 iCIMS 等 ATS,并说明所有职位会被标准化到一个 schema,再按 stable key 去重。
  • README 说明添加公司是 board catalog 中的一行配置,表明常见来源不必为每家公司重写整套系统。
  • Stack 章节明确使用 Go + Fiber v2 作为 HTTP server,并使用 sqlc 从 SQL 生成 type-safe DB access,且注明 no ORM。
  • 架构洞察显示采集适配器、规范化、去重和软关闭共同维护职位生命周期;但实际适配器接口、字段映射和测试要求不在给出的 README 正文中。

所以,技术方向适合扩展 ATS 来源;真正实施前仍需阅读 Adding a source、Sources 和 Workers 章节,确认某个 ATS 是否已有适配器以及需要哪些调度任务。

  • Why freehire?:Workday、Greenhouse、Lever、Ashby、iCIMS;One schema, deduplicated
  • Why freehire?:Adding a company is one row in the board catalog
  • Stack:Go + Fiber v2;sqlc — type-safe DB access from SQL (no ORM)
  • 项目洞察:来源通过适配器和目录化配置扩展;采集、富化、嵌入、索引和通知采用独立 Worker
make help
材料未说明:提供的 README 正文未包含 Adding a source、Sources 和 Workers 的具体接口、配置字段与运行命令。;README 未说明 Workday、Greenhouse 和 Lever 当前是否都已有可直接复用的适配器。
视情况 我现有前端是 SvelteKit 2、Svelte 5 runes 和 Tailwind 4,还要编译 freehire 的 web 与 extension;这个仓库能直接融入我的前端工作流吗?
适合读者: 维护 SvelteKit 2、Svelte 5 runes 和 Tailwind 4 前端,并准备同时构建 web 与浏览器扩展的前端工程师

视情况,技术栈高度匹配,但 web 和 extension 依赖仓库内的 design-system symlink,不能把它们当成两个完全独立的前端包。

  • Frontend 章节明确使用 SvelteKit 2、Svelte 5 runes、Tailwind 4 和 adapter-node,因此与你列出的版本方向一致。
  • web 是服务端渲染应用,位于 web/,并通过同源 API 消费后端;如果你的应用依赖纯客户端渲染或不同路由模型,需要额外适配。
  • README 特别说明共享 tokens 和 components 来自 sibling design-system package,构建 web/ 或 extension/ 前必须安装它,因为该包是 symlink 而不是复制品。
  • 项目数据显示 TypeScript、Svelte 和 HTML 都有实际代码,但没有说明 extension 支持的浏览器范围或发布流程。

因此,SvelteKit 生态内的前端开发者较适合直接接入;若你的 CI 不允许 symlink,或需要明确的浏览器兼容矩阵,现有资料不够。

  • Frontend:A server-rendered SvelteKit 2 app (Svelte 5 runes, Tailwind 4, adapter-node)
  • Frontend:install `design-system` before building `web/` or `extension/`, since it is symlinked, not copied
  • 项目数据:TypeScript 3,725,228;Svelte 2,712,052
make up
材料未说明:README 未提供 design-system 的安装命令或 web/extension 的独立构建命令。;README 未说明浏览器扩展支持 Chrome、Firefox 或其他浏览器的具体范围。

✨ 核心亮点

  • 320个来源聚合337万条开放职位
  • Workday等124个ATS直接抓取原始职位
  • PostgreSQL与Meilisearch支持职位筛选搜索
  • MIT许可并提供无密钥公共HTTP API
  • Docker Compose需同时运行多个基础服务

🔧 工程化

  • 用Meilisearch提供地区、技能和薪资分面搜索
  • 用稳定键去重同一职位的多站转载
  • 通过GET /api/v1/jobs提供无凭证职位API
  • worker命令覆盖抓取、嵌入和索引流程

⚠️ 风险

  • make up会启动api、web、Postgres等整套服务
  • JWT_SECRET缺失时服务器不会启动
  • enrich和embed依赖DATABASE_URL及队列配置
  • 已有Postgres卷不会自动重放迁移

👥 适合谁?

  • 需要自建Go求职数据管道的开发团队
  • 使用PostgreSQL和Meilisearch的搜索工程师
  • 希望接入CLI或MCP的求职产品开发者