What does a PaaS look like when the developer is a coding agent?

Heroku showed that deployment becomes easier when developers work with application-level concepts instead of servers and cloud resources.

Coding agents reach a similar limit: they can change a database schema, write a background job, and add an SDK, but a feature that needs object storage, a worker, a secret, or more compute still sends someone to a dashboard, CLI, infrastructure repository, or platform team. The interesting possibility is not AI deploying code, which CI already handles, but giving the coding agent tools to configure the application's infrastructure.

Heroku solved an interface problem

Heroku reduced a large set of operational tasks to apps, dynos, config vars, add-ons, and releases. Attaching an add-on does not require the developer to choose where it runs or configure how the application finds it because the platform creates the service and normally supplies its connection details through config vars such as DATABASE_URL, as shown in Heroku's add-on documentation.

The infrastructure still exists, but the platform handles hosts, process supervision, traffic routing, and connections between services behind a simpler interface. That is useful for agents because "add PostgreSQL to this environment" can be a restricted operation with clear inputs instead of permission to create arbitrary IAM policies, subnets, virtual machines, firewall rules, and systemd units.

Coding agents reveal the next interface problem

Consider an existing document application with three components:

• A web service accepts uploads and search requests.
• PostgreSQL stores users, document metadata, and job state.
• A background worker performs document processing.

Now ask the coding agent to add a feature that requires changes to both the code and its infrastructure:

Add semantic search over uploaded documents. Store the original files in object storage and use a vector database for retrieval.

Although the code changes are substantial, they follow the feature directly: the web service needs an upload path, the worker must extract and divide the text into chunks, an embedding client must write vectors, and the search path must retrieve relevant chunks. Running that code also requires durable object storage, a vector database, private connections, credentials, storage volumes, and configuration shared by both processes.

With a conventional PaaS, the agent can implement the code and perhaps update an example .env file, but a person must still interpret those changes, create the services through a dashboard or CLI, copy endpoints and credentials, set production variables, deploy, and return any errors to the agent.

What MCP contributes

An agent can already run heroku, kubectl, terraform, or a cloud CLI, so MCP's value is not simply the ability to execute commands. A shell can grant far more access than the task requires while leaving the agent to assemble commands and interpret output written for humans, and a proprietary API requires a platform-specific integration. Model Context Protocol instead standardizes how an AI application discovers tools, learns what inputs they accept, and calls them.

Four layers have distinct responsibilities:

1. The model decides what the application needs.
2. MCP describes the tools and carries calls and results.
3. The PaaS's MCP server defines allowed operations and inputs.
4. The PaaS validates requests and applies infrastructure changes.

MCP does not choose the database or create it by itself: the model decides what to request, the protocol carries that request, and the platform performs a defined operation. The tool can therefore require replicas to be an integer and memory to fall within a valid range instead of accepting arbitrary shell input or requiring the agent to operate a dashboard.

The evolution is easier to see when the code and infrastructure paths are shown together:

The last model removes the need for a developer to translate between those paths, but it does not remove responsibility for architecture, permissions, review, cost, or incident response.

Building the semantic-search feature

If the team chooses MinIO for S3-compatible object storage and Qdrant for vectors, the target environment contains web, worker, Postgres, MinIO, and Qdrant, with only web exposed publicly, durable storage attached to both new services, and their credentials kept as secrets.

The agent must change the code and infrastructure together:

1. Inspect the existing services and configuration.
2. Add private MinIO and Qdrant containers from reviewed, version-pinned images, with persistent volumes and internal ports.
3. Create credentials and reference them from the web and worker rather than duplicating values.
4. Add the upload flow, indexing job, vector schema, retrieval path, health checks, and configuration validation to the repository.
5. Present the infrastructure diff for review, then inspect deployment state and logs after Apply so code or configuration failures can be corrected.

What this looks like in Suga today

Suga is a container PaaS whose environments keep an application's services, volumes, networking, and configuration together and separate from other deployments. Its hosted MCP server exposes that model to MCP clients over OAuth-authenticated HTTP.

We tested the infrastructure part of the example by giving a connected agent this deliberately short prompt:

Add a Qdrant vector store and a MinIO object store to my Suga environment. Wire QDRANT_API_KEY and S3_ACCESS_KEY on the web container so it can reach them.

After inspecting the environment, the agent added MinIO, Qdrant, and their configuration to the draft below, leaving three unpublished changes for a person to review.

The current server exposes a sequence of small, specific operations rather than one unrestricted "configure infrastructure" call:

Apply is not the only safeguard because the MCP tools cannot delete projects or environments, secrets remain write-only, and every action uses the connected user's permissions.

After Apply, the read tools shown above let the agent inspect the deployment and its runtime logs. If QDRANT_URL incorrectly points to localhost, for example, the agent can identify the refused connection, update the draft to use Qdrant's private hostname, and return another review link, but it cannot deploy the correction silently.

What infrastructure tools must guarantee

If an agent can change infrastructure, the platform tools it calls must be safe and predictable:

• Separate permissions: Reading, drafting, deploying, deleting, and accessing secrets should not require the same level of access, while production should use narrower permissions and more approval gates than development.
• Clear rules: The model may choose the wrong service or size, but each tool should reject invalid input, behave consistently, and return errors the agent can understand.
• Safe retries: Repeating a request should not create a duplicate service or apply the same change twice, which platforms can prevent with idempotency keys or consistent update-or-create behavior.
• Useful failure data: Deployment state, build output, logs, health, endpoints, and metrics need stable identifiers so the agent can investigate failures without a person relaying the evidence.
• Cost controls: Resource ceilings, quotas, cost previews, and approval thresholds should prevent a technically valid request from creating an unexpectedly expensive environment.

MCP is one interface, not the only interface

The lower-level tools discussed earlier remain preferable when a setup must work across providers, an existing infrastructure-as-code process already controls changes, or the task falls outside what a PaaS supports. Terraform can keep networking and IAM for several providers in version control, while Kubernetes offers a broad resource API and mature permission controls.

How much infrastructure detail an agent should manage determines which interface fits, and HashiCorp's Terraform MCP server, which disables destructive operations by default, shows that MCP can also work with infrastructure as code. A PaaS MCP server fits when the tools should stay focused on the application: inspect an environment, add a service, connect variables, show the pending change, retrieve a failed build, and report whether the release became healthy.

What could come next

What if a reviewer could evaluate the code diff, infrastructure diff, cost impact, required permissions, and test plan as one application change? That would turn today's separate code and PaaS reviews into one clear decision without giving the agent unrestricted production access.