Introducing the MakerKit CLI v2: Plugins, Project Updates, and AI-Powered Merges

This post is part of a unique release, including the MakerKit Plugin System and MakerKit MCP 2.0.

We just shipped CLI v2 - along a much improved plugin system and MCP server.

You can now add a feedback widget, analytics, or billing to your SaaS in under 60 seconds with npx @makerkit/cli@latest plugins add feedback. One command, fully wired, no manual config. Our codemods take care of the rest.

MCP-first

The Makerkit CLI v2 is MCP-first: every operation — installing plugins, pulling upstream updates, resolving merge conflicts — is exposed as a tool your AI assistant can call directly.

You can still run every command from your terminal, but the CLI was designed from the ground up so that Claude, Cursor, or any MCP-compatible agent can manage your MakerKit project on your behalf.

This is also part of a larger effort to make Makerkit more vibe-codeable. More exciting developments coming soon!

One-command plugin installation

Installing a plugin used to mean git subtree commands, manual config wiring, and hoping nothing breaks. That's over.

npx @makerkit/cli@latest plugins add

That single command downloads the plugin files, installs dependencies, wires up your config files with AST-based codemods, and appends environment variables. No manual steps. No merge conflicts. Review the diff, run your tests, commit. Done.

Available plugins

Thirteen plugins ship at launch (across all the kits), with more on the way:

• Feedback: Popup widget with admin dashboard for collecting user feedback
• Waitlist: Signup form with admin approval workflow
• Testimonial: Testimonial collection with video support and display widgets
• Roadmap: Public roadmap with voting, comments, and kanban admin
• Paddle: Paddle Billing integration (alternative to Stripe)
• Google Analytics: GA4 tracking with configurable page view handling
• PostHog: Product analytics with client and server-side event tracking
• Umami: Privacy-focused, self-hosted analytics
• SigNoz: OpenTelemetry-based application monitoring
• Honeybadger: Error monitoring and uptime tracking with zero-config alerts
• Directus: Headless CMS integration with content modeling and REST/GraphQL APIs
• Meshes Analytics: Event tracking for user engagement and conversions
• Supabase CMS: Use Supabase/Postgres as a headless CMS with Markdoc rendering

All thirteen are available for the Next.js + Supabase variant. Next.js + Drizzle and Next.js + Prisma currently ship six plugins (Google Analytics, PostHog, Umami, SigNoz, Honeybadger, Directus), with the rest being ported.

Each plugin lands as a self-contained package under packages/plugins/ in your Turborepo monorepo. You own the code — read it, modify it, make it yours.

Getting started with plugins

Running plugins add with no arguments shows an interactive picker where you can select multiple plugins at once.

# First-time setup — configures the registry with your GitHub username
npx @makerkit/cli@latest plugins init
# Install a plugin
npx @makerkit/cli@latest plugins add feedback
# Install multiple at once
npx @makerkit/cli@latest plugins add umami posthog feedback
# Or pick from an interactive list
npx @makerkit/cli@latest plugins add

The CLI requires a clean git working tree before making any changes. If something goes wrong, roll back with git checkout . && git clean -fd.

For the full architecture deep dive — how the registry works, why we built our own file orchestrator, and how AST-based codemods wire everything up — read Introducing the MakerKit Plugin System using Codemods and Shadcn CLI.

project update: keep your kit current

Staying up to date with the upstream MakerKit kit used to mean managing git remotes, remembering the right commands, and hoping the merge goes smoothly. project update handles all of it.

npx @makerkit/cli@latest project update

Here's what happens under the hood:

1. Detects your kit variant by reading package.json dependencies (Next.js + Supabase, Next.js + Drizzle, Next.js + Prisma, React Router + Supabase)
2. Configures the upstream remote pointing to the correct MakerKit repository for your variant
3. Auto-detects SSH access to GitHub and falls back to HTTPS if needed — no more fiddling with remote URLs
4. Fetches and merges the latest changes from upstream/main
5. Reports conflicts with clear, actionable instructions if the merge needs manual resolution

The command is smart about remote management. If you already have an upstream remote configured, it validates the URL matches the expected repository. If the URL is wrong (maybe you switched variants, or the remote is pointing somewhere else), it asks before updating. If you don't have one at all, it adds it automatically.

SSH detection works by testing ssh -T git@github.com with a 10-second timeout. If SSH is available, the remote uses git@github.com:makerkit/.... If not, it falls back to https://github.com/makerkit/.... Either way, it just works.

When the merge succeeds, you're up to date. When there are conflicts, you get a clear list:

Merge conflicts detected. To resolve:
  1. Fix the conflicting files
  2. Run: git add .
  3. Run: git commit

And if you have the MCP server running, your AI assistant can resolve those conflicts automatically (more on that below).

MCP Server: the AI-first interface

Every CLI command has a corresponding MCP tool. What does it mean? It means that AI-Agents have first-class access to your MakerKit project (if you use the MCP server with your AI-Agent of choice).

That's not an afterthought — it's the core design principle. The CLI ships as an MCP (Model Context Protocol) server, so your AI assistant can install plugins, pull updates, and resolve conflicts without you typing a single command.

Setup

Drop this into your Claude Desktop config (.mcp.json) or Cursor config (.cursor/mcp.json):

{
  "mcpServers": {
    "makerkit-cli": {
      "command": "npx",
      "args": ["-y", "@makerkit/cli@latest", "makerkit-cli-mcp"]
    }
  }
}

That's it. Your AI assistant now has access to every tool it needs.

Available tools

Three-way merge with AI conflict resolution

Before this, updating a customized plugin meant choosing: lose your changes, or skip the update. The MCP server eliminates that trade-off.

Here's how it works. When a plugin is installed, the CLI stores the original registry files as base versions. On the next update, makerkit_check_update computes a three-way diff for each file:

• Base: the original version you installed
• Local: your current file (with your customizations)
• Remote: the latest version from the registry

Each file gets a status:

For conflict files, your AI assistant reads all three versions, understands both your changes and the upstream changes, and produces a merged result. Then it calls makerkit_apply_update to write the resolved files.

The same three-way merge powers project update. When pulling upstream kit changes creates merge conflicts, the AI assistant gets the base/ours/theirs content for each file and resolves them automatically.

One important note: AI merging is non-deterministic. Always review the result and run your tests before committing. But in practice, it handles the vast majority of conflicts correctly — and it's a lot faster than resolving them by hand.

Full command reference

What's next

We're just getting started. Here's what's coming:

• plugins remove: Clean removal with reverse codemods that undo config wiring
• More plugins: New plugins based on customer requests — tell us what you need
• Smarter AI merges: Better conflict context and resolution strategies in the MCP tools

And there's something else. The CLI and MCP server aren't just developer tools — they're the foundation for a new way to interact with your MakerKit project. Every operation is now programmable, every tool is callable by any MCP-compatible client. We built this infrastructure for a reason, and the terminal is just the beginning. More soon.

For the full breakdown of what the kit MCP server can do — 56 tools across database ops, environment management, email inspection, translations, and more — see MakerKit MCP 2.0.