JobSync: A Self-Hosted Job Tracker With an AI Panel Bolted to the Side
Self-hosted, open-source job application tracker and AI-powered career assistant. Helps job seekers manage their search journey with AI resume review, job matching, task logging, and application analytics, all while keeping your data private.
At a glance
- What is it?
- JobSync is an MIT-licensed TypeScript application that tracks job applications, stores resumes, and runs AI resume reviews and job matching through Ollama or a cloud provider. The interesting part is not the tracker; it is the deliberately narrow scope of what the assistant is allowed to read.
- Who is it for?
- Adopt JobSync if you are running Docker on a machine you control and you want your resume and application history to stay there, and if you are willing to set up a tool-calling model before the assistant panel is useful. Do not adopt it if you want a hosted service with no server to maintain, or if you expect the AI to reason across your whole job history: the assistant reads your resumes and the single job on screen, and the README says it cannot list or search your jobs.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem JobSync Picks, and Who It Is Aimed At
A job search generates a specific kind of mess. Applications live in a spreadsheet, resumes live in five files named with dates, cover letters live in a documents folder, and the notes about which recruiter said what live in your head. JobSync's answer is to put the tracker, the resume store, and the writing assistance in one self-hosted application. The README frames it as a companion for the job search: track applications, manage and export resumes, and ask a built-in assistant to review a resume, match it against a job, write a cover letter, or add a job from a posting you paste in. The privacy claim is the differentiator. The data stays on your own server, and the AI features can run entirely locally through Ollama or through a cloud provider of your choice. That combination is aimed at a specific reader: someone comfortable running Docker, likely already self-hosting other services, who does not want their employment history sitting in a third party's database. If you have never opened a terminal, the quick start is short but it is still a terminal.
What the Assistant Can Actually See, and Why That Is the Design
The AI assistant is a chat panel that docks beside the current page rather than replacing it, so the job or resume you were looking at stays visible while the assistant works. You open it from the AI Assistant button in the header, or the app opens it for you: the Review button on a resume and the Match with AI and Cover Letter buttons on a job all start the request in the panel. The outputs are saved to the object they describe. A resume review is stored on the resume, a job match is stored on the job, and a cover letter lands in your documents with the previous one kept, so asking again produces a new letter rather than overwriting the old one. The constraint is the part worth reading twice. The README states the assistant reads your resumes and the single job you are looking at, and nothing else. It cannot list or search your jobs, and it cannot see tasks or activities. Pasted postings are treated as untrusted text, so instructions embedded in a posting cannot make the assistant act on your data. That is a real security decision, and it costs capability: you cannot ask the assistant which of your applications have gone quiet, because it has no view of the application list at all.
How It Runs: Docker Compose, Two Environment Variables, One Port
The quick start assumes Docker is installed and running. Clone the repository, change into it, and bring up the stack:
git clone https://github.com/Gsync/jobsync.git cd jobsync docker compose up
The README notes that the first startup builds the app image, which can take a few minutes, and warns that the app may be unreachable immediately after the command returns. The interface is then at http://localhost:3737, where you create your account. Two environment variables are documented for docker-compose.yml. TZ takes a value such as America/Edmonton, and the README explicitly says to set it on remote servers to avoid activity time shifts. AUTH_SECRET is auto-generated if you leave it out, or you can produce one with openssl rand -base64 32. API keys for AI providers are configured in Settings after you sign in, and the model selection lives under Settings > AI Settings. There is a live demo at demo.jobsync.ca if you want to look before building anything.
Updating, and the Homelab Detail That Breaks Things
The documented update path is a script rather than a git pull. From the project directory:
curl -fsSL https://raw.githubusercontent.com/Gsync/jobsync/main/deploy.sh | sudo bash -s
On Windows the README directs you to .\deploy.ps1 instead, noting that deploy.sh needs WSL or Git Bash while the PowerShell script runs natively. Piping a remote script into sudo bash is convenient and also means you are executing whatever is on main at that moment, which is a trade-off worth naming rather than glossing. The second operational detail matters more in practice: if you are updating in a homelab environment, you must edit NEXTAUTH_URL in your .env file to use your server IP address instead of localhost, with .env.example showing the expected format. Skip that and the app will be reachable but the auth URL will point at the wrong host. Release cadence is visible in the material: v1.1.19 on 2026-09-06, v1.1.18 on 2026-08-23, v1.1.17 on 2026-08-17. The patch-level versioning and the roughly two-week spacing suggest incremental fixes rather than large migrations, but nothing in the supplied material describes a database migration path or a rollback procedure, so treat upgrade safety as unverified.
Automated Discovery and the MCP Server
Two features extend JobSync past manual entry. Automated job discovery schedules automations that track companies through job board APIs, then AI-matches each listing against your resume and surfaces the best fits for review. The README points to a Features in Detail section for the specifics, and the supplied excerpt does not include that section, so the scheduling syntax and the supported job board APIs cannot be confirmed here. The second is the built-in MCP server, which lets agents such as Claude Desktop add job applications and Question Bank entries from a chat, with your approval. The README adds a conditional: when a job description is substantial enough, the agent can also analyze it against your default resume and save a match score from the chat. Both features share the same confirmation pattern as the in-app assistant, where nothing is written until you approve it on a card. That pattern is the strongest thing in the design, because it keeps the model in a proposing role rather than a writing one.
Where JobSync Is the Wrong Tool
The assistant needs a model that supports tool calling, and the README says it will tell you rather than guess if none is configured. That means a local Ollama setup with a small model that cannot call tools is not a degraded experience, it is a non-functional one, and the model choice is a prerequisite rather than a preference. The narrow context window is the second limit. Because the assistant sees resumes and one job at a time, questions that span your search (which companies have not replied, which resume variant performs better) are outside what it can answer, even though the dashboard and analytics pages may show that data to you. Third, this is a single-user self-hosted application. The README describes creating your account after first launch, and nothing in the material describes multi-user roles, shared workspaces, or team permissions. If two people need to share one tracker, that is not a configuration you can reach from what is documented.
What It Is Not: A Spreadsheet, and a Note on the Licence
The honest alternative for most people reading this is the spreadsheet they already have, plus a text editor for cover letters. A spreadsheet costs nothing to run, needs no server, and lets you sort and filter across every application you have ever filed. JobSync's advantage is not that it stores rows better. It is that the resume store, the PDF export with the Simple and Professional templates, the PDF and .docx import that extracts contact info, experience, education and certifications for you to review and save section by section, and the assistant all read from the same data. The moment you want the model to score a resume against a specific posting, the spreadsheet stops being able to help and the maintenance cost of a Docker host starts to look reasonable. The licence is MIT, which permits commercial and private use and modification; the repository ships a LICENSE file. That is a factual description of the licence identifier, not legal advice, and if you plan to redistribute a modified version you should read the file yourself.
Who Should Install This, and What to Check First
Install it if you already run Docker for other services, you are comfortable editing a compose file, and you specifically want your resume and application history on your own hardware. The two-variable configuration is genuinely small, and the confirmation-before-write pattern in both the chat panel and the MCP server means the model never silently modifies your records. Skip it if you want a hosted product with no server to patch, or if you need shared access for a partner or a coach, since no multi-user model appears in the documentation. Before you commit, verify that your chosen provider or local model supports tool calling, because the assistant panel is inert without one. Set TZ on any remote host. And on a homelab box, fix NEXTAUTH_URL in .env to your server address rather than localhost before you update, since the README calls that out as the step people miss.
Editorial conclusion
Adopt JobSync if you are running Docker on a machine you control and you want your resume and application history to stay there, and if you are willing to set up a tool-calling model before the assistant panel is useful. Do not adopt it if you want a hosted service with no server to maintain, or if you expect the AI to reason across your whole job history: the assistant reads your resumes and the single job on screen, and the README says it cannot list or search your jobs. Before committing, verify three things: that your chosen model supports tool calling, that TZ is set correctly on a remote host so activity timestamps do not shift, and that the deploy script's rebuild path fits your update habits.
Community notes