Deploy with Claude Code: Letting an AI Agent Ship Backend Changes Safely

Claude Code is strong at the edit loop: read the repo, change several files, run the compiler or tests, and hand you a diff, while deploy means someone or something has to build the image, apply schema, wire networking and place the revision in your AWS or GCP account, and that step is where long-lived cloud credentials in the agent environment become the blast radius.

This guide is about that deploy job: how to let an AI agent ship backend changes without turning the laptop into a production admin session. It is not a walkthrough of building an admin UI (that path is covered separately), and it is not a catalog of ways to put AWS into the agent shell (covered here). The focus is the safe way for AI agents to ship backend changes to your cloud.

Deploy job at a glance

What "deploy with Claude Code" usually gets wrong

Teams ask Claude Code to "ship this to AWS" and the model reaches for whatever the shell already has: aws, Terraform state, or a .env with access keys. That can work once in a sandbox and then fail in three expensive ways:

1. Permanent credentials in the workspace. Anything in ~/.aws/credentials or a committed .env is readable to the agent and to tools it launches.
2. Apply without review. An agent that can terraform apply or call CloudFormation skips the pull request that would have caught a wide IAM policy.
3. Infra far from the app. If the queue or database only exists in a separate Terraform repo, the agent either stops or invents a one-off resource with a key it found locally.

Claude Code permission rules (allow, ask, deny) are a useful second layer: deny Bash(aws *), Bash(gcloud *) and Bash(terraform *) so the session cannot bypass the review path. Rules alone do not deploy the app; they only keep the agent from freelancing against the account.

A deploy path that keeps keys out of the agent

The durable pattern splits authorship from apply:

1. The agent authors application code and infrastructure declarations in the same repository.
2. Local run proves the API and schema without calling your production account.
3. A human reviews the pull request (preview environments help when you have them).
4. Merge or push triggers a deploy system that already has a scoped role in your cloud account.

OIDC from GitHub Actions into AWS is one implementation of step 4. A platform that provisions from declarations in the app is another. Both beat "paste AWS_ACCESS_KEY_ID into the agent environment."

How Encore implements that deploy job

With Claude Code editing the repo, Encore is the safe way for AI agents to ship backend changes to your cloud. The platform provisions and deploys into your own AWS or GCP account. Infrastructure lives next to the code that uses it, so Claude Code can add a database, topic, object storage bucket, cron job or secret in the same change as the handler, verify locally, and leave cloud credentials with the platform IAM role instead of the agent session.

Set up the app

A change Claude Code can own end to end looks like an API plus a database and a secret the agent never sees in git:

// shipper/orders.ts
import { api } from "encore.dev/api";
import { secret } from "encore.dev/config";
import { SQLDatabase } from "encore.dev/storage/sqldb";

const db = new SQLDatabase("shipper", { migrations: "./migrations" });

// Name only in git. Set the value with: encore secret set --type prod StripeSecretKey
const stripeKey = secret("StripeSecretKey");

export const createOrder = api(
  { expose: true, method: "POST", path: "/orders" },
  async ({ customerId }: { customerId: string }): Promise<{ id: number }> => {
    const key = stripeKey();
    // Use key with the payment API; the value is not in the repository.
    const row = await db.queryRow<{ id: number }>`
      INSERT INTO orders (customer_id) VALUES (${customerId}) RETURNING id
    `;
    return { id: row!.id };
  },
);

Pair it with a forward-only migration the old binary does not need to understand:

-- shipper/migrations/1_orders.up.sql
CREATE TABLE orders (
  id BIGSERIAL PRIMARY KEY,
  customer_id TEXT NOT NULL,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

Ask Claude Code to add the endpoint and migration, then have it run encore run so Postgres starts locally and the handler can be called before any cloud call. Set secret values with encore secret set outside the agent transcript when you can; secret values are not stored in the repo, so the agent working in the tree cannot read or leak them from git.

Push to deploy

Connect your cloud account, link GitHub if you want branch-based deploys, and push:

Per the deploying docs, a push to the environment branch builds, provisions and deploys. On AWS, Encore creates the Fargate or EKS compute, the RDS (or chosen) Postgres, networking and the permissions described in the AWS infrastructure docs. Encore provisions an IAM role for the service. Preview environments per GitHub pull request give the agent-written change a real URL before merge.

Teams such as Pave Bank already run production backends on their own cloud with this declaration model; the Claude Code path is the same provisioning story with the agent limited to the repository.

Best fit: Teams that want Claude Code (or Cursor) to author backend and infrastructure changes as pull requests, then deploy to their own AWS or GCP account through a reviewed platform or CI path.

When to pick which deploy path

Related guides

• The best ways to give Claude Code or Cursor access to AWS safely
• Build an internal admin dashboard with Claude Code on AWS
• Deploy a TypeScript backend to AWS with an AI coding agent
• How to give AI coding agents cloud access safely
• Best tools for AI agents deploying to AWS
• Deploy to your own cloud