Essay · May 2026

Why I stopped paying Composio $29/month and built mcpvault instead.

Hosted credential platforms make sense for products. They make less sense for the developer using AI to do their own work. Here's the math, the threat model, and what I built to replace mine.

The setup

I'm a solo developer. Most days I'm using Cursor or Claude Code against a small set of services I actually pay for: Supabase (a personal account and a work account), GitHub (personal + an org-scoped fine-grained PAT for client work), Vercel (one personal team), and Stripe (one live account, mostly for read-only customer lookups when invoices come in).

The agent loop that mattered to me looked like this: "Hey Claude, I'm working on the client project today, switch to that Supabase and tell me if there are any failed migrations." If the agent could do that reliably and securely, it'd save me 20 minutes of context-switching per session.

I tried Composio first. It worked. It also cost money and required me to authorise their OAuth app for every service I cared about, meaning the credentials for my production Supabase ended up living on composio.dev's servers in addition to mine.

That second part bothered me more than the money.

The money first, because it's easier

Composio's pricing is fine for what it is. Free tier with usage limits; Growth at ~$29/month per developer; enterprise on top. I burned through the free tier in a week of normal use (lots of repeated tool calls during agent iteration), so $29/month was the actual ask.

$29/month is $348/year. For something that, fundamentally, is a CLI that wraps four HTTPS APIs. The substrate (MCP) is a free open spec. The implementation work is non-trivial but bounded. For a hosted product serving thousands of users at scale, $29/month is cheap. For me running it against my own tokens, it's an annual mid-range mechanical keyboard for a wrapper around fetch().

None of this is a knock on Composio's pricing — they have to staff a company. It's a knock on me, the person who paid them, for buying a hosted answer to a problem that doesn't actually need hosting.

"It's a wrapper around fetch(). Why am I paying someone else's AWS bill to run it for me?"

The trust model second, because it's harder

The pricing was the prompt. The trust model was the reason.

Here's what happens when your agent calls a Composio tool, simplified:

agent  →  composio.dev  →  api.supabase.com
       ←     (proxy)    ←     (response)

Composio holds your auth token (encrypted at rest on their side, but decryptable by them). When your agent calls supabase_run_sql, the SQL goes through Composio's servers, they attach your token, they forward to Supabase, they receive the result, they forward it back to your agent.

That's a sensible design for what they do. It's also a design where a third party sees:

Every SQL query you run against your production database.
Every customer email you look up in Stripe.
Every file you read from a private GitHub repo.
Every customer ID, project name, and table name in your stack.

Composio's privacy policy says they don't snoop. I believe them. That's not the point. The point is the architecture permits snooping, and depends on their security posture continuing to be perfect against an attacker who really, really wants to read enterprise customer SQL traffic. That's a lot of Lindy time to bet on, for a 2-year-old startup.

For my use case — a solo dev's working credentials, against my own and my clients' production systems — the architectural hop is the wrong trade. There's no reason my SQL needs to transit a third party's servers when the only consumer is me, on my own laptop.

What I built

I built mcpvault. It's a single npm package — installed globally with npm i -g @elraian/mcpvault, configured with three commands, integrated into every chat client I use.

The architecture is the inverse of Composio's:

agent  →  mcpvault on my machine  →  api.supabase.com
       ←       (in-process)        ←     (response)

The vault file lives at ~/.mcpvault/vault.enc, encrypted with AES-256-GCM under a key derived from a master password via Argon2id (m=64MiB, t=3, p=1 — the OWASP recommended baseline). The derived session key is cached in my OS keyring (Keychain on macOS, DPAPI on Windows, libsecret on Linux) so I don't re-enter the password on every command.

When my agent calls supabase_run_sql, here's the path:

Cursor (or Claude Code, or Cline, etc.) spawns the mcpvault wrap supabase subprocess.
The subprocess reads ~/.mcpvault/active.json to find which Supabase account is currently active (e.g. client-acme).
It decrypts the credential for that account in-memory only.
It attaches the credential to an HTTPS request to api.supabase.com.
It returns the API response back over MCP to the agent.
It writes one line to ~/.mcpvault/vault.log: 2026-05-15T14:22:31Z supabase client-acme supabase_run_sql. No SQL body. No response. No credential. Just enough for me to answer "what did the agent touch and when".

