Open
Use the free engine
Self-hosting is where the open-core promise becomes concrete: run the engine yourself, choose your own data, and control the runtime assumptions.
Docs / Self-Host
Run your own
DaedalMap deployment.
Today, self-hosting means using the open repo and setting up your own runtime. Later, this path should become easier through native app delivery and clearer packaged installs.
Bring your own data
Build your own pack tree
You are not limited to the hosted catalog. The self-host path is also where private or custom sources fit.
Today
Technical path first
Right now this path is still developer-oriented, with GitHub and manual runtime setup as the main entry point.
Now
GitHub and manual setup
- Download the public repo
- Run your own app/runtime stack
- Use local files or your own packs compatible
- Best for technical users comfortable with setup
Coming soon
Native local install
- One-click install, no repo setup required
- Choose and download only the packs you need
- 2x to 6x faster than the hosted app
- Offline capable once packs are installed
- Private data stays on your machine, no per-query API cost
- Optional local AI model — remove the last cloud dependency, fully offline
- Right path for analysts, field teams, and restricted environments
Current self-host path
Right now, the practical path is to use the public GitHub repository and follow the runtime setup directly. That keeps the engine open and usable for people who want control, private deployment, or a local-first workflow.
Why self-hosting matters
Some people want the hosted app because it is easy. Others want their own runtime because the work is sensitive, custom, offline, performance-sensitive, or deeply tied to local files and policies. DaedalMap should support both without pretending they are the same use case.
Where this goes next
In the future, this path should become much friendlier: native installs, clearer pack syncing, and better local workspace behavior. The open repo is the current path, not the final form.