Self-Host JobSync with Ollama and Localtonet

What you are building, and what is verified

JobSync is an open-source job application tracker and AI-assisted workspace. Its published feature set includes application statuses and dates, companies and contacts, interview rounds and questions, tasks, activity tracking, daily goals, and resume workflows. It can import PDF or DOCX resumes, review sections, compare resumes with job postings, and help prepare cover letters. Scheduled discovery includes Greenhouse, Lever, and Ashby job boards.

The project's published quick start is to clone its repository, run Docker Compose, then open http://localhost:3737 and create an account. Its website identifies Ollama as the default AI option, with hosted-provider alternatives including OpenAI, Gemini, DeepSeek, and OpenRouter. That establishes the intended architecture, but not the exact current settings needed to connect the application container to Ollama.

This distinction matters because pinning a Git checkout does not necessarily pin the running application. A Compose file can reference a moving container tag. Record both the repository commit and the actual deployed image before treating a setup as reproducible.

The v1.1.22 release notes describe a default-model change from llama3.1 to qwen3.5:9b and the addition of AI usage reporting. Those are historical release-specific facts. They do not establish the model default or every AI reporting behavior at the later main-branch snapshot.

With Localtonet, our client establishes an outbound connection to a relay. Standard tunneling does not require inbound router port forwarding, a public IP address, or VPN setup. It is not itself a VPN. The public route works only while the selected device is connected and the tunnel is running.

Prepare the host and a disposable test environment

Use a host that can remain online when you need the application. Install Git and Docker with the Compose plugin. Docker Desktop is a common path on Windows and macOS; Docker Engine with Compose is a common Linux path. This article does not establish JobSync's complete operating-system support matrix or minimum hardware requirements.

Allow storage for application images, persistent data, model files, and backups. Model memory and disk requirements depend on the model and context size. A successful model download does not prove that the host can run the model comfortably.

git --version
docker --version
docker compose version
docker info

The first three commands check installed tools. docker info also checks access to the Docker engine. Resolve daemon or permissions errors before proceeding. Docker access is powerful; do not respond to a permissions problem by making the Docker socket publicly writable.

Use fictional job descriptions and a sample resume during setup. Do not import your only copy of important records. If the Docker host is remote, remember that localhost in your browser refers to your own computer, not that host.

Install JobSync and record the deployed revision

The JobSync project website publishes the following three-command quick start. Use a fresh directory for evaluation so an existing deployment is not overwritten.

git clone https://github.com/Gsync/jobsync.git

cd jobsync

docker compose up

Identify the source before a repeatable deployment

The quick start above follows whatever revision Git retrieves. To evaluate the source snapshot identified in this guide instead, perform the following after entering the repository and before starting Compose:

git checkout --detach 8c20325c35dbf203334a270cef5aef446f06a774
git rev-parse HEAD
git status --short
docker compose config --quiet
docker compose config --services
docker compose config --images

The checkout fixes the source files, while the subsequent commands record the commit, identify local changes, validate Compose configuration, and show configured services and images. A detached checkout is intentional here. Do not apply it casually to a working installation with uncommitted changes.

Before relying on the deployment, inspect README.md, docker-compose.yml, .env.example, and relevant files under wiki. In particular, establish persistent mounts, published interfaces, image references, restart policies, and required configuration. Full docker compose config output can contain resolved secrets, so keep it private.

Do not infer configuration from variable names

The previous version of this guide assigned meanings and defaults to TZ, AUTH_SECRET, ENCRYPTION_KEY, NEXTAUTH_URL, MCP_ENABLED, and DATABASE_URL without enough current file evidence. Those assignments are not used here as deployment instructions.

Only create values that the installed revision actually requires, using its documented formats. Do not assume a key is arbitrary text, hexadecimal, or Base64. Do not assume copying .env.example automatically passes every variable into the application container: Compose interpolation and container environment configuration are separate mechanisms.

Likewise, we do not assert that MCP is currently enabled by default, describe unverified token behavior, select a database engine, or prescribe a NEXTAUTH_URL change. Confirm these details before public exposure. Preserve any required encryption material securely; changing it can affect access to encrypted application data.

Prepare Ollama and choose the correct network path

There are two separate tests: Ollama must generate a response, and JobSync must reach the same service with the correct provider configuration. Passing the first does not imply passing the second.

Install and test Ollama independently

Ollama provides native downloads for macOS and Windows through its official download page. Install the appropriate application and start it before using the CLI. For Linux, its standard installation script is available at the official endpoint below. These are general Ollama instructions, not evidence that a particular JobSync image has been tested with that Ollama version.

