Set Up Hunter Community Edition with Localtonet

What this deployment includes

Hunter Community Edition is an open-source, self-hosted financial AI application intended to run on infrastructure you control. Its interface combines chat, financial research workflows, positions, watchlists, investment memory, tools, and skill-based analysis. The project uses Docker Compose to coordinate its services, which keeps the initial installation workflow consistent across supported Docker environments.

The deployment has three distinct layers that are important to understand before exposing anything remotely. Hunter is the application layer. Docker and Docker Compose provide the runtime layer. Localtonet is added afterward as the connectivity layer. Keeping those responsibilities separate makes verification and troubleshooting much easier.

What self-hosting means in this workflow

Hunter's containers and application storage run on your machine, and the project describes conversations, positions, and investment-memory data as residing on your disk. That gives you direct control over the host, environment file, Docker storage, and application lifecycle. It does not automatically mean that every piece of information remains entirely offline.

Hunter requires an external language-model provider unless you deliberately configure a compatible endpoint that you operate. Prompts and other information included in model requests may therefore be sent to the configured provider. Financial data can also come from external data services, tools, or MCP servers. Review the privacy and retention behavior of every service you configure, not only the location of Hunter's database.

Why local verification comes before tunneling

A remote-access tunnel cannot repair a failed application deployment. If the containers are unavailable, the web service is not listening, or Hunter cannot reach its configured provider, the public address will only expose the same underlying failure. We therefore divide this guide into two milestones:

1. Install Hunter and prove that http://localhost:3100 works from the host.
2. Install our client on a device that can reach that endpoint, create an HTTP tunnel, start it, and test the assigned public address.

This order also helps isolate faults. Before the tunnel is introduced, every problem belongs to the repository, environment configuration, Docker runtime, container images, local port, or upstream providers. After local verification succeeds, remote-only failures can be investigated as connectivity or tunnel-configuration issues.

Prerequisites for Hunter Community Edition

Prepare the host before cloning the repository. The project's documented requirements are Docker Desktop on Windows or macOS, or Docker Engine with Docker Compose v2 on Linux. The machine also needs at least 20 GB of available disk space, 4 GB of memory, access to ghcr.io, and an API key for a supported language-model provider.

Confirm Docker Compose v2

The syntax matters. Compose v2 uses docker compose with a space. If your installation only recognizes an older docker-compose executable, update the Docker installation or install the supported Compose v2 integration before continuing. This guide follows the command documented by Hunter and does not substitute an older Compose workflow.

On Windows and macOS, start Docker Desktop and wait until its engine reports that it is ready. On Linux, ensure the Docker daemon is running and that the current user is allowed to execute Docker commands under your local administration policy. Permission handling varies by Linux distribution and should not be worked around by broadly weakening access to the Docker socket.

Check disk, memory, and registry connectivity

Treat the 20 GB disk requirement as available capacity, not total device capacity. Container layers, writable volumes, logs, and future image updates can all consume additional space. If the host is already close to full, free storage before beginning. A pull that fails midway due to insufficient disk space can leave an incomplete deployment and additional cached layers.

The host must be able to connect outbound to ghcr.io. Corporate proxies, registry allowlists, DNS filtering, and authenticated egress gateways can prevent Docker from pulling images even when ordinary websites work in a browser. If your environment controls outbound registry traffic, have the appropriate administrator approve the required registry access rather than disabling network controls.

Choose an LLM provider before editing the environment

The environment file needs the provider's base URL, model identifier, and API key. Hunter supports OpenAI-compatible endpoints, but the exact values are provider-specific. Copy them from the current documentation for the provider and model you actually intend to use. Model names, availability, account requirements, and API behavior can change independently of Hunter.

The project's example configuration includes a DeepSeek setup and states that LLM_SCHEMA_SANITIZE=1 must be enabled for that provider. Do not assume that a provider-specific setting applies to every OpenAI-compatible service. Conversely, do not omit a provider requirement simply because another endpoint works without it.

Install and configure Hunter Community Edition

Hunter's documented quick-start process has three stages: clone the repository and create the environment file, configure the required environment values, and start the Compose deployment. Perform these actions from a terminal on the machine that will host the containers.

git clone https://github.com/agentpit-io/hunter-community
cd hunter-community
cp .env.example .env

echo "JWT_SECRET=$(openssl rand -base64 48)" >> .env

docker compose up -d

Step 1 in detail: create a working configuration copy

The repository's .env.example is a template, not the active configuration. Copying it to .env gives the Compose deployment a local configuration file while preserving the original example for comparison. Make all secret and provider changes in .env.

The supplied quick-start command uses cp, which is available in Linux and macOS shells and in some Windows terminal environments. If the shell on Windows does not provide cp, copy .env.example to a new file named exactly .env using the operating system's file-management tools. Ensure the result is not accidentally named .env.txt.

