A deck cannot be read
A roadmap drawn in slides or on a whiteboard is a picture. Editing it is handwork, so it stops being edited, and an agent cannot use it at all.
Your agents plan with you
Zeitlines is an open-source roadmap and Gantt timeline viewer you host yourself. People edit it in the browser, agents edit it over MCP, and both work on the same records. The plan is plain JSON in a documented schema, so it stays readable and portable.
Why agents cannot see your plan
An agent working in your codebase has the code, the tickets and the conventions. What it does not have is the intent: what is planned next, in which order, what depends on what, and what has been promised to somebody outside. That lives in slide decks, whiteboards and people’s heads, where nothing can read it.
Zeitlines keeps the plan as records instead of as a picture. Phases, dependencies, status and versions are fields, not conventions in a title, so an agent can query them and act on them rather than guess.
A ticket is not a plan
In an issue tracker the roadmap is a view over tickets. A phase, a dependency across quarters or a commitment made outside has no field to live in, so an agent has to infer the plan from issues.
What an agent can do with a Zeitlines plan
Zeitlines ships an MCP server over stdio. Point Claude Code at a deployment and it can read and change the plan through the same API the browser uses, with the same optimistic locking.
Only database-backed timelines are exposed. File-based timelines are read-only on a deployment, so they are not offered for editing rather than failing halfway through a write.
| Tool | What it does |
|---|---|
list_timelines | Every database timeline, with id and description |
get_timeline | One timeline in full: items and groups |
add_item / update_item / delete_item | Items, patched field by field |
add_group / update_group / delete_group | The lanes items sit in |
replace_timeline | A whole timeline at once |
set_pricing, set_tier_value, … | The pricing model, from the product-roadmap plugin |
What it does
Agents work on the plan, not next to it
The MCP server exposes the same records the browser edits. An agent lists timelines, reads one, adds and moves items, and maintains groups. It runs against the live deployment, so a change is live when the tool call returns.
The plan is a file you can read
A timeline is JSON in a documented schema that is generated from the viewer’s own types, so it cannot drift from what the software reads. Version it in git, diff it, take it somewhere else.
Phases, dependencies, milestones
Phases run as a labelled ribbon across the top with a faint tint behind the items. Dependencies are drawn as right-angle arrows. Milestones are point items with a semantic icon.
Editable in the browser
On a database-backed timeline you drag to move and resize, double-click to add, and edit in a side form. Writes are per item with optimistic locking, so two people editing at once do not overwrite each other.
Timeline and list, one build
The same data renders as an interactive timeline or as a grouped list. Switching keeps your selection, grouping, filter and edits, because the view is a lens over one set of records.
Yours to run
MIT licensed, self-hosted, no telemetry and no sign-up. Node.js is enough for file-based timelines; Postgres is what makes one editable and live for several people.
A timeline is a file you can read
The file format is small enough to write by hand and versioned in git
like any other source file. Add the $schema
line and your editor completes and validates it, because that schema is
generated from the viewer’s own TypeScript types rather than maintained
alongside them.
An item needs a start and a label. Everything else — the end or a duration, the lane, the icon, the status, the owner, the Markdown body, the dependencies — is optional and additive. That is also what an agent reads and writes, so there is one representation rather than two.
{
"$schema": "../schema/timeline.schema.json",
"name": "Launch plan 2026",
"phases": [
{ "id": "discovery", "label": "Discovery",
"start": "2026-01-05", "end": "2026-03-15" }
],
"groups": [
{ "id": "eng", "content": "Engineering" }
],
"items": [
{
"id": "kickoff",
"start": "2026-01-05",
"content": "Kickoff",
"type": "point",
"icon": "milestone"
},
{
"id": "build",
"start": "2026-01-12",
"duration": "6w",
"content": "Build the thing",
"group": "eng",
"status": "Doing",
"body": "Markdown, shown in the detail panel.",
"metadata": {
"owner": "someone@example.com",
"dependsOn": ["kickoff"]
}
}
]
}Every kind of planning has its own rules
A litigation chronology is not a project plan with renamed columns. It has deadlines with a reference point, parties with roles, dates that cannot move. A construction schedule has trades, lead times and acceptance milestones. Put either in a generic tool and the rules end up as a convention in a title, which is exactly the knowledge nothing can read.
A Zeitlines plugin brings a domain its own item fields and, where grouping is not enough, a view of its own. It is switched on per timeline as data, and its code is only downloaded when a timeline that uses it is opened.
product-roadmap
Product and roadmaps
Adds a versioned pricing matrix and pricing cards to a timeline, plus the Version, Tier and Features item fields derived from that model. The assembled pricing model is readable through a public, unauthenticated endpoint.
Build one for your domain
One folder and one registration line, against a versioned host contract. The playbook walks through the gate, the domain model, the naming research and the verification.
What people plan with it
Product roadmap
Run a public or internal product roadmap on your own infrastructure: phases across the top, tracks as lanes, and a versioned pricing matrix that external pages can read straight from the API.
Needs a database →
Gantt project plan
A classic project plan with phases, dependencies and milestones, defined in one JSON file that lives in your repository. No sign-up, no database, no per-seat licence.
Runs without a database →
Timeline from Markdown notes
Point Zeitlines at a folder of Markdown files and it builds a timeline from the dates in their frontmatter. Your notes stay the source of truth; the timeline is a view of them.
Runs without a database →
Roadmap edited by Claude
Zeitlines ships an MCP server, so Claude Code can read a timeline, add items, move dates and maintain the pricing matrix. The changes are live the moment the tool call returns.
Needs a database →
Running it takes three commands
Clone, install, start. With no database configured, Zeitlines serves the
JSON files in data/ and
warns about anything it could not find rather than refusing to boot.
git clone https://github.com/zeitlines/zeitlines.git
cd zeitlines
npm install
npm run devQuestions about Zeitlines
- Can an AI agent edit a Zeitlines roadmap?
- Yes. Zeitlines ships an MCP server, so Claude Code can list timelines, read one, add and update items and groups, and maintain the pricing model. It works against the live deployment, so a change is live the moment the tool call returns.
- What is Zeitlines?
- Zeitlines is an open-source Gantt chart and roadmap viewer that you host yourself, with an MCP server so AI agents can read and write the same plan people edit. It renders items, groups, phases and dependency arrows from either static JSON files or a live PostgreSQL database, and shows the same data as an interactive timeline or a grouped list.
- Why keep a roadmap outside the issue tracker?
- In Jira or Linear the roadmap is a view derived from tickets, so anything that is not yet a ticket has nowhere to live: a phase, a dependency that spans quarters, a commitment made to somebody outside. An agent reading that has issues and has to infer the plan. Zeitlines keeps phases, dependencies and versions as fields of their own, and links out to the tickets rather than replacing them.
- Is Zeitlines free?
- Yes. Zeitlines is released under the MIT license, with no paid tier, no per-seat pricing and no sign-up. You run it on your own machine or your own server, so the only cost is whatever that hosting costs you.
- Does Zeitlines need a database?
- No. Drop a JSON file into the
data/folder and it registers itself as a read-only timeline — that path needs nothing but Node.js. A PostgreSQL database is what makes a timeline editable in the browser and live for several people at once. - What do I need to run Zeitlines?
- Node.js 22 or newer. That is enough for file-based timelines. For editable timelines you also need a PostgreSQL database, reached either through a plain connection string or through Supabase.
- Does Zeitlines collect telemetry?
- No. A self-hosted Zeitlines reports nothing anywhere, not anonymously and not optionally, and the website loads nothing from a third party. Usage outside a deployment you run yourself is therefore invisible to the project, which is the intended trade.
- Can several people edit the same roadmap at the same time?
- Yes. Every write targets a single item and carries the row version it was based on, so a stale write is rejected rather than silently overwriting somebody else’s change. Other people’s edits arrive without a reload, and presence avatars show who is currently on which item.
- What is a Zeitlines plugin?
- A plugin adds what one kind of planning needs on top of items and groups: its own item fields and, where grouping is not enough, a view of its own. It is switched on per timeline as data and its code is only downloaded when a timeline that uses it is opened. The shipped example is
product-roadmap, which adds a versioned pricing matrix plus the Version, Tier and Features fields derived from it. - Can I put a Zeitlines deployment behind a login?
- Yes. The Netlify deploy includes an edge auth gate: Google sign-in plus a whitelist of allowed e-mail domains. Public pricing endpoints stay reachable without a login, which is what lets an external pricing page read the same model.
- Can I change how Zeitlines looks?
- Yes. The viewer ships one neutral theme defined entirely as CSS custom properties — colour tokens, lane colours, typography and mark radius. Override any of them in a stylesheet loaded after the theme; there is no build flag and no runtime theme selector to work around.