On Linux, download and inspect the script before executing it. It can make system-level changes:

curl -fsSL https://ollama.com/install.sh -o ollama-install.sh
less ollama-install.sh
sh ollama-install.sh
ollama --version

On a systemd installation where the installer created an Ollama service, inspect it with:

systemctl status ollama --no-pager
journalctl -u ollama -n 100 --no-pager

If using a manual foreground installation instead, ollama serve starts the server. Do not start a second server when the native application or service is already listening.

The following uses llama3.2:3b as a small standalone smoke-test example. It is not a claimed JobSync default or a guarantee of suitability for structured resume workflows. Check model availability, licensing, and hardware requirements before downloading.

ollama pull llama3.2:3b
ollama list
ollama run llama3.2:3b "Reply with a short greeting."

Test the native HTTP API separately. These command examples use a POSIX shell; on Windows, use WSL or adapt quoting for your shell.

curl --fail --show-error http://127.0.0.1:11434/api/tags

curl --fail --show-error http://127.0.0.1:11434/api/generate \
  -H 'Content-Type: application/json' \
  -d '{"model":"llama3.2:3b","prompt":"Reply with a short greeting.","stream":false}'

The first request should list installed models. The second should return JSON containing generated text. A connection error indicates service or networking trouble; a model-not-found error indicates that the selected server does not have the requested model.

Choose one network arrangement

These addresses describe Ollama's native API base. They are not verified values for a particular JobSync field. Some integrations expect a base address, others an API prefix, and OpenAI-compatible integrations can use different paths. Do not append /api or /v1 without confirming what JobSync expects.

Ollama on the Docker host

Inside a container, 127.0.0.1 refers to that container. On Docker Desktop, host.docker.internal normally resolves to the host. On Linux Docker Engine, a service-level mapping can provide that name:

# Merge into the actual JobSync service definition.
# This is a Docker networking fragment, not a complete JobSync Compose file.
extra_hosts:
  - "host.docker.internal:host-gateway"

Use docker compose config --services to identify the actual service rather than assuming its name. A host-gateway mapping does not make a loopback-only Ollama listener reachable. Ollama uses OLLAMA_HOST to control its bind address. A value such as 0.0.0.0:11434 listens broadly and requires appropriate host firewall restrictions.

For a Linux systemd Ollama service, sudo systemctl edit ollama can add this override if private-network access is deliberately required:

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"

sudo systemctl daemon-reload
sudo systemctl restart ollama

Apply network restrictions before broadening the listener. For a native macOS or Windows installation, configure the environment for the process that actually starts Ollama and fully restart that application. Setting a variable in an unrelated terminal will not reconfigure an already running server.

Ollama in another container

A shared Docker network avoids publishing the Ollama API to the host. This standalone example creates a private backend service with persistent model storage:

docker network create jobsync-ai
docker volume create jobsync-ollama
docker run -d --name jobsync-ollama \
  --network jobsync-ai --network-alias ollama \
  --restart unless-stopped \
  -v jobsync-ollama:/root/.ollama \
  ollama/ollama
docker exec jobsync-ollama ollama pull llama3.2:3b
docker exec jobsync-ollama ollama run llama3.2:3b "Reply with a short greeting."

This example does not configure GPU passthrough and uses an unpinned image reference for evaluation. Record or pin an approved image digest before relying on it operationally. No -p option is used, so the example does not publish port 11434 on the host.

Attach the actual JobSync service to the external network while retaining its existing networks and dependencies. The following is a merge fragment, not a replacement for the repository's Compose file:

services:
  YOUR_ACTUAL_JOBSYNC_SERVICE:
    networks:
      - default
      - jobsync-ai

networks:
  jobsync-ai:
    external: true

Replace the service placeholder and preserve any non-default networks already configured. Validate the merged configuration before applying it with docker compose up -d. On that shared network, the Ollama native API base is http://ollama:11434. A manual docker network connect can help diagnose connectivity, but a Compose declaration is preferable because manual connections can disappear when containers are recreated.

Ollama on another private machine

Use the machine's reachable private address or private DNS name, not container loopback. Configure its listener and allow only the required client path. Test from the Docker host and then from the application's network context. Plain HTTP does not encrypt traffic between machines; use an appropriately protected private network or an authenticated encrypted proxy where required. Do not make Ollama public merely to solve container routing.

Verify the local application, authentication, and AI path

