# PlanExe writes a plan you can edit, and admits what it cannot know

> PlanExe is a Python planning pipeline that turns a project brief into a structured first pass, then leaves the source artifacts on disk so a human can contradict them and continue from there. The interesting engineering is in the deployment defaults, where the compose file is deliberately cautious about the network boundary.

**PlanExeOrg/PlanExe** — Create a plan from a description in minutes

- Repository: https://github.com/PlanExeOrg/PlanExe
- Website: https://planexe.org
- Stars: 403 · Forks: 66
- Language: Python
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/planexeorg-planexe

## PLANEXE_BIND_HOST decides who on the network can reach the app

The compose file draws the network boundary in a comment block at the top, which is unusual and useful. Two services get published to the host: `frontend_multi_user` and `mcp_cloud`. Both bind to `PLANEXE_BIND_HOST`, and that variable defaults to `127.0.0.1`, so a default `docker compose up` is reachable from the machine and nothing else.

Widening it is a two step operation, and the comment insists on ordering. To test from a phone or from Claude Desktop on another machine:

```
export PLANEXE_BIND_HOST=0.0.0.0
docker compose up
```

Set the passwords first. The comment names three values to establish before you publish anything: `PLANEXE_FRONTEND_MULTIUSER_ADMIN_PASSWORD`, `PLANEXE_MCP_API_KEY`, and `PLANEXE_MCP_REQUIRE_AUTH=true`. Binding to all interfaces while leaving the third flag false is the specific combination the file is trying to prevent.

Worth noting for MCP use: `mcp_cloud` is the service an agent connects to, so it is the one that needs an API key before it is exposed.

## The compose file names its own insecure defaults out loud

The published defaults are permissive, and the file says so before you deploy rather than after. The listed exposures are admin/admin on the frontend, `PLANEXE_MCP_REQUIRE_AUTH=false` together with an empty API key on `mcp_cloud`, the default Postgres password, and no authentication at all on `worker_plan`.

That list is a design position as much as a warning. Frontend-only exploration on localhost should not force you to invent a credential system first, so the defaults are open and the blast radius is meant to be kept small by the bind host. The failure mode is a `docker compose up` on a shared network with those defaults intact.

Two of the four are environment variables you set yourself, which is the cheaper half to fix. `PLANEXE_MCP_REQUIRE_AUTH=true` plus a real `PLANEXE_MCP_API_KEY` closes the agent facing surface. The frontend credential is `PLANEXE_FRONTEND_MULTIUSER_ADMIN_PASSWORD`, and the Postgres password is whatever your `.env` supplies, since the services read configuration through `env_file`.

A `docker-compose.md` sits next to the compose file, which is where that detail belongs.

## Postgres and the planning worker keep no host ports at all

The other two services, `database_postgres` and `worker_plan`, have no host port mapping. They are reached over the compose network at `database_postgres:5432` and `worker_plan:8000`, and the file explains that inspection happens through `docker compose exec` or a one-off override rather than by opening a port.

The stated benefit is a nice piece of pragmatism: no host port to collide with a Postgres you already run on 5432. Running the stack on a laptop that already has a database stops being a conflict.

There is a second detail in the shared anchor block. Container to container connections always use port 5432, and the comment marks that explicitly as not affected by `PLANEXE_POSTGRES`. A variable that suggests it can change the internal port would break every service that talks to Postgres, so the compose file pins the semantics rather than leaving them inferred from the variable name.

Worker services also declare `depends_on` with `condition: service_healthy` for Postgres, so a worker does not start against a database that is still starting up. Each worker carries a `PLANEXE_WORKER_ID` with a per service default, and `PLANEXE_CONFIG_PATH` points inside the container at `/app`.

## Every run leaves editable artifacts, and edits propagate forward only

This is the part that separates PlanExe from a chat transcript. A run produces a folder of readable source artifacts alongside the final report, and the folder is Markdown, JSON and CSV.

The revision model has a direction. If you disagree with an assumption or an early decision, you edit that artifact and continue the plan from there. PlanExe rebuilds the later work that depends on your change and preserves the earlier work you have already accepted. Editing a stakeholder assumption does not invalidate the executive summary you agreed with last week, and it does not silently keep the risk register you rejected.

That makes the plan a sequence of checkpoints rather than one document. It also means the artifact layout is the interface, so the directory names and formats are worth inspecting before you build anything around the report.

The README is direct about what the output is not: not a substitute for stakeholder participation or professional sign off, but a way to start from a broad, inspectable baseline instead of a blank page.

## The output list is a planning discipline, not a feature list

The report components map to how a consulting engagement is structured: an executive summary and project purpose, then assumptions, constraints and unanswered questions, then strategic choices with alternative scenarios.

Execution detail follows. A work breakdown structure with a dependency-aware Gantt chart. Governance bodies with decision rights and escalation paths. Roles, stakeholders and engagement approaches. A risk register with SWOT analysis and mitigation proposals.

