Why pdrive exists
Publishing markdown shouldn't require a static site generator, a deploy pipeline, and a prayer. AI coding tools now generate a flood of specs, RFCs, and architecture docs, and there is nowhere good to put them. Gists get lost. Wikis want their own editor. Static site generators want a build pipeline.
We built pdrive because we wanted to go from .md file to published URL with as little friction as possible. Markdown in, URL back.
You can use pdrive for all kinds of writing, not just product docs:
- AI-generated specs, RFCs, and architecture docs
- Human-written design docs and proposals
- Engineering handbooks and onboarding guides
- Internal knowledge bases for growing teams
- Runbooks, playbooks, and operational procedures
- API and product documentation
What makes it different
API-first. Every action you can take in the web UI is available through the JSON API. Publish from CI, scripts, or anything that can make an HTTP request.
MCP support. pdrive has a built-in MCP server, so AI coding tools like Claude Code, Cursor, and Windsurf can publish and read documents directly. Your AI assistant can update documents as part of a code change without you switching contexts.
Version control built in. Every publish creates a new version. You can view and compare previous versions of any document. No git history to dig through, no separate versioning system to maintain.
Simple permissions. Accounts have members with roles, and projects have members with roles. No complex permission matrices or inherited access rules.
Early access
pdrive is in early access. The core features work, but there's more to build. If you run into issues or have ideas, we want to hear about them on our Discord.