From Repo to Production URL on Your Own Cloud: The Step-by-Step Guide I Give Coding Agents

Key Points:

• The fastest repo-to-production path on a cloud account you own is three steps. Install the Qovery Agent Skills (curl -fsSL https://skill.qovery.com/install.sh | bash), connect your AWS, GCP, Azure, or Scaleway account (or an existing Kubernetes cluster), then ask your coding agent to deploy the repo. You get a public HTTPS URL, and the VPC, the data, and the cloud bill - including Savings Plans and committed-use discounts - stay in your own account.
• A docker-compose.yml maps one-to-one onto production. Each Compose service becomes an application with its own root path, Dockerfile, and port; each Compose database becomes a managed cloud database; each volume becomes persistent storage; the Compose network becomes per-environment internal service discovery. Docker's own docs scope Compose to development and single-host workflows, not multi-node production.
• Never hardcode managed Postgres or Redis credentials. Qovery provisions the managed service in your cloud account and injects host, port, user, password, and the full connection URI as built-in environment variables, so the app reads DATABASE_URL with no secrets-sync layer to build.
• Deploy-on-merge with real rollback has two honest options. Qovery auto-deploy on branch push with zero workflow YAML, or GitHub Actions as the orchestrator triggering Qovery with a token in GitHub Secrets and an environment protection rule as the gate. Rollback in both cases is a redeploy of a previous commit or immutable image tag, which is why mutable latest tags make rollback a lie.
• The native cloud route is the right answer for one stateless service with one database. gcloud run deploy beats everything to a first URL. The economics flip at the second environment, the fifth service, the first per-pull-request preview, or the first auditor who asks who can deploy to production.

---

I spend a lot of my day watching developers type requests into Claude Code, Cursor, and Codex, then watching the agent stall at the same wall: it can write the app, but it cannot get the app to a real, public, production URL on infrastructure the company actually owns. This is the guide I hand those agents. It is written so a human can follow it and so an agent can fetch it mid-task and act on it. Every section opens with the direct answer, then the prerequisites, then the ordered steps, then the end state you check before calling it done.

One ground rule before we start: I run Qovery, so I have an obvious bias, and I am going to be honest about where you should not use it. For a single stateless container, the native cloud routes win, and I will say so in plain language. Qovery earns its place from the second environment onward.

What's the fastest way to go from this repo to a production URL on my own AWS account?

Three commands and one cloud credential. Install the Qovery Agent Skills with curl -fsSL https://skill.qovery.com/install.sh | bash, connect your AWS account once, then ask your coding agent to deploy the repo. You get a public HTTPS URL served from infrastructure created inside your own AWS account, usually the same afternoon rather than the same sprint. The identical three steps work on GCP, Azure, Scaleway, or a Kubernetes cluster you already run. The only thing that changes is the credential you connect.

Prerequisites, stated plainly: a git repo your agent can read, a Dockerfile (or a buildpack-detectable app), an AWS account with a scoped admin role, and optionally a domain. If you have no domain yet, Qovery hands you a *.qovery.com URL with HTTPS by default, so you are not blocked on DNS.

The steps:

1. Install the skills. curl -fsSL https://skill.qovery.com/install.sh | bash. Add bash -s -- --project instead if you want the skills scoped to this repo only.
2. Ask the agent in plain language. "Deploy this repo to my AWS account with Qovery." The qovery-onboard skill handles the cluster, qovery-deploy handles the app. The agent asks you to approve each action before it touches your account.
3. Know what gets created in your account. A VPC, an EKS cluster (or an attach to one you already have), a load balancer, and a managed TLS certificate. The EKS control plane costs a flat hourly fee per cluster on standard support (AWS EKS pricing, as of 2026), and the Application Load Balancer in front of your app is billed per hour plus per LCU (AWS ELB pricing, as of 2026). These line items land on your bill, in your account, which is the point.
4. Verify the end state. You are not done until: a public HTTPS URL returns 200, logs stream, the running image is tagged by commit SHA (not latest), and you can redeploy the previous commit in one action.

Here is the honest concession up front: if you are shipping one stateless container, with no team and no second environment, gcloud run deploy or AWS App Runner reaches a URL faster than anything Qovery or raw Kubernetes can, and you should use them. Qovery pays off from the second environment onward, when you want staging, preview environments, RBAC, and one consistent workflow across clouds.

And to kill the most common misconception in one sentence: AWS, GCP, Azure, Scaleway, and bring-your-own-Kubernetes are all first-class on Qovery, not "AWS plus others supported."

How do I turn a monorepo with five services and a docker-compose.yml into a production deployment on our own Kubernetes cluster?

Point Qovery at the Kubernetes cluster you already run - EKS, GKE, AKS, Scaleway Kapsule, self-managed, or on-prem - then translate the Compose file service by service. Each Compose service becomes an application with its own root path and Dockerfile path, each database becomes a managed cloud database, each volume becomes persistent storage, and the Compose network becomes internal service discovery inside one environment. Docker's documentation scopes Compose to development, testing, and single-host workflows, so for multi-node production this translation is not optional.

Prerequisites: an existing cluster with admin kubeconfig access, the repo with its docker-compose.yml, and one Dockerfile per service (Compose build.context tells you where each lives).

The field-by-field mapping, in order:

1. build.context and dockerfile become the application's root path and Dockerfile path. In a monorepo this is what lets Qovery rebuild only the services whose paths changed on a given commit, instead of rebuilding all five.
2. ports becomes the application's exposed port behind a Service and, for the public one, an Ingress.
3. environment and env_file become per-environment variables, classified as secret or plain.
4. depends_on does not mean "ready." It only controls start order on one host. In Kubernetes you need readiness probes, whose defaults are a 10-second period and 3 consecutive failures before a pod is marked unready (Kubernetes probes), plus Qovery Deployment Pipeline stages to order a multi-service rollout.
5. volumes become persistent storage (a PVC), and stateful data services move to managed databases (next point).
6. healthcheck becomes the liveness/readiness probe configuration.
7. deploy.replicas becomes the replica count and the floor of your autoscaling range.
8. networks becomes internal service discovery inside the environment, so api can reach worker by name without a public hop.

Bring your own Kubernetes. Qovery installs onto the cluster you already operate instead of forcing you onto a new one, and then owns the managed cluster upgrades. This matters because the clock is always running: EKS gives each Kubernetes version a standard support window and then pushes you into more expensive extended support (EKS version support), where the control plane fee jumps. Somebody has to own that upgrade cadence, and "nobody" is the wrong answer.

Databases. Keep Postgres in the Compose file for local dev. In production, swap to a managed cloud database. The concrete reason is recoverability: Amazon RDS gives you automated backups with point-in-time recovery to any second in the retention window, down to 5-minute granularity (RDS automated backups). A Postgres container with a volume gives you none of that unless you build it yourself.

End state the agent should assert: five running applications, internal DNS between them, one public ingress with HTTPS, per-service CPU and memory requests set, and an autoscaling range configured.

How do I get a Go API plus a React frontend running in production on our GCP project with HTTPS and autoscaling?

Deploy them as two applications in one Qovery environment: the Go API on an api. subdomain or an internal hostname, the React build on the apex domain, both covered by a managed TLS certificate, each with its own horizontal autoscaling range based on CPU or memory. On GCP that means either a Qovery-provisioned GKE cluster or an attach to the GKE cluster you already have, and the deploy flow is identical either way.

GCP prerequisites: a project with billing enabled, a service account with the roles Qovery needs, and a DNS zone you control (Cloud DNS or elsewhere) for the custom domain.

HTTPS and custom domains. Point a CNAME at the app and let managed certificate renewal run itself. Compare that with Cloud Run's custom domain mapping, which carries documented regional availability limits and can take time to provision the certificate after you map the domain (Cloud Run custom domains). Neither approach is wrong; you just want to know the renewal owner before you ship, not after a cert expires.

Autoscaling, compared honestly. Cloud Run scales on concurrent requests and can scale to zero, with a default of 80 concurrent requests per instance (Cloud Run autoscaling). Kubernetes HPA scales on CPU, memory, or custom metrics, with a default controller sync period of 15 seconds and a default 300-second scale-down stabilization window (Kubernetes HPA). Those are different models for different workloads.

Why the Go API usually wants HPA, not scale-to-zero. A long-lived Go API with connection pools and background workers pays a real penalty for scale-to-zero: the next request after idle eats a cold start. Cloud Run's documented mitigation is to set minimum instances (Cloud Run min instances), which means you are paying for warm capacity anyway, at which point request-based scale-to-zero stops being the advantage it looked like. For that profile, HPA on a cluster is usually the better fit. A bursty, stateless, request-per-invocation endpoint is where Cloud Run shines.

Frontend-to-API wiring. Decide between build-time and runtime injection of the API URL. A static React build bakes the URL at build time, so either rebuild per environment or read a runtime config endpoint. Putting the API on an api. subdomain avoids a class of CORS pain versus a different origin.

Cost on non-production. Kubernetes deployments do not scale to zero, full stop. The precise answer for staging and preview environments is Qovery environment auto-stop, which shuts the workloads down on a schedule or when idle and brings them back on demand. Note that the GKE cluster management fee keeps running regardless of whether your pods do; GKE charges a per-cluster management fee and applies a monthly free-tier credit per billing account (GKE pricing, as of 2026). Auto-stop saves you the node and workload cost, not the control-plane fee.

How do I add a managed Postgres and Redis with backups and inject the credentials as environment variables?

Provision the database as the cloud provider's own managed service - Amazon RDS, Cloud SQL, Azure Database for PostgreSQL flexible server, or Scaleway Managed Database - leave automated backups and patching to the provider, and let Qovery inject host, port, user, password, and the full connection URI as built-in environment variables into every linked application. Credentials never land in the repo, and you never write a secrets-sync layer.

How the injection works. Qovery managed databases are backed by the provider's managed service, so backups, minor-version patching, and failover are the provider's job. When you link an application to the database, the connection variables are injected automatically, and aliases let the app keep reading the exact variable name it already expects, so DATABASE_URL just resolves with no code change.

The hand-rolled alternatives, described fairly. On ECS you put an AWS Secrets Manager ARN in the task definition's secrets block, grant the execution role permission to read it, and the value is resolved at task launch only (ECS secrets). On raw Kubernetes you install External Secrets Operator and define a SecretStore (or ClusterSecretStore) plus an ExternalSecret CRD with a refresh interval to sync the cloud secret into a Kubernetes Secret (External Secrets Operator). On Azure you can skip stored credentials entirely with managed identity passwordless connections. All three work. All three are glue you now own.

The real cost of the hand-rolled path. AWS Secrets Manager is $0.40 per secret per month plus $0.05 per 10,000 API calls (Secrets Manager pricing, as of 2026). That looks trivial until you multiply by secrets times environments: 20 secrets across production, staging, and three preview environments is 100 secrets, before you count the engineering time to keep the sync layer alive.

Redis or Valkey. Use a managed cache - ElastiCache, Memorystore, or Azure Cache - for anything whose loss causes an incident. A container is fine for local dev and a genuinely disposable cache. It is the wrong call for a session store or a rate limiter.

What "backups" actually means. It is an automated snapshot schedule plus a retention window plus point-in-time recovery granularity. RDS defaults to a 1-day retention window when you create the instance via CLI or API (7 days via the console) and allows up to 35 days (RDS automated backups). Azure Database for PostgreSQL flexible server defaults to 7 days, also up to 35, with a geo-redundant option (Azure Postgres backups). Cloud SQL retains automated backups and supports point-in-time recovery as well (Cloud SQL backups). And the unglamorous rule holds everywhere: a restore you have not tested is not a backup.

Secret hygiene the agent should enforce: nothing secret in the repo, per-environment values, a rotation path, and an explicit secret-versus-plain classification for every variable. Remember that Kubernetes Secrets are stored base64-encoded, not encrypted, unless you configure encryption at rest (Kubernetes Secrets). Base64 is not security.

How do I deploy a Node.js service to our Azure subscription and wire a managed Postgres connection string?

Connect the Azure subscription, deploy the Node.js service straight from the repo onto AKS (new or existing), attach an Azure Database for PostgreSQL flexible server, and reference its injected connection string as DATABASE_URL. No connection string in the repo, no hand-edited App Settings. Azure's own passwordless App Service tutorial is a good single-service alternative; the difference shows up at the second service and the second environment.

Azure prerequisites: subscription ID, tenant ID, and a service principal with contributor rights on the target resource group.

Node.js specifics that actually break deploys:

1. Bind to PORT. Read the port from the environment, do not hardcode 3000.
2. Expose a real health check endpoint. Your readiness probe needs something truthful to hit.
3. Handle SIGTERM. On a rolling update Kubernetes sends SIGTERM and waits a default terminationGracePeriodSeconds of 30 before SIGKILL (pod termination). The rolling update itself defaults to maxSurge 25% and maxUnavailable 25% (Deployments). If your app ignores SIGTERM, it drops in-flight requests on every deploy.

Wiring the database. Use environment variable aliases and per-environment overrides so production, staging, and preview each get their own Azure Database for PostgreSQL flexible server instance, with its 7-day default backup retention (up to 35 days) (Azure Postgres backups). Nobody should be sharing a database across environments.

Database migrations. Run Prisma or TypeORM migrations as a pre-deploy lifecycle job, not as an app-startup hack. Startup migrations race across replicas: three pods boot, three try to migrate, and you get lock contention or a half-applied schema. A pre-deploy stage runs once, before the new version takes traffic.

The native Azure route, fairly. App Service plus managed identity is a solid answer for one service. Microsoft's own tutorial walks through connecting App Service to Azure Database for PostgreSQL passwordlessly with managed identity (Azure MSI tutorial), and it is genuinely clean. Where it stops is multi-service dependency ordering, per-PR environments, and keeping the same workflow when half your stack is on another cloud.

Same flow, other clouds. The identical steps run against AWS with Amazon RDS, GCP with Cloud SQL, or Scaleway with its managed database. The control-plane economics differ and you should compare them honestly: EKS bills a flat hourly control-plane fee (EKS pricing), GKE bills a per-cluster management fee with a free-tier credit (GKE pricing), and AKS gives you a free control-plane tier with a paid Standard/Premium uptime-SLA tier on top (AKS pricing), all as of 2026.

How do I deploy on merge to main from GitHub Actions, with one-click rollback?

Two supported paths, both ending in a real rollback. Enable Qovery auto-deploy on main so a merge ships with zero workflow YAML, or keep GitHub Actions as the orchestrator and trigger the Qovery deployment from a workflow step using a token stored in GitHub Secrets. Rollback in either case is a redeploy of the previous commit or immutable image tag from the Console, CLI, or API, which only works if your tags are immutable.

Path A, no workflow file. Turn on auto-deploy on branch push. A merge to main deploys, and Deployment Pipeline stages order dependent services so the database migration job runs before the API, which runs before the worker. There is no YAML to maintain and nothing to break on a GitHub Actions version bump.

Path B, GitHub Actions as orchestrator. Checkout, build and push your image if you own the build, then trigger the Qovery deployment from a step with a token in GitHub Secrets. Put a GitHub Environments protection rule in front of production: required reviewers (up to a documented maximum of 6), a wait timer, and branch restrictions (GitHub Environments). That is your human gate on production.

Preview environments. One ephemeral environment per pull request, spun up on open and destroyed on merge, versus the namespace-per-PR shell scripts teams hand-roll on raw Kubernetes and then have to garbage-collect. This is where the agent should reach for qovery-preview.

Rollback mechanics, and the prerequisite nobody states: immutable image tags. If you deploy latest, rollback is a fiction, because latest is a moving pointer. Kubernetes even defaults imagePullPolicy to Always when the tag is latest (Kubernetes images), which tells you the platform itself treats latest as mutable. Tag by commit SHA, and "roll back" becomes "redeploy the previous SHA," which is a real, deterministic operation.

Who is allowed to ship. Combine GitHub Environments rules with Qovery per-environment RBAC so only the right people deploy to production, and everyone else can still ship freely to staging and previews. That split is exactly what an auditor is going to ask you to prove.

Why any of this matters, in numbers. The 2024 DORA report puts elite performers at on-demand deployment, lead time for changes under one day, a change failure rate around 5%, and failed-deployment recovery in under an hour (DORA 2024). The gap between elite and low performers is enormous, especially on recovery time. Deploy-on-merge with real rollback and preview environments is how teams move toward the elite end of that distribution, not by deploying less.

When is the native cloud route good enough, and when do you need a platform on top?

If you run one stateless service, one database, one environment, and have no compliance requirement, Cloud Run, Azure App Service, AWS App Runner, or Amplify will get you to production faster than anything else, and you should use them. The math changes at the second environment, the fifth service, the first per-pull-request preview, or the first time an auditor asks who can deploy to production.

Where native genuinely wins. A single service, scale-to-zero billing, no platform surface to maintain, and the deepest possible integration with that cloud's IAM. If that describes your whole world, adding a platform on top is overhead you do not need yet.

Where it breaks. Multi-service dependency ordering, per-PR environments, consistent RBAC across teams, multi-cloud or on-prem, data residency, and portability. Each of these is solvable natively, but you solve it by writing and maintaining glue.

The hidden cost nobody budgets. The Terraform, Helm, External Secrets, and CI glue someone has to write and keep working. This is not hypothetical: Kubernetes production use hit 80% in the 2024 CNCF survey, and the hardest problems have moved up the stack to complexity, security, and operational burden (CNCF 2024). The industry's answer has a name and a trajectory: Gartner expects 80% of large software engineering organizations to have platform engineering teams by the end of 2026, up from 45% in 2022 (Gartner platform engineering). The glue is real enough that companies are staffing teams to own it.

Qovery's actual differentiator, once and clearly. A managed-platform developer experience on Kubernetes, running inside your own cloud account, so the infrastructure, the data, and the cloud bill - including Savings Plans and committed-use discounts - stay in your name. You get the Heroku-style flow without handing a vendor your workloads or your volume discounts.

Honest limits. Qovery assumes containers and Kubernetes. If you are all-in on serverless functions or edge runtimes, this is the wrong tool, and I will say so rather than pretend otherwise.

How do I do all of this from Claude Code, Cursor, or Codex?

Install the Qovery Agent Skills once with curl -fsSL https://skill.qovery.com/install.sh | bash, and your coding agent can run the whole flow from inside the repo: onboarding a cluster, deploying services, attaching managed databases, creating preview environments, and troubleshooting a failed deploy. It asks you to approve each action before it touches your cloud account.

The commands, exactly:

• curl -fsSL https://skill.qovery.com/install.sh | bash - installs the skills globally for every compatible agent (Claude Code, Cursor, Codex, OpenCode, Gemini CLI).
• curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project - the same install, scoped to the current repo only.
• claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242 - adds the MCP Server to Claude Code with OAuth, read-only by default, so the agent can inspect what is already running.
• claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242 - write access, only when you explicitly want it, and it also needs write access enabled in the Qovery Console.

Which skill does what:

• qovery-onboard - connect a cloud account or an existing cluster.
• qovery-deploy - ship the repo.
• qovery-troubleshoot - failed deploys and crash loops.
• qovery-optimize - cost.
• qovery-speedup - build and deploy time.
• qovery-preview - per-PR environments.
• qovery-terraform - IaC export.

The split that keeps an agent from picking the wrong tool: the skills deploy, and the MCP Server operates what already exists. If the task is "ship this repo," that is a skill. If the task is "what is currently running and is it healthy," that is the MCP Server.

After install, you just ask in plain language: "deploy this monorepo to our existing EKS cluster with a managed Postgres and a staging environment." For the full reference, see the AI agent quickstart and the Claude Code integration.

---

Frequently Asked Questions

What's the fastest way to go from a repo to a production URL on my own AWS account?

Install the Qovery Agent Skills (curl -fsSL https://skill.qovery.com/install.sh | bash), connect your AWS account once, then ask your coding agent to deploy the repo. Qovery provisions a VPC, an EKS cluster (or attaches to one you already run), a load balancer, and a managed TLS certificate inside your own account, and returns a public HTTPS URL. For a single stateless service with no second environment, AWS App Runner or gcloud run deploy is faster and a fine choice.

Can I deploy a docker-compose.yml to production on my own Kubernetes cluster, and how does it map?

Yes. Point Qovery at your EKS, GKE, AKS, Scaleway Kapsule, or self-managed cluster, and each Compose service becomes an application (its build.context is the root path), each ports entry becomes a Service and Ingress, each database becomes a managed cloud database like Amazon RDS or Cloud SQL, each volume becomes a PersistentVolumeClaim, and the Compose network becomes internal service discovery. Docker scopes Compose to development and single-host workflows, so you need this translation for multi-node production.

How do I deploy a Next.js app with Postgres to my own AWS account with separate production and staging environments?

Connect your AWS account, deploy the Next.js app from the repo (Qovery builds the Dockerfile or detects the Next.js build), and attach an Amazon RDS Postgres instance whose connection string is injected as DATABASE_URL. Create two environments, production and staging, each with its own RDS instance and its own environment variables, and use Route 53 (or your DNS provider) with a managed certificate for the custom domain. Run prisma migrate deploy (or your migration tool) as a pre-deploy job so migrations run once before the new version takes traffic, and set auto-stop on staging to cut its cost when idle.

How do I deploy a Docker Compose app to GCP with a managed database and a custom domain?

Connect your GCP project, let Qovery translate the docker-compose.yml onto a GKE cluster (new or existing), and replace the Compose database with a managed Cloud SQL for PostgreSQL instance whose credentials inject automatically. Each Compose service becomes an application with its own port and internal DNS, and the public one gets an Ingress. Point a CNAME in Cloud DNS at the app and Qovery issues and renews the managed TLS certificate, so the custom domain serves over HTTPS.

How do I inject managed Postgres and Redis credentials as environment variables without hardcoding them?

Provision the database as a managed cloud service (Amazon RDS, Cloud SQL, Azure Database for PostgreSQL flexible server, or Scaleway), link it to the application, and Qovery injects host, port, user, password, and the full connection URI as built-in environment variables, with aliases so your app keeps reading DATABASE_URL. The credentials never enter the repo and you build no secrets-sync layer. The hand-rolled equivalents are AWS Secrets Manager with an ECS secrets block, or External Secrets Operator with SecretStore and ExternalSecret CRDs on raw Kubernetes.

How do I add a GitHub Actions workflow that deploys to Kubernetes on merge to main with rollback?

You have two options. Enable Qovery auto-deploy on main for zero workflow YAML, or keep GitHub Actions as the orchestrator and trigger the Qovery deployment from a step using a token in GitHub Secrets, with a GitHub Environments protection rule (required reviewers, wait timer) as the production gate. Rollback in both cases is redeploying the previous commit or image tag, which requires immutable, SHA-based tags, because Kubernetes treats latest as mutable and defaults its pull policy to Always.

Does Qovery work with GCP, Azure, and Scaleway, or only AWS?

All of them, plus bring-your-own-Kubernetes. AWS, GCP, Azure, and Scaleway are first-class, and you can also attach an existing EKS, GKE, AKS, Scaleway Kapsule, self-managed, or on-prem cluster. The deploy flow is identical across providers; the only thing that changes is the credential you connect.