Then the adversarial pass: premortem, expert criticism, premise attack and self-audit. Then a concrete shopping list of documents to create, documents to find, and data to collect.

Two things follow from reading that list as a whole. The Gantt chart is dependency aware, so ordering carries information the tool derived rather than a flat timeline you typed. And the four review passes are separate stages, which is why a run can surface an assumption you did not know you were making instead of burying it in prose.

The scope claim is stated plainly: PlanExe targets consulting-scale, multi-phase initiatives, not everyday task lists or small personal projects.

## The repository is split into services that mirror the deployment model

The top level layout reads like a deployment diagram. `planexe` is the core, `llm_config` holds model configuration, and the worker side is split across `worker_plan` and `worker_plan_database`. Storage is `database_postgres` with `database_api` and `database_worker` alongside it. `frontend_multi_user` and `mcp_cloud` are the two surfaces the compose file publishes.

Everything else supports those services. `presets/`, `tools/`, `skills/`, `self_improve/`, `public/`, `experiments/`, a `rebuild.sh`, an `AGENTS.md`, a `PlanExe.code-workspace`, two example env files named `.env.developer-example` and `.env.docker-example`, and `docker-compose.md`.

The split matches the readme's claim that the pipeline can use cloud models or run with local models so sensitive project material stays on systems you control. Two `test.py` files at the root, including `test_oauth_parse.py`, suggest the test suite is shallow compared with the service count.

Self hosting is presented as a set of concrete motivations: work offline or inside an air-gapped environment, keep planning when a provider is unavailable in your country, avoid depending on pricing changes or shutdowns, and pick models that fit your language and hardware.

## The fifteen minute figure is the project's claim, not a measurement

The headline is that a complex project brief becomes an editable planning baseline in about 15 minutes, and the repository contains no benchmark, no timing harness and no evaluation dataset to back that number. Treat it as a vendor figure for the size of input the author had in mind.

What is checkable is the example gallery at planexe.org/examples/. Any plan there can be opened and read, which is the honest way to judge output quality: pick the report closest to your domain and check whether the assumptions and the premortem are the ones a practitioner would raise.

Entry points come in three shapes. The hosted path needs no installation and runs through an early access link on app.mach-ai.com. An account and the getting started guide live on separate subdomains of planexe.org. The documentation covers MCP, command line, AI agent and Docker setup for people who need their own infrastructure.

The licence is MIT and the last push was on 2026-09-27. There are no GitHub releases, so the commit history is the only version signal, which is worth remembering before you depend on this for a deadline.

## Conclusion

PlanExe suits teams that need to expose assumptions before committing money to a plan, and it suits anyone who wants the pipeline on their own hardware for confidential material. Before you deploy it, change the defaults the compose file names outright: admin/admin on the frontend, PLANEXE_MCP_REQUIRE_AUTH=false with an empty API key, the default Postgres password, and no auth on worker_plan. The last push was on 2026-09-27 and there are no GitHub releases, so treat the roughly 15 minute figure as an unmeasured claim and check the example plans under planexe.org/examples/ against your own domain.

## FAQ

### What does a PlanExe run produce?

Each run produces an interactive report plus a folder of readable source artifacts in Markdown, JSON and CSV. The report commonly covers an executive summary, assumptions and constraints, alternative scenarios, a dependency-aware Gantt chart, a risk register, a premortem and a list of documents to create and data to collect.

### Can I edit a generated PlanExe plan instead of starting over?

Yes. If you disagree with an assumption or an early decision, you edit that artifact and continue the plan from there. PlanExe rebuilds the later work that depends on the change and preserves earlier work you already accept.

### How do I expose the PlanExe docker services to my LAN?

Set PLANEXE_BIND_HOST to 0.0.0.0 and run docker compose up. The compose file requires you to set PLANEXE_FRONTEND_MULTIUSER_ADMIN_PASSWORD, PLANEXE_MCP_API_KEY and PLANEXE_MCP_REQUIRE_AUTH=true first, and the bind host defaults to 127.0.0.1.

### Can PlanExe run without sending project data to a model provider?

The planning pipeline can use cloud models or run with local models, which the project presents as a way to keep trade secrets and confidential strategies within systems you control, work offline or in an air-gapped environment, and keep access to the planning process over time.

### Is a PlanExe report safe to act on as a project plan?

No. The project states that generated claims, budgets, dates, laws, engineering assumptions and risk estimates may be wrong or incomplete, and that important projects still require evidence, stakeholder interviews, domain experts, professional review where applicable, and named people who take responsibility.

## Sources

- [Issues](https://github.com/PlanExeOrg/PlanExe/issues)
- [License: MIT](https://github.com/PlanExeOrg/PlanExe/blob/main/LICENSE)
- [PlanExeOrg/PlanExe on GitHub](https://github.com/PlanExeOrg/PlanExe)
- [Project website](https://planexe.org)
- [README](https://github.com/PlanExeOrg/PlanExe/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/planexeorg-planexe