Stay in the cloned hunter-community directory for the remaining commands. Running Compose from another directory can cause Docker to miss the intended docker-compose.yml and environment file.

Step 2 in detail: configure the authentication secret

JWT_SECRET is a shared secret used by Hunter's JWT-based authentication path. The documented Linux/macOS command uses OpenSSL to generate 48 random bytes encoded as Base64 and appends the result to .env. Before running it, inspect the template. If JWT_SECRET is already present with a placeholder value, replace that line rather than creating conflicting duplicate entries.

The extracted project evidence points Windows users to its detailed getting-started document for a PowerShell-specific generation command, but that exact command is not established in the evidence available for this article. We will not invent one. On Windows, generate the value with a cryptographically secure secret generator that you trust and place it after JWT_SECRET= in .env. A casual phrase, username, date, or reused password is not an appropriate JWT secret.

Step 2 in detail: configure the model provider

The project identifies the following environment names for its LLM connection:

LLM_BASE_URL=your-provider-base-url
LLM_DEFAULT_MODEL=your-provider-model-id
LLM_API_KEY=your-provider-api-key

Replace every descriptive placeholder with a value supplied by the selected provider. Do not include quotes unless the project's environment syntax or the value itself requires them. Do not copy a model identifier from a tutorial without confirming that it exists for your account and endpoint.

For the DeepSeek example documented by Hunter, the configuration shape is:

LLM_BASE_URL=https://api.deepseek.com/v1
LLM_DEFAULT_MODEL=deepseek-v4-pro
LLM_API_KEY=replace-with-your-own-key
LLM_SCHEMA_SANITIZE=1

The model identifier and provider availability are external, time-sensitive details. Confirm the current model name and API entitlement with the provider before treating this example as deployable. The important Hunter-specific point is that the base URL, model, and API key must agree, and the documented DeepSeek path requires schema sanitization.

Hunter also describes HUNTER_API_KEY as optional. It is associated with the project's platform data pipeline rather than the basic requirement to connect a language model. Do not confuse the two credentials. An LLM key drives model requests; an optional Hunter pipeline key enables the corresponding financial-data services.

Choose how Hunter receives financial data

The project documents three data-supply approaches. This choice is separate from the mandatory LLM setup:

A practical installation starts with the least complex path that can prove the interface and model connection. Add external tools only after the base deployment works. Introducing a model provider, several data services, custom MCP servers, and public access at the same time makes failures much harder to isolate.

Step 3 in detail: allow the first image pull to complete

Run docker compose up -d only after saving .env. The -d option starts the stack in detached mode, allowing the terminal to return while the containers continue running.

Hunter's project description notes that the initial pull can take around ten minutes and that later starts can be much faster. Treat those figures as rough project guidance, not a performance guarantee. Download time varies with registry reachability, bandwidth, disk performance, host load, image cache state, and current image sizes.

Do not interpret a returned shell prompt as proof that every service is ready. Compose can start containers while application initialization continues in the background. Use the local browser check in the next section as the primary user-facing verification.

Verify Hunter locally before remote access

Open the following address from a browser on the Docker host:

http://localhost:3100

A successful result is the Hunter web interface rather than a browser connection error, an unrelated service, or a perpetual gateway failure. Because localhost refers to the device running the browser, perform this first test on the same machine as Docker. If Docker runs on another server, localhost on your laptop does not refer to that server.

Verification checklist

1. Confirm that the page loads from http://localhost:3100.
2. Confirm that the visible interface is Hunter, not another application already bound to port 3100.
3. Complete any local first-use flow shown by the installed version.
4. Submit a simple, low-risk prompt that does not contain sensitive financial or personal information.
5. Confirm that the application returns a model response rather than an authentication, provider, or configuration error.
6. Try a supported market-data query and distinguish a data-source limitation from an LLM failure.
7. Refresh the page and confirm that the web interface remains reachable.

The Hunter README suggests testing with a market-price question and trying its prediction or deep-analysis workflows. Those operations can depend on the configured data route and may take longer than a basic chat response. Start with the smallest useful test. A failed advanced analysis does not necessarily mean the entire web deployment is broken.

Interpret failures by layer

If the browser cannot connect at all, focus on Docker, container startup, port binding, and host resources. If the interface loads but model requests fail, review the LLM base URL, model identifier, key, account entitlement, and provider-specific settings. If ordinary chat works but market data does not, inspect the selected data-supply route and its coverage.

This distinction prevents unnecessary tunnel changes later. Localtonet forwards traffic to the local web endpoint, but it does not configure Hunter's model or financial-data providers.

Routine operation and maintenance boundaries

