Model access
MiroFish simulations are only as available as the model endpoint behind them. If the model provider is remote, the deployment is self-hosted but not fully offline.
MiroFish offline
MiroFish can be self-hosted, but fully offline use depends on every model and storage dependency.
People search for MiroFish offline when they want private control over source code, data, model calls, or deployment infrastructure. The practical answer is: self-hosting is the right starting point, while true air-gapped operation requires local models and local supporting services.
Self-hosting checklist
- Read the current GitHub README before copying setup commands.
- Review `docker-compose.yml`, Dockerfile, frontend, backend, and service ports.
- Copy `.env.example` into a local environment file and fill values through your own secret manager.
- Choose model endpoints: hosted provider, private gateway, or local model server.
- Plan storage for simulation memory, uploaded seed files, generated reports, and logs.
- Confirm AGPL-3.0 obligations before modifying or offering hosted access.
Important constraints
Compute load
Multi-agent simulations can be heavier than normal chat. Agent count, round count, report depth, and memory design all affect latency and cost.
Operational review
Before production use, review logs, auth, rate limits, file handling, data retention, and update process. A demo install is not the same as a hardened deployment.
Recommended path
Start with the online MiroFish workspace or demo reports to understand the workflow. Then inspect GitHub for Docker and `.env.example` details. Only after that should you decide whether self-hosting is worth the operational overhead for your team.