Cursor, with its latest model Composer 2.5, turns a description of a service into a working backend. Running that backend on cloud infrastructure has been a separate, manual step. Encore brings that step into the same code: the agent declares the infrastructure a service needs (databases, queues, cron jobs, and more), and Encore provisions it into your own AWS or GCP account.

We have built Encore around that idea for years, and it is the model AI turned out to need: the infrastructure lives in the application's code, with no detached Terraform project to maintain alongside it. It is also built for the part teams are careful about, letting an agent near a cloud account: the platform team sets the boundaries for what an agent can create and how large it can be, so the agent moves quickly while the team keeps control. Today, more than 200 teams build on it, its open source framework has passed 12,000 GitHub stars, and applications running on it serve billions of requests in production.

The rest of this post is how that works with Cursor, from writing a service to running it in production.

Declaring infrastructure in the code Cursor already writes

In Encore, a database or a Pub/Sub topic (or a cache, cron job, object storage bucket, or secret) is an object you create in Go or TypeScript, right next to the code that uses it, rather than in a separate config file. The footprint is small: a few imports and declarations, with the rest of the service left as ordinary Go or TypeScript.

import { api } from "encore.dev/api";
import { SQLDatabase } from "encore.dev/storage/sqldb";
import { Topic } from "encore.dev/pubsub";

// A database and a Pub/Sub topic, declared in the service that uses them.
// Caches, object storage, cron jobs, and secrets are declared the same way.
const db = new SQLDatabase("users", { migrations: "./migrations" });

interface SignupEvent {
  userID: string;
}
const signups = new Topic<SignupEvent>("signups", {
  deliveryGuarantee: "at-least-once",
});

// A typed endpoint. Encore generates the API docs and typed clients from these
// types, computes the least-privilege IAM the service needs, and traces every
// request and query without instrumentation.
export const register = api(
  { expose: true, method: "POST", path: "/users" },
  async (params: RegisterParams): Promise<{ id: string }> => {
    const user = await createUser(db, params);
    await signups.publish({ userID: user.id });
    return { id: user.id };
  },
);

When Cursor writes that, it provisions a Postgres database and a topic as part of writing the endpoint, so there is no separate infrastructure file to keep in sync. The topic is typed, so publishing the wrong message to it is a compile error on the line the agent just wrote, caught in the same loop rather than by another service in production. Encore reads the same declarations to generate the service's API docs and typed clients and to work out the IAM it needs, so what the agent builds stays auditable: the platform team can see which service uses which resource, and why. And because all of this is ordinary code, whether a change is safe to ship stays a decision the reviewer makes, on the same pull request as everything else.

Guardrails for AWS and GCP

An agent can provision the databases, queues, caches, and other resources an app runs on. What gets created is split between the agent and the team: the agent declares those resources in the code, and the settings that carry real cost and risk, like instance sizes and replica counts, stay out of the code, where the platform team sets them from the Encore dashboard or your cloud console, or leaves Encore's defaults in place. Because those bounds hold whatever the agent creates, a new resource is safe to provision even when no one reviews it first, so engineers move at their own pace instead of waiting on the platform team to clear each change. Teams that want a closer eye can turn on infrastructure approval, where a platform admin approves or rejects the planned change in the Encore dashboard before it goes out. Either way, provisioning happens with least-privilege permissions, sized the way the team decided rather than the way the agent guessed. The agent never holds a cloud credential of its own.

Giving Cursor the live picture with MCP

Some mistakes depend on how the system behaves, and for those the agent needs to see the system. That is what Encore's MCP server gives Cursor. Through it the agent reads the real schema and writes a query against the columns that exist instead of guessing at names, and it can call its own endpoints and read the traces that come back to confirm the query it meant to run is the one that ran. It works from what the system does rather than from what the model assumed, which is where most of the wrong guesses started.

What the loop looks like

A change and the infrastructure it needs move through as one pull request. The developer asks Cursor for a feature, the agent writes the service and declares the database or queue in the same code, and Encore stands up a full preview environment for that pull request with the new infrastructure provisioned. Cursor can call the endpoints in that environment and read the traces to confirm the change behaves the way it should, and a reviewer can open the same environment and try it by hand before it reaches production.

Merging the pull request is what ships it. The declarations that built the preview environment provision the change into your own cloud, so what the team approved is what runs, and the tracing and API docs Encore generated carry through to production. The infrastructure was never a separate task sitting in another queue behind the code.

What Encore adds to your Cursor workflow

The pieces above come together into a single platform. From the first line of code to production traffic, here is what building on Encore gives a Cursor agent:

• Live introspection: Cursor reads your app's architecture, APIs, data, and traces through Encore's MCP server.
• End-to-end type safety: typed APIs, clients, and resources, so a bad call or a wrong message fails at compile time instead of in production.
• Infrastructure orchestration: local and cloud infrastructure provisioned automatically, into your own AWS or GCP account.
• Standardized API and service design: consistent patterns for APIs and services across the codebase.
• Automated documentation: API docs and architecture diagrams generated from the code.
• Built-in observability: every request traced through local and cloud infrastructure, without extra instrumentation.

The part that was left

The slow part of shipping has always come after the code: getting it running on cloud infrastructure a team is accountable for. That is the part we have spent years building Encore to solve, by keeping infrastructure in the code that uses it and provisioning it into your own cloud, inside bounds the platform team sets. This is how backends get built from here, and it is what makes it safe to let an agent near a cloud account at all.

You can try it today. Encore is ready for Cursor out of the box: when you create an app it sets up the rules and MCP connection for the agent you use, so Cursor can build and provision from the start.

Prefer to read first? The quick start walks through building an app, and the AI integration guide covers the Cursor setup.