Open http://localhost:3737 on the Docker host. The published quick start directs you to create an account there. Complete the following checks with disposable content:

1. Rendering: Confirm the application loads, not merely that the TCP connection succeeds.
2. Authentication: Create the account, sign out, and sign back in. Test a private browser session and confirm protected records are not available without authentication.
3. Storage: Create a sample job or task, reload the page, and confirm it remains.
4. AI backend: Run the standalone Ollama API test against the backend actually used by the application.
5. Integration: After confirming JobSync's provider configuration, perform a harmless AI action and check that the intended model service receives it.
6. Persistence: Restart the deployment and confirm the account and sample record still exist.

A successful home page does not prove database writes or inference. Conversely, failed AI generation does not necessarily mean the web application is unhealthy. Keep observations for each layer separate.

Historically, v1.1.22 introduced AI Usage information covering tokens, calls, response times, provider/model breakdowns, context-limit flags, and failures. If the installed revision includes that view, use it alongside container and Ollama logs. Do not assume those historical metrics establish the current UI or retention behavior.

Start, stop, inspect, update, and recover the deployment

The commands in this section are standard Docker Compose operations. Run them from the same project directory, with the same Compose files and project identity used at installation. They are not a claim about the behavior of JobSync's deployment scripts.

Background startup and logs

If the first launch is still attached to your terminal, stop it with Ctrl+C, then start in the background:

docker compose up -d
docker compose ps -a
docker compose logs --tail=100
docker compose logs --follow --tail=100
docker compose images

Ctrl+C exits a following log session without stopping detached containers. Inspect service state and logs together: “running” is not the same as application readiness. Record image IDs along with the Git commit for future troubleshooting.

Stopping, starting, and restarting

docker compose stop
docker compose start
docker compose restart

These commands are alternatives for different tasks, not a sequence you need to run routinely. stop stops existing containers; start starts those containers again; restart restarts them. A restart does not apply changed environment values or recreate services from updated configuration. After reviewing configuration changes, use:

docker compose config --quiet
docker compose up -d

Avoid docker compose down -v for routine maintenance because it can remove persistent volumes. Even ordinary container recreation can lose data stored only in a container's writable layer. Verify the deployment's persistent mounts before trusting it with important records.

Reboot persistence

Detached startup alone does not guarantee startup after reboot. The Docker daemon must start, each required service must have an appropriate restart policy, storage must be available, and Ollama must also return. The supplied JobSync Compose contents do not establish its restart policy.

On Linux systems with a systemd Docker service, inspect host startup configuration with:

systemctl is-enabled docker
systemctl status docker --no-pager

Docker Desktop has its own startup and login requirements. Plan a controlled reboot only after saving work and taking a backup. Afterward, check Compose state, local login, the sample record, standalone Ollama generation, and a JobSync AI action. If remote access is enabled, also confirm our client reconnects and the tunnel is running. Do not assume either behavior without testing it.

Backups and an isolated restore rehearsal

JobSync's public website describes backup and restore as a single ZIP archive. However, the supplied material does not include the current backup guide, exact UI actions, archive contents, encryption-key requirements, or compatibility rules. The repository also lists backup-db.sh and restore-db.sh, but their presence does not verify their invocation, prerequisites, or scope.

For that reason, no guessed restore command is provided. Before production use, establish the exact backup and restore controls for the installed revision and perform this acceptance test:

1. Create identifiable disposable records and generate an application backup using the confirmed workflow.
2. Store the archive separately from the host, along with securely protected configuration and keys required for recovery.
3. Prepare an isolated deployment with separate storage and no public tunnel. Start with the same application version unless documented compatibility permits otherwise.
4. Restore through the confirmed workflow, accounting for any warning that restoration replaces existing data.
5. Verify account access, sample records, resume attachments, and the restored configuration. Test AI separately.
6. Record the successful procedure and securely remove the temporary restored copy when finished.

Until those exact application steps and the rehearsal are complete, consider recovery unverified. A ZIP file existing on disk is not evidence that it contains everything needed to recover the deployment.

Updates without unverified scripts

We do not recommend executing deploy.sh or deploy.ps1 based solely on their filenames. Their current contents and prerequisites are not supplied. Review them before execution, including any source changes, image builds, migrations, deletions, or backup behavior.

For an image-based Compose deployment, the standard image-refresh mechanism is:

docker compose pull
docker compose up -d
docker compose ps -a
docker compose logs --tail=100