No composio.dev in the path. No third-party logs. No hosted dashboard with my SQL queries waiting to be exfiltrated by a future intern who finds the wrong S3 bucket.

The multi-account thing is the actual feature

This bit is what made me stop using Composio specifically. I have three Supabase accounts: my personal, my work, and a freelance client's. Switching between them in Composio means either:

Maintaining three separate "Composio connections" and remembering which one I activated this session, or
Restarting the agent session every time I switch contexts, which defeats the point of "the agent works alongside me".

mcpvault solves this by making per-service wrappers re-read the active account label on every tool call. So this works:

Me: Hey, I'm working on Acme today. Switch all my accounts to client-acme and tell me how many open issues there are.

Agent: (calls mcpvault_activate_account('supabase', 'client-acme'), then mcpvault_activate_account('github', 'client-acme'), then github_list_issues({state: 'open'}))
You're on client-acme now. 7 open issues, 2 of them tagged "blocker".

Five minutes later in the same conversation:

Me: Switch back to my personal Supabase and check the migration status on the side project.

Done. No restart, no MCP reconnection. The wrappers just re-read active.json on the next call and the chat continues uninterrupted.

This pattern is the actual reason I stopped paying for hosted alternatives. Once you have it, you don't go back.

Who this isn't for

mcpvault wins for solo developers and small teams using AI for their own work. It loses for two groups:

People shipping agent products to end-users. If you're building a SaaS where your customers connect their own accounts, Composio is the right answer. You need OAuth flows for thousands of users, you need a hosted dashboard, you need them to not have to install a CLI. mcpvault is the wrong shape entirely. Use Composio (or roll your own OAuth layer).

People who genuinely need 500+ integrations on day one. mcpvault has four service wrappers in v1 — the developer-tool quartet of Supabase, GitHub, Vercel, Stripe. v2+ will add OAuth services (Gmail, Drive, Slack) and 1Password / Bitwarden adapters. It will never be 500. If you need Salesforce + HubSpot + Asana + Notion + Zoom + Slack + Jira now, mcpvault doesn't have them. Composio does. Pay them.

Who this is for

The other 80% of the people on Composio's free tier. Specifically:

Anyone with multiple personal/work/client accounts for the services mcpvault covers.
Anyone who doesn't want a third party seeing their SQL queries against production.
Anyone who's tired of subscription fatigue for tools that should be CLIs.
Anyone who values being able to read the source of the thing handling their credentials. mcpvault is MIT-licensed on GitHub.

How to migrate

If you're on Composio and want to try the local route:

Install mcpvault (npm i -g @elraian/mcpvault, then mcpvault init).
For each service Composio currently holds tokens for that mcpvault also covers (Supabase / GitHub / Vercel / Stripe): regenerate a fresh Personal Access Token from the upstream provider, then mcpvault add <service> and paste it.
Run mcpvault setup to wire mcpvault into your chat clients (auto for Claude Code, Claude Desktop, Cursor, Cline, Windsurf).
Restart the chat client.
Once you've confirmed the local setup works, revoke the Composio-issued tokens from each provider's dashboard. Your fresh local tokens take over and the old ones can't be replayed.

Total migration time: about 10 minutes if you have the upstream dashboards open and PAT-creation muscle memory. The two services run side by side cleanly during the transition — they're separate MCP servers in your client's config — so there's no flag day.

What I'm not claiming

mcpvault is better than Composio for everyone. It isn't. They're optimised for different users.

I built mcpvault for the segment of Composio's customer base who are on the free tier, paying $0/month, but providing Composio with the keys to their entire stack in exchange. That's a real cost too, just not a billable one.

If that segment is also you, install it. If it isn't, stay on Composio — it's a fine product, run by people who took the time to build a real company around the MCP spec, and they deserve their pricing.

mcpvault vs Composio — feature-by-feature comparison.
All Composio alternatives — six options ranked by trust model.
mcpvault security model — full cryptographic spec and threat model.
Install mcpvault — three-command quickstart.

Posted May 15, 2026. Written by AISIDE. mcpvault is open-source, MIT-licensed, and made because the author got tired of subscriptions.