Use an AI Agent to Deploy Docker Compose to GCP

When you use an AI coding agent to prepare a Docker Compose application for Google Cloud, keep the deployment plan in Compose. Defang can turn that service intent into GCP infrastructure after you review the file.

You get a readable deployment contract. Your agent can help edit compose.yaml, explain the intent, and prepare the deployment command instead of producing a new cloud-specific infrastructure project.

Prerequisites

Before deploying, the user needs:

• Defang CLI installed (brew install defang or npm i -g defang)
• Authenticated with defang login (this handles both Defang auth and can trigger GCP OAuth)
• GCP project identified (set GCP_PROJECT_ID, or the CLI will prompt during stack creation)
• A Defang stack targeting GCP: run defang stack new and select GCP when prompted for provider

Deployment path

After the Compose file is reviewed, deploy it with Defang:

defang login
defang stack new    # interactive: select GCP, choose region, name the stack
defang compose up

Use Defang Agent Skills

If you use Claude Code, Codex, or another coding agent, install Defang Agent Skills so the agent has Defang’s estimate, deploy, and debug workflows available in its own environment.

This path fits when:

• The repository already has a compose.yaml or docker-compose.yml.
• You want Google Cloud but do not want to hand-write cloud-specific deployment configuration.
• The app needs HTTPS, public services, logs, managed Postgres, Redis, MongoDB, or LLM access.
• You want your agent’s deployment changes concentrated in one file you can review.

Why this works well with coding agents

Coding agents are useful at editing structured text. Docker Compose is compact, reviewable, and familiar. It can define services, ports, environment variables, health checks, resource intent, and managed-service annotations in one place.

Defang maps that intent to Google Cloud services (Cloud Run for public-facing services, Cloud SQL for Postgres, Memorystore for Redis, Firestore for MongoDB, with Vertex AI access for LLM-enabled services). Instead of reviewing generated service, networking, identity, image registry, and managed dependency configuration, you review Compose and let Defang handle the cloud translation.

Guardrails to keep in Compose

Add health checks for public services. Declare required environment variables by name and store sensitive values using defang config set SECRET_NAME. Use managed-service annotations such as x-defang-postgres, x-defang-redis, and x-defang-mongodb when the app needs GCP-managed backing services (Cloud SQL, Memorystore, Firestore). Use x-defang-llm to configure Vertex AI access and, for supported model runner images, to provision an OpenAI-compatible LLM proxy.

services:
  web:
    build: .
    ports:
      - "3000:3000"
    environment:
      - DATABASE_URL
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3000"]
      interval: 30s
      timeout: 10s
      retries: 3

  db:
    image: postgres:17
    x-defang-postgres: true

Defang also supports Railpack, which can build and deploy apps without a Dockerfile. If the project has no Dockerfile, Defang will auto-detect the runtime.

Note: The image field (e.g., postgres:17) is required — Defang uses it to determine the managed service version. Locally, docker compose up uses the same image as a regular container. The x-defang- annotations are only interpreted by Defang during cloud deployment.

What to ask your agent to produce

Ask for a reviewed compose.yaml, a short explanation of which services are public, a list of required secrets to set with defang config set, and the final Defang commands. That keeps the deployment plan visible while still giving you a direct path to Google Cloud.