Provision SaaS Services and Sync Credentials with Stripe Projects

This skill wraps the Stripe Projects CLI plugin so Hermes Agent can provision SaaS services like Neon, Twilio, and Vercel, generate and sync credentials into the user's .env, and manage billing across providers from one place. It is gated to linux, macos while the broader payments cluster matures on Windows; the Stripe CLI itself is cross-platform, so this gate is a posture for the cluster, not a hard limit.

What it does

Stripe Projects is a CLI plugin that turns a Stripe account into a provisioning hub. You add a provider and service (for example, neon/postgres), and Stripe Projects creates the resource in your own account with that provider, generates the connection credentials, writes them into your local .env file, and stores an encrypted record in a project vault. The same tool handles tier upgrades, credential rotation, and deprovisioning. For Hermes, this means a single natural-language request can spin up a Postgres database, a Twilio SMS number, or a Vercel project without you leaving the terminal.

Before you start

• Stripe CLI must be installed. On macOS, use Homebrew; on Linux, use your package manager or download from https://docs.stripe.com/stripe-cli/install.
• Stripe Projects plugin must be installed on top of the CLI.
• A Stripe account is required. If the user does not have one, the CLI can guide them through sign-in or account creation in the browser during the first setup.
• Platform limits: the skill is gated to linux, macos. The Stripe CLI itself runs on Windows, but the broader payments cluster is not yet tested there.

Install

macOS:

brew install stripe/stripe-cli/stripe
stripe plugin install projects

Linux: follow the platform-specific install at https://docs.stripe.com/stripe-cli/install, then:

stripe plugin install projects

How to run

All commands run through the terminal tool from inside the user's project directory. The CLI writes .env and .projects/vault/vault.json into the current working directory, so run these from the root of the project that needs the credentials.

Procedure

1. Initialize the project

cd <project-root>
stripe projects init

This creates .projects/vault/vault.json (an encrypted credential store) and prepares the project to receive providers. Run this once per project.

2. Discover available providers

stripe projects catalog

Lists every provider Stripe Projects supports: databases, hosting, auth, AI, analytics, messaging, and more. The output is a flat list of provider/service pairs. If you are looking for something specific, pipe through grep before calling add.

3. Add a service

stripe projects add <provider>/<service>

Examples:

• stripe projects add neon/postgres
• stripe projects add twilio/sms
• stripe projects add runloop/sandbox

The CLI provisions the service in the user's own account with the provider, generates credentials, syncs them into .env, and records the resource in the vault. The user may need to confirm a tier selection or pricing prompt.

4. Verify

stripe projects list

Should show the newly added provider and its .env keys.

5. Manage / upgrade / remove

stripe projects upgrade <provider>     # tier change
stripe projects remove <provider>      # deprovision
stripe projects rotate <provider>      # rotate credentials

When not to use it

If the user already has a provider account, this skill can still connect it with stripe projects link. However, if the user wants to use an existing provider resource (such as an existing database or Vercel project), check provider support first: many providers currently support provisioning new resources but not importing existing ones. In that case, you would need to manage the resource directly through the provider's own CLI or dashboard.

Limits and gotchas

• .env writes are real writes. The CLI appends to whatever .env is in the project root. If the user's .env is gitignored (normal), the keys land safely; if not, this skill could be a credential-leak vector. Always check .gitignore first.
• Per-project state. .projects/vault/vault.json is per-project. Provisioning the same service in two different projects creates two separate resources and two bills.
• Billing happens on Stripe's side. Tier prompts during add/upgrade are real charges; surface them to the user before confirming.
• Provider availability changes. The catalog grows; if a provider the user names is not listed, stripe projects catalog | grep first instead of failing the add call.
• Credentials in vault are encrypted but .env is plaintext. Standard .env hygiene applies: never commit it.
• Removing a service does NOT always destroy the underlying resource. Some providers leave a paused/dormant resource behind. Check the provider's own dashboard after remove for high-cost services (managed databases especially).

Verification

stripe projects --version && stripe projects list

Exit code 0 inside an initialized project means the plugin is healthy.

Related skills

• stripe-link-cli for linking existing Stripe accounts
• mpp-agent for multi-provider provisioning coordination