Local app
The UI and backend run on your machine, but model calls may still leave your network.
MiroFish-Offline
MiroFish offline means private setup with real infrastructure work.
Use this checklist before private deployment. A local web app is not enough if model calls, graph memory, uploads, logs, or backups still leave your network.
Before deploying sensitive material, verify your model provider, graph memory service, logs, uploads, and backups. A private frontend is not enough if the backend still sends data to cloud services.
What self-hosting gives you
- Control over the web app and backend runtime.
- Local storage for uploads and simulation artifacts when configured that way.
- Freedom to choose model endpoints and deployment boundaries.
- Better visibility into logs, costs, and operational behavior.
Offline readiness levels
Private network
The stack runs inside your own server or LAN, with controlled access and private storage.
Fully offline
All models, memory services, dependencies, and data stores are available without external network calls.
Related MiroFish guides
local UI
internal storage
model endpoint?
logs and analytics?
Offline is an operational claim
Self-hosted and offline are not the same word. Self-hosted may mean the interface runs on your own server while model calls, memory services, analytics, or backups still leave the machine. Offline means the workflow works without external network calls, or every dependency is an approved internal service.
For MiroFish, check the whole path before using sensitive seed material: upload handling, prompt construction, model endpoint, graph memory, report storage, authentication, logs, analytics, backups, and error reporting. If any piece reaches outside the intended boundary, say so before private material enters the system.
Small offline test
Use a harmless public prompt and a tiny text file. Run the workflow while watching where data goes during upload, model calls, graph building, report creation, authentication, and logging. Then repeat with the network restricted according to the target deployment. The failure point tells you which dependency is not local yet.
Run log fields
Input
What test file and prompt were used?
Network
Which endpoints were contacted during the run?
Storage
Where did uploads, memory, reports, and logs land?
Signoff
Who owns infrastructure, and who owns data approval?
FAQ
Can the UI run locally?
Possibly, but local UI does not prove model, memory, storage, and logs are local.
What should I test first?
Use harmless public seed material and map data movement before sensitive tests.
Is offline a one-time check?
No. Upgrades, model changes, analytics settings, and backups can change the boundary.
Source: MiroFish self-hosting and private deployment concerns.
Method: Reviewed browser, backend, model, memory, storage, logs, and backups.
Limits: This is not a security audit.
Updated: July 6, 2026
Private-readiness note
A useful note might say: "The web app runs on an internal host. Uploads are stored on an internal disk. Model calls go to a local endpoint. Graph memory is internal. Analytics are disabled. Logs are retained for seven days." Another valid note might say: "The UI is self-hosted, but model calls go to an external API." The second setup may still be acceptable for some work, but it should not be called fully offline.
Write the boundary in boring language. Boring is good here. It tells the reviewer where data goes, who can read stored reports, and which part would need to change before confidential material is allowed.
Who should approve the boundary
For personal experiments, a short checklist may be enough. For a team, offline use should be reviewed by the person who owns infrastructure and the person who owns the data. One knows where services run; the other knows what material is allowed to leave the organization. Both views are needed before the page's claim becomes operational reality.
Boundary language for teams
Use exact phrases. "Runs locally" means the interface or service starts on local infrastructure. "No external model calls" means prompts are not sent to a third-party model endpoint. "Internal storage only" means uploads and reports remain on approved storage. "Analytics disabled" means page events, errors, and report metadata are not transmitted to an outside service. Each phrase should be testable.
If a claim cannot be tested, it should not be used for private material. The safest offline page teaches readers to ask better operational questions before trusting the label. That is more valuable than a simple yes or no.
Audit the boring parts
Offline claims often fail in boring places: error reporting, analytics, font loading, package updates, backup jobs, or a default model endpoint left in configuration. These are not dramatic security events, but they can still move data outside the intended boundary. A careful deployment test checks normal success, expected failure, restart, backup, and upgrade behavior.
Keep the audit small and repeatable. One harmless input, one report, one failure, one log review, one network check. If that routine is easy to run, the team can repeat it after changes instead of relying on memory.
Offline checklist before sensitive material
Run the checklist in order: confirm the interface host, confirm model endpoint, confirm upload storage, confirm report storage, confirm graph or memory storage, confirm log retention, confirm analytics state, confirm backups, and confirm who can access each place. Then run one harmless scenario with the network boundary set the way production will use it. If any answer is unknown, the deployment may still be useful for public tests, but it should not be described as ready for confidential data.
The page should teach this discipline because "offline" is a trust word. Used loosely, it creates risk. Used carefully, it helps teams decide what setup is safe enough for their material.
Do not forget ordinary browser dependencies
Offline reviews often focus on model calls and storage, but the browser page can also load fonts, analytics, error reporting, scripts, or images. Check the rendered page with the intended network rules. If the interface breaks without an outside asset, either bundle the asset locally or document the dependency honestly.
Simple pass condition
The offline page passes only when a reader can describe what stays local, what is internal, what is external, what is disabled, and what remains unknown. Anything less is still a deployment question, not an offline answer.
Last check
If someone changes one setting later, rerun the harmless scenario and update the boundary note.