01
Start with organization and project boundaries
Members manage projects, tasks, and Agents within an organization so work has clear ownership and visibility.
Enterprise HiFox private deployment
Run Agent tasks inside your boundary
Deploy HiFox inside your private network or dedicated infrastructure. Members create tasks in projects, assign Agents, and let registered Computers execute through the CLI and local service while progress, blockers, and results return to the task context.
How HiFox works
Deploy an Agent execution loop, not an empty service shell
After private deployment, HiFox still works around real engineering objects: who owns the work, what gets done, which Computer executes it, how far it has progressed, and how the result is reviewed all remain in task context.
02
Assign the task to an Agent
Requirements, bugs, and technical debt enter the task flow, where an Agent can become the assignee and task context becomes the execution entry point.
03
Let a Computer receive and execute
A member Computer registers with an install token, while the HiFox CLI and local service connect the Agent CLIs already installed on that computer.
04
Return results to the task timeline
Status, blockers, execution results, and follow-up discussion return to the task context; isolated code changes are reviewed before delivery.
HiFox execution loop
Task in progress
1Organization / project
2Task
3Agent
4Computer
5CLI / local service
6Result returned
From assignment to result review, engineering collaboration stays in one work system
Why private deployment for HiFox teams
Turn Agents on personal computers into managed team execution resources
The value is not only putting services inside the enterprise network. It is bringing Agent configuration, tasks, execution environments, and delivery results into a workflow the organization can understand and review.
Set a clear Computer boundary
Each computer that runs Agents registers separately: the server coordinates work while the local service connects tools and executes it.
Control data and attachment location
Choose where PostgreSQL, attachments, domains, and network boundaries live so HiFox fits your existing infrastructure management.
Make cross-computer access explicit
Use a reverse proxy, TLS, or a private tunnel to connect the server and member Computers, with clear browser, API, WebSocket, and local execution paths.
Fit upgrades into existing operations
Version updates, logs, the /livez health check, and database migrations can be included in your existing release and operations process.
Security and governance
Give every Agent execution a clear responsibility boundary
Confirm the boundaries around HiFox's actual data and execution paths: browser, frontend, API, WebSocket, database, attachments, Computers, Agent CLIs, and repositories.
Organization, project, and task visibility
Use existing organization membership and workflow boundaries to define visibility and responsibility across projects, tasks, Agents, and execution results.
Separate server and Computer responsibilities
The server carries HiFox collaboration and realtime connections; each member Computer uses the CLI/local service to connect local Agent tools and execute work.
Decide where context, attachments, and logs live
Agree how task context, execution results, logs, and attachments are stored and retained; private attachments can use S3-compatible storage.
HiFox connects the work. Your organization decides where it runs.
From organization permissions and Computer registration to repository access and attachment retention, each boundary can be made explicit in the deployment design.
HiFox runtime topology
Collaboration on the server, data in layers, Agents on Computers
The server can run with Docker Compose or on your target infrastructure; browsers, data services, and member Computers connect according to your network design while HiFox keeps collaboration and execution clearly separated.
Browser / enterprise network entry
Configure an HTTPS reverse proxy or private tunnel for your network, forwarding the frontend, API, and WebSocket paths.
01
Server
Runs the HiFox frontend, Go backend, REST API, WebSocket, task collaboration, and realtime connections.
Vite static frontendGo backendREST APIWebSocket
02
Data layer
Stores HiFox core data; configure private object storage for attachments as part of the deployment design.
PostgreSQL 17pgvectorS3-compatible attachments
03
Execution layer
A registered Computer connects to its local Agent CLIs and receives and executes assigned tasks locally.
Registered ComputerHiFox CLIlocal serviceAgent CLI
Connect according to your network design
HiFox product capabilities
Keep the full collaboration loop from task management to Agent execution
HiFox connects the project-management layer your team knows with local Agent execution. These are the product objects to deploy and accept, not just infrastructure components.
Tasks, status, and timeline
Create requirements, bugs, and technical-debt tasks, assign people or Agents, and follow status, blockers, results, and discussion.
Agent and Computer management
Create Agents in HiFox, generate an install token from Computers, and register member computers as available execution resources.
CLI / local service execution
The local service discovers Agent CLIs on a member computer, receives assigned tasks, and returns execution status and results to the server.
Worktree isolation and realtime updates
Parallel Agents can use isolated worktrees while the Go REST API and WebSocket carry task collaboration, execution state, and realtime events.
Data and private attachments
Core data uses PostgreSQL 17 with pgvector; S3-compatible private storage can be configured for attachments with access rules agreed per deployment.
Delivery and acceptance
Accept HiFox with a real task, not only a running service
Starting the services is only the beginning. Delivery proceeds by verifying the organization, Computer, Agent, and representative engineering task loop.
Map HiFox work objects
Confirm organizations, members, projects, task types, repositories, Agent CLIs, Computer count, and data boundaries.
Deploy services and register Computers
Prepare Docker Compose or the target environment, configure frontend, API, WebSocket, database, attachments, and proxy/TLS, then register Computers.
Accept the real execution loop
Create an Agent, create and assign a task, then verify Computer pickup, CLI execution, status updates, worktree isolation, and result review.
Upgrade and operate by version
Check /livez, logs, and key configuration, update by version, and let database migrations run automatically; support scope is confirmed per project.
Contact sales
Bring your HiFox workflow to the deployment conversation
Share a little about your team and engineering workflow, along with the Agent task you want to try first. We can work through the deployment details together in the conversation.
- Your team's current engineering workflow
- The Agent task or process you want to try first
WeCom
Scan to contact sales.
Private deployment FAQ
Bring HiFox into your engineering workflow
What does HiFox do after private deployment?
+
HiFox connects organizations, projects, Agents, Computers, and tasks. Members create and assign work, a registered Computer receives it through the CLI and local service, and status, blockers, and results return to the task context.
Where does an Agent run?
+
Each member computer that runs Agents installs the HiFox CLI and local service, then registers through a Computer install token. Execution takes place in that registered local environment.
Can teams keep using Claude Code, Codex, and other tools?
+
Yes. HiFox does not replace the Agent tools your team already uses. The CLI/local service connects supported CLI-based tools so work can be assigned and tracked from the team task flow.
How do parallel Agents avoid overwriting code?
+
Agents can execute in isolated worktrees. Parallel changes stay separated, and the team reviews the result in the task context before deciding how to merge or deliver it.
Does private deployment require public internet access?
+
Not necessarily. Cross-computer use requires an HTTPS reverse proxy or private tunnel appropriate for your network, with the frontend, API, and WebSocket paths forwarded correctly.
How are upgrades handled?
+
Self-hosted services are updated by version, with database migrations running automatically when the backend starts. Health checks, logs, configuration reviews, and support scope are confirmed for each deployment project.