The documented startup action is docker compose up -d from the repository directory. Keep that directory, its Compose file, and its environment file together. If the host reboots, verify both the Docker runtime and the Hunter web endpoint before assuming that the application or tunnel has resumed.

Keep a record of the deployed revision

The repository's main branch can change over time, and container tags can also move when a Compose file references a rolling tag. Record the repository revision and deployment date during installation. This provides a known point for investigating behavior changes and lets you compare your environment with the configuration expected by that revision.

Do not update a working financial research system casually. Read the project's current release notes and migration instructions before pulling changes or replacing images. The supplied evidence confirms installation and startup, but it does not establish a universal update command, rollback procedure, or backup sequence for every release. We therefore do not invent those operations here.

Back up data according to the deployed Compose definition

Hunter describes local storage for application information, including investment-memory data. Before designing a backup, inspect the exact Compose revision you deployed and identify its named volumes, bind mounts, and database services. Backing up only the cloned source directory may omit data stored in Docker volumes. Copying a live database directory without an application-consistent procedure can also produce an unusable backup.

The available project evidence does not define a verified backup and restore workflow for this exact deployment. Treat that as a limitation. Before entering information you cannot recreate, establish and test a backup method suitable for the actual database and volume layout in your checked-out version.

Monitor resource growth

The initial 20 GB requirement is not a permanent storage ceiling. Images, container logs, databases, cached assets, and application data can grow. Monitor free space and memory on the host. A system that worked after installation can later fail if the disk fills or memory pressure causes services to restart.

Handle secrets as deployable configuration

Keep .env out of commits and backups that are shared without encryption. Limit host access to administrators who need it. When rotating an LLM key or JWT secret, use a planned maintenance window and follow the current project behavior for applying environment changes. Changing a JWT secret may invalidate existing sessions, which is often desirable after suspected exposure but can surprise active users.

Separate a restart from a repair

Restarting containers can clear a transient process failure, but it does not correct an invalid model name, revoked key, blocked registry, full disk, or conflicting port. Record the visible symptom before taking action. Otherwise, a restart can erase useful context while leaving the root cause untouched.

Expose the verified Hunter interface with Localtonet

Once http://localhost:3100 works, you can make the browser interface reachable remotely through a Localtonet HTTP tunnel. Our client runs on a device that can reach Hunter and establishes an outbound connection to a Localtonet relay. This avoids inbound router port forwarding, firewall rule changes, VPN setup, and the need for a public IP address.

The public address is available only while the selected Localtonet client is connected and the tunnel is running. Creating a tunnel does not start it automatically. You must use the Start action, and you can later stop or delete the tunnel.

HTTP tunnels may use a generated random subdomain, a selected custom subdomain where supported, or a custom domain. All three process types serve the configured content at a public HTTPS address. Availability can vary by plan and current product configuration. Exact custom-domain DNS instructions are intentionally not included because they must be checked against current Localtonet documentation before being applied.

For the current product workflow, consult our Localtonet HTTP tunnel documentation . Use the dashboard's current server and domain options rather than assuming that every option is present in every account.

Which local target should you use?

The same-host configuration is preferable for a first deployment because it avoids assumptions about LAN bindings and host firewalls. It also preserves the exact endpoint already tested during local verification.

Verify the remote path independently

Do not test only from a browser that already has an authenticated local Hunter session. Use a private browsing window or a separate device so that you can observe the real first-visit behavior. Check that the public URL uses HTTPS, the expected Hunter page appears, and unauthenticated access is handled appropriately by the installed version.

Then send a harmless prompt. This tests the complete path from the remote browser through the Localtonet relay, through the outbound client connection, into Hunter, and onward to the selected model or data provider. If the page loads but an AI request fails, the tunnel is probably transporting HTTP successfully and the failure belongs to Hunter or an upstream provider.

Security and privacy considerations

A Localtonet HTTP tunnel changes Hunter from a service available only through its local network path into one with a public address. That is useful, but it also expands the audience capable of reaching the application's entry point. Treat the public URL as discoverable and design access accordingly.

Protect application and provider credentials

The environment file may hold a JWT signing secret, an LLM API key, and an optional financial-data key. These credentials have different purposes and should be rotated independently. The Localtonet device token is another separate secret. Never combine them in one public configuration example or send them as part of a browser troubleshooting screenshot.

Provider keys may authorize billable usage. A public Hunter endpoint can therefore create cost exposure if weak authentication allows someone else to submit prompts or trigger expensive analysis. Apply provider-side usage controls where available and monitor account activity. Do not rely on obscurity of the public hostname.

Minimize sensitive prompts during testing

Use fictional or public market examples for installation tests. Do not begin with private portfolio notes, account identifiers, customer records, brokerage exports, or confidential research. First confirm where Hunter stores data, what the selected model provider receives, which external tools are active, and whether any connected service retains requests.

