# How it works **Code to Cloud** is Opsera's AI deployment agent. You point it at your GitHub repository from your IDE, answer a few questions, and it deploys your app to wherever you want it — your AWS account, your EKS cluster, your ECR registry. No CI/CD setup, no YAML writing, no DevOps expertise needed. ## **The Problem** You have a working app in a GitHub repo. Deploying it means: * Writing a Dockerfile * Setting up a container registry * Provisioning or configuring a Kubernetes cluster * Writing Helm charts and deployment manifests * Building a CI/CD pipeline with build, scan, push, and deploy stages * Wiring up secrets, ingress, TLS, and DNS That's days of work before a single user sees your app. Code to Cloud compresses it to a single conversation. ## **Prerequisites** Before starting, confirm the following: * An Opsera Enterprise account with Code to Cloud access * An IDE with MCP support — VS Code with the Claude extension, or Cursor * AWS CLI installed locally with at least one named profile configured * `kubectl` installed and accessible in your PATH * A GitHub repository containing your application code * AWS credentials with sufficient permissions for EKS, ECR, and IAM read access ## **What Code to Cloud Does** The agent connects to your IDE via MCP. You give it your repo path. It inspects your code, asks you a handful of questions about where you want to deploy, then creates and runs a fully configured pipeline — all within your existing AWS infrastructure. **You stay in control.** The agent deploys to your AWS account, your EKS cluster, your ECR registry. It doesn't spin up new infrastructure you don't own. It works with what you already have. **Nothing is assumed. Nothing is hard-coded.** Every deployment target is confirmed by you before the pipeline is created. Your app is deployed at a URL auto-assigned from your cluster's wildcard domain. ## **How the Agent Works — Step by Step** **1. Repository Analysis** The agent reads your repo — tech stack, package files, Dockerfile (if present), existing manifests. It tells you exactly what it found and what it will auto-generate if missing. **2. You Answer a Guided Set of Questions** The conversation is shaped by what the agent found in your code. Core questions cover: * App name * Target environment (dev / test / uat / prod / custom) * Cloud provider * AWS profile — the agent lists all profiles found on your machine; you select one * EKS cluster and ECR repository — discovered automatically from your selected profile * Deployment asset handling — how to manage your Dockerfile and K8s manifests. If the agent finds existing K8s manifests, it asks how you want to use them. If nothing exists, it offers to generate a full Helm chart. Options vary based on what's in your repo * Security scanning — optionally enable SonarQube code quality scanning and Grype container vulnerability scanning The questions are specific to your application — not a one-size-fits-all wizard. **3. Deployment Plan Review** Before doing anything, the agent shows you a full summary table covering: pipeline name, app name, environment, cloud, cluster, registry, namespace, ingress pattern, deployment URL, branch, workflow stages, and secrets needed. You confirm with `yes` or provide corrections before the agent proceeds. **4. Pipeline Created** On confirmation, the agent creates the pipeline in Opsera with all variables pre-filled, generates the deployment script, and tells you exactly which secrets to configure in the portal. The number and type of secrets required depends on your pipeline configuration. **5. You Configure Secrets** Open the portal link provided by the agent and enter the credential secrets that cannot be auto-detected from your environment. Common secrets include your GitHub Personal Access Token, AWS credentials, container registry credentials, and any scan tokens for enabled scanning tools. All other pipeline variables are already pre-filled. **6. You Trigger the Pipeline** Return to the IDE and type `deploy` to trigger the first run. Subsequent runs can also be triggered directly from the Opsera portal using the **Run Pipeline** button, or automatically via webhook on git push. The pipeline runs end to end and your app goes live. **The Pipeline Chain** The pipeline stages depend on what was configured for your specific pipeline. The core stages are: ``` clone → build → push → deploy ``` If security scanning tools were configured, additional stages are added at the appropriate points: ``` clone → scan → build → containerscan → push → deploy ``` Scanning stages are not automatically added to every pipeline. Whether `scan` or `containerscan` appear depends on how your pipeline was configured when it was created. Each pipeline's stage chain reflects its own setup. ## **After Deployment** Once your pipeline runs successfully, you can manage everything from the Opsera portal under **Code-to-Cloud → Pipelines**: * View run history and per-stage logs * Access the live deployment URL from any successful run record * Re-trigger runs using the Run Pipeline button * Set up a webhook to auto-trigger on every git push to your branch * Update pipeline variables or secrets without recreating the pipeline * View the Deployment Plan, Blueprint, and Activity tabs for the full configuration and audit trail Every run is logged with who triggered it, when it ran, which stages executed, and what the outcome was. ## **Use Cases** Use Case 1 — Frontend Web App, Dev Environment ***Scenario**:* A developer has a Vite + React + TypeScript app in GitHub. They want to deploy it to their team's AWS dev cluster to share a preview URL with designers. ***What they do**:* Open IDE, trigger agent with repo path, confirm app name, select environment dev, pick their AWS dev profile, use existing ECR repo. ***What the agent does**:* Detects the Vite + React stack, finds the Dockerfile, discovers the EKS cluster, identifies the wildcard domain, creates the pipeline with all variables pre-filled. *Pipeline chain for this run:* `clone → build → push → deploy` (no scanning configured for this pipeline) ***Result**:* App live at a shareable URL in under 10 minutes. Designer review link ready immediately. Use Case 2 — Backend API, Production Deployment ***Scenario**:* A team is ready to promote their Node.js REST API to production. Their production pipeline was configured with SonarQube and Grype, with strict quality and security thresholds. ***What they do**:* Trigger agent, select environment prod, pick the production AWS profile. ***What the agent does**:* Discovers the production EKS cluster and ECR registry, creates the pipeline. Because this pipeline was configured with scanning, the full chain is built in. *Pipeline chain for this run:* `clone → scan → build → containerscan → push → deploy` ***Result**:* Every deployment to prod automatically runs through the quality and security stages configured for that pipeline. Full audit trail visible in the Opsera portal. Use Case 3 — New App, No Dockerfile, No Manifests ***Scenario:*** A developer has just finished building a Python Flask API. The repo has only application code — no Dockerfile, no K8s YAML, no CI/CD config at all. ***What they do:*** Trigger agent with the repo path. Agent detects Python + Flask, reports no Dockerfile found, offers to auto-generate everything. ***What the agent does:*** Generates a multi-stage Python Dockerfile, creates a full Helm chart, creates a new ECR repository, builds the complete pipeline. *Pipeline chain for this run:* `clone → build → push → deploy` ***Result**:* A repo with zero DevOps files becomes a fully deployed, URL-accessible application — without the developer writing a single line of YAML. Use Case 4 — Multiple Environments, Same App ***Scenario:*** An engineering team wants dev, uat, and prod pipelines for the same application — each pointing to a different AWS account and EKS cluster. ***What they do:*** Run the Code to Cloud agent three times — once per environment. Each time, select the appropriate AWS profile, which maps to the correct account and cluster. ***What the agent does:*** Creates three fully independent pipelines, each with its own namespace, ECR configuration, deployment URL, and stage chain. Each pipeline reflects the configuration choices made for that environment. ***Result**:* Full environment isolation. Each pipeline is independently configured, independently triggered, and independently visible in the Opsera portal under the same organization. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.agents.opsera.ai/code-to-cloud/how-it-works.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.