You're a developer. You have an idea, a blank directory, and some version of an evening free. You don't want to become an infrastructure engineer. Here's how to pick the right CLI tool for the job.
Every few years, the "right way" to provision a dev stack shifts. It went from manually SSH-ing into a VPS, to clicking through cloud consoles, to writing YAML for Kubernetes. Each iteration got more powerful—and more complex.
Right now, there are two very different CLI traditions for provisioning infrastructure, and they're solving different problems. One is built for platform teams managing production systems at scale. The other is built for developers who want a running app, not a new job.
Knowing which camp a tool belongs to will save you a lot of time.
Two worlds, two tools
The DevOps world built Terraform, Pulumi, and friends to manage infrastructure at scale—thousands of resources, multiple environments, complex dependency graphs. These tools are excellent at what they do. They are also, by design, general-purpose infrastructure orchestrators. Getting one running for a new project means learning a DSL or SDK, managing state backends, setting up provider credentials, and writing declarations before you can run anything.
That's the right trade-off when you're provisioning production infrastructure for a 50-person engineering team. It's the wrong trade-off when you're trying to get a database running for the side project you promised yourself you'd finally ship.
The developer-first world has been building something different: tools where a single command provisions a real service, returns your credentials, and gets out of the way. The job isn't "manage infrastructure"—it's "set up a stack so I can write code."
Here's how the main options compare.
The tools
Terraform / OpenTofu
The most widely-used infrastructure provisioning tool in existence. Terraform's CLI is mature, well-documented, and backed by a massive provider ecosystem. OpenTofu is its open-source fork, with active development and near-identical syntax.
What it does well: Large-scale, multi-cloud infrastructure management. Audit trails. State management. Plan-before-apply safety. If you're managing production systems and need policy, governance, and repeatability, Terraform is the standard for a reason.
Worth knowing: The learning curve is real. Before you can provision a database, you're initializing a state backend, creating a main.tf, and understanding provider authentication. The feedback loop is slow. And because it's designed for IaC at scale, it treats every service as a resource to declare—not a thing to quickly spin up.
Best for: Platform engineers and DevOps teams managing production infrastructure. Not the right tool if you just want a Postgres database by tonight.
Pulumi
Pulumi takes the Terraform model and lets you write infrastructure in a real programming language—TypeScript, Python, Go, C#. For developers who already know those languages, this removes the HCL learning curve.
Pulumi is actively investing in agentic provisioning workflows (their "Pulumi Neo" work moves in this direction), which puts it on a path toward the developer-first world. But it still requires a Pulumi account, a state backend, and enough infrastructure literacy to write a meaningful program before you see results.
What it does well: IaC in a language you already know. Solid multi-cloud support. Good for organizations that want programmable infrastructure without HCL.
Worth knowing: Still fundamentally an IaC tool. The complexity floor is lower than Terraform's, but it's not zero. Agents can invoke Pulumi, but they need a well-structured program to run—you don't get an out-of-the-box agent-ready workflow.
Best for: Developer-friendly infrastructure teams and engineers who want IaC power with a familiar language.
Platform CLIs (Vercel, Railway, Render, Fly.io)
Each of these has a solid CLI that can provision and deploy applications quickly. vercel deploy. railway up. fly launch. If your app fits neatly on one of these platforms, their CLIs are genuinely fast and pleasant to use.
The limitation is scope. Each CLI talks to exactly one provider. Take Railway: railway up gets your app deployed in seconds. But the moment your app also needs AI inference from OpenRouter, error monitoring from Sentry, and a background job queue from Inngest, the Railway CLI has nothing to offer. Those are separate signups, separate dashboards, and three more sets of credentials to track down and maintain.
What it does well: Fast deployment within a single provider's ecosystem. Low ceremony for the simple case.
Worth knowing: Most apps are multi-service from day one. Every service that lives outside your primary host is a manual credential workflow your CLI can't help with.
Best for: Apps that fit cleanly within a single provider's world.
Stripe Projects
Stripe Projects is a Stripe CLI plugin that takes a different approach to the whole problem. Instead of being a tool you write infrastructure code with, it's a catalog of real services—databases, hosting, auth, AI providers, analytics, monitoring—that you add to your project with a single command.
stripe projects add neon/postgresThat command creates a real Neon database, generates your credentials, and writes them to your project's .env. No provider dashboard, no API key hunting, no copy-paste. The same command works for 33 providers: Supabase, Vercel, PlanetScale, Clerk, WorkOS, OpenRouter, Upstash, Sentry, Cloudflare, and more.
All of them run their billing through Stripe. One payment method on file, and spend across every provider is visible and manageable from a single place.
stripe projects add supabase/postgres
stripe projects add vercel/project
stripe projects add clerk/auth
stripe projects add sentry/monitor
stripe projects env --syncWhat it does well: Zero-friction provisioning for common developer services. Credentials are managed for you and stay in sync. Multi-provider stacks become a list of commands. And because the CLI is designed to run non-interactively, it works just as well when invoked by a coding agent as it does when you run it yourself.
Worth knowing: Stripe Projects is a developer tool, not an IaC system. It doesn't manage infrastructure state, handle complex networking configurations, or give you a Terraform-style plan-before-apply safety model. For the app with 800 microservices and a dedicated platform team, it's not the right layer. For the developer building a product, it is.
Best for: Solo developers, early-stage teams, builders, and AI-native workflows where the goal is a running stack, not a managed infrastructure system.
How they compare
| Terraform / OpenTofu | Pulumi | Platform CLIs | Stripe Projects | |
|---|---|---|---|---|
| Setup time | 30–60 min | 20–40 min | 5 min | < 5 min |
| Multi-provider | ✓ | ✓ | ✗ | ✓ (33 providers) |
| Credential management | Manual | Manual | Per-provider | Automatic |
| Centralized billing | ✗ | ✗ | ✗ | ✓ (via Stripe) |
| Agent-friendly | With wrappers | With wrappers | Partial | Built-in |
| State management | ✓ | ✓ | ✗ | ✗ |
| Learning curve | High | Medium | Low | Very low |
| Best use case | Prod infra at scale | Prod infra, IaC-as-code | Single-platform apps | Developer stacks |
How to pick
You're building a product and need a running stack tonight. Use Stripe Projects. It's the fastest path from empty directory to live services with wired credentials.
You're deploying to one platform and staying there. Use that platform's CLI. If your app lives entirely on Vercel, the Vercel CLI is fast and purpose-built.
You're a developer who wants infrastructure-as-code without HCL. Use Pulumi. It's genuinely more ergonomic than Terraform for developers already comfortable with TypeScript or Python.
You're a platform or DevOps engineer managing production infrastructure. Use Terraform/OpenTofu. The ecosystem, the provider coverage, and the plan-apply model exist for a reason.
You're building with coding agents—Cursor, Claude Code, Codex—and want them to provision services as part of the build loop. Use Stripe Projects. It's designed to be invoked non-interactively, returns structured outputs, and handles the credential handoff that agents can't do through a browser.
Getting started with Stripe Projects
Install the Stripe CLI and the Projects plugin:
brew install stripe/stripe-cli/stripe
stripe plugin install projectsInitialize a project in your working directory:
stripe projects initAdd your first service:
stripe projects add neon/postgresThat's a real Neon database. Your DATABASE_URL is now in .env. You didn't need to create a Neon account, generate an API key, or copy a connection string.
The full provider catalog covers databases, hosting, auth, AI inference, queues, analytics, monitoring, and more—any combination of which becomes a list of stripe projects add commands.
Ready to set up your first project? See the quickstart guide or browse the provider catalog.