Understand the encryption boundary

The public HTTP process types provide an HTTPS address and terminate TLS at the tunnel edge. Hunter remains configured as a local HTTP target on port 3100 in this workflow. Do not extend that statement into unsupported claims about every downstream provider connection, database field, credential store, or container network. Each component has its own security boundary.

Expose only the intended service

Create the HTTP tunnel for Hunter's browser endpoint only. Do not publish databases, Docker control interfaces, internal MCP callbacks, or administrative ports unless a separately documented and secured use case requires them. The presence of several services in a Compose stack does not mean they should all be remotely accessible.

Stop access when it is not needed

The tunnel is available only while the selected client is connected and the tunnel is running. Use that lifecycle deliberately. Stop the tunnel when remote access is unnecessary, and delete obsolete tunnel configurations rather than leaving forgotten public entry points. Remember that stopping Localtonet does not stop Hunter itself, and stopping Hunter does not delete the tunnel configuration.

Keep the host and application maintained

Remote access makes timely maintenance more important. Keep the host operating system, Docker runtime, Hunter revision, and container images under a reviewed update process. Read release notes for authentication changes, migrations, new exposed ports, and modified environment variables. Back up recoverable data before applying changes.

Respect organizational policy

Outbound tunneling should be used only on devices and networks where you have authorization to expose the service. Do not use a tunnel to bypass workplace controls, application authorization, or network policy. If Hunter contains regulated, customer, or employer-owned information, obtain the necessary approval before making it reachable from the public internet.

Troubleshooting the deployment and tunnel

Troubleshoot from the inside out. Start with host resources and Docker, then verify Hunter locally, then verify upstream providers, and only then inspect Localtonet. This sequence keeps unrelated failures from being mixed together.

The repository cloned, but .env is not being used

Confirm that the file is named exactly .env and resides beside the Compose file in the cloned repository. On systems that hide known extensions, verify that it was not saved as .env.txt. Also check for duplicate keys and malformed lines introduced while copying values.

Do not share the full file while asking for help. Create a redacted list of variable names and whether each value is present. Replace every secret, hostname unique to your environment, account identifier, and private endpoint before sharing diagnostic material.

Docker cannot pull from GHCR

Verify that the host can resolve and connect to ghcr.io. If the error mentions authorization, inspect the exact image and registry response. The v0.2.0 release notes discussed a companion image whose visibility required attention at release time and mentioned registry authentication as an alternative when an image is private. Current visibility may differ, so diagnose the current registry response instead of assuming that every image is public or private.

If a controlled network uses a proxy, configure Docker according to the network administrator's policy. Browser proxy settings do not necessarily apply to the Docker daemon. Avoid copying registry access tokens into the Hunter environment file because those credentials belong to Docker's registry authentication mechanism, not Hunter's application configuration.

Hunter does not appear on port 3100

Allow initial image downloads and service initialization to complete. Verify that Docker has enough memory and storage. Check whether another application already uses port 3100. Because the available evidence does not provide Hunter-specific log commands or a complete health-check procedure for every release, use Docker Desktop's container status and logs interface or the equivalent supported diagnostic facilities in your Docker installation without publishing secrets.

If the Compose configuration was edited, return to the repository version's expected values before diagnosing deeper issues. Unrelated changes to ports, networks, image tags, or service dependencies can invalidate the documented local endpoint.

The interface loads, but the provider rejects requests

Confirm that LLM_BASE_URL belongs to the provider issuing the key and that LLM_DEFAULT_MODEL is available to that account. An HTTP-compatible API does not guarantee that every model supports the same tool-calling behavior. Also check whether the account has quota, billing authorization, geographic eligibility, or request restrictions.

For the documented DeepSeek path, verify LLM_SCHEMA_SANITIZE=1. For another provider, follow its current requirements and Hunter's matching environment template. Do not add random compatibility flags until the base URL, key, and model are known to be correct.

Local access works, but Localtonet does not

First identify where our client runs. If it is on the Hunter host, use the same-host target 127.0.0.1:3100. If it runs elsewhere, opening localhost:3100 on that second device tests the second device itself, not Hunter. The remote client device needs a reachable private address for the Hunter host, and Hunter must listen on an interface that permits that connection.

Next verify lifecycle state. The device must be connected, and the tunnel must have been explicitly started. Confirm that the selected authentication token belongs to the intended device and that the relay selection is currently available in the dashboard. Do not hardcode a server code copied from an old guide.

The public page is reachable but should no longer be exposed

Stop the tunnel in our dashboard. If the configuration is obsolete, delete it. Then verify from an unauthenticated browser that the public address no longer serves Hunter. If credentials may have been exposed while the application was public, rotate the affected Hunter, LLM, data-provider, and Localtonet credentials according to their respective systems.

Frequently asked questions