This is conditional infrastructure guidance, not a verified JobSync upgrade procedure. Use it only after confirming that the target release supports that path, the image references identify the intended release, and backups are recoverable. It does not update a pinned Git checkout or account for database migrations. Image rollback alone may not undo a schema change.

After an update, repeat authentication, record persistence, attachment access, Ollama generation, JobSync AI, backup creation, and public-URL tests. Record the new source commit and image identity.

Add Localtonet access to the verified web service

Use an HTTP tunnel because JobSync serves a browser-based web interface. Run our client on the Docker host when practical, so the target can be 127.0.0.1:3737. If the client is in a separate container or on another device, its loopback address is not the Docker host; use a target reachable from that client.

Our HTTP tunnel documentation is the specific configuration reference. The sequence below follows the supported general Localtonet lifecycle. The supplied evidence does not reproduce the current HTTP form's complete field ordering, so this is not represented as a screenshot-level transcription of that form.

Domain options and availability can vary by plan and current configuration. All three HTTP Process Types serve the target content at a public HTTPS address. Check current custom-domain instructions before changing DNS; no assumed DNS records are prescribed here.

Verify public authentication, not just connectivity

Open the final public URL in a private browser window, preferably from a different network. Confirm unauthenticated users cannot see protected records, then test sign-in, navigation, record creation, sign-out, and a fresh session. Check that redirects remain on the intended address.

Do not change NEXTAUTH_URL merely because its name sounds relevant. Its current JobSync support and semantics have not been established by the supplied files. If authentication fails through the public URL, verify the installed release's canonical URL and proxy requirements before making changes. Recreate the service when required to apply configuration, then repeat local and remote checks.

Protect resumes, credentials, and recovery data

Self-hosting gives you control over infrastructure, not an automatic guarantee that every request stays local. Hosted AI providers change the prompt-processing destination. Job discovery and other integrations can make external requests. A local Ollama backend narrows one data path but does not eliminate all network activity.

• Use unique account credentials. A hard-to-guess public URL is not authentication.
• Separate secrets. Application keys, provider credentials, integration tokens, and Localtonet device tokens serve different purposes.
• Restrict backend access. Do not publish database or Ollama ports to solve a web-access problem.
• Protect backups. Archives may contain personal records and attachments. Restrict access and keep an off-host copy.
• Review optional routes. Disable unused capabilities through supported configuration after verifying their actual controls.
• Sanitize diagnostics. Remove prompts, resumes, tokens, account identifiers, and private connection strings from logs and screenshots before sharing.

Keep the operating system, Docker, JobSync, Ollama, and our client maintained. Changes should have an identified target version, a recovery plan, and post-change tests. Remote connectivity must follow your organization's authorization and network policies.

Diagnose failures one layer at a time

Cloning or image downloads fail

Check the repository URL, DNS, outbound HTTPS access, and available disk space. Inspect partial directories before retrying. For Docker failures, preserve the relevant error text but redact credentials. Do not delete existing volumes as a generic troubleshooting step.

Compose cannot reach Docker or port 3737 is occupied

Use docker info to distinguish a stopped engine from application startup failure. Inspect docker compose ps -a and docker compose logs --tail=100. If the port is occupied, identify its owner before stopping anything. Any changed port mapping must also be reflected in the browser URL and tunnel target.

Ollama works on the host but not in JobSync

Check the container's network path. Host loopback, container loopback, and another machine's private address are different destinations. A working host-side /api/tags response does not establish container reachability. Confirm the listener address, shared network or host-gateway mapping, firewall policy, and application endpoint format.

The model is missing or inference stalls

Run ollama list against the correct service. Host and container Ollama installations can have different model stores. Test the exact selected model independently. Inspect Ollama logs and resource usage; larger context requests can behave differently from a one-line greeting.

Local JobSync works but the public URL fails

Confirm the selected client is connected, the HTTP tunnel has been started, and the local target is reachable from that client. Check for host sleep or container shutdown. A wrong device selection or a loopback target on the wrong machine can produce failures even when JobSync is healthy.

The public page loads but sign-in redirects fail

Inspect the redirect destination and application logs without sharing sensitive cookies. Verify current application URL and proxy configuration requirements rather than guessing environment variables. Retest using a fresh browser session after applying a confirmed correction.

Data disappears after restart or an update

Stop importing real data. Verify that the same Compose project and persistent storage are in use and that application data was not kept only in the container's writable layer. Do not run destructive cleanup commands. Restore only through a verified procedure into appropriate isolated storage when diagnosing a recovery problem.

Frequently asked questions