Deploy

Deploy turns a natural-language prompt into a live cloud service. Connect your AWS account and GitHub repo in Connect, describe what you want to deploy, and Deploy analyzes your repo, composes infrastructure from vetted modules, builds your container image, runs a Terraform plan, and waits for your approval before a single resource is created. You own the apply gate — nothing spins up until you click it.

Caution

Early access — AWS only. Deploy runs containerized web services on AWS (ECR + Fargate + Application Load Balancer), optionally with an RDS PostgreSQL database, composed from a curated module catalog. Support for additional cloud providers is on the roadmap but not available today.

Open Deploy

Deploy lives at deploy.destesi.io. Sign in once at account.destesi.io and your session follows you across the suite — open Deploy from the 9-dot launcher in any product. Everything you see is scoped to your active workspace.

Deploy your first repo

1. Connect AWS and GitHub in Connect. Open connect.destesi.io and authorize both your AWS credentials and the GitHub repo you want to deploy. Deploy reads all provider credentials from Connect and stores none of its own. If either connection is missing, the deployment fails immediately with a clear prompt to set it up.

2. Pick a repo and write a prompt. In Deploy, select the connected GitHub repo and describe your deployment — include the owner/name, your preferred AWS region, and any context that helps. For example: Deploy acme/api-service to us-east-1. Your prompt drives how the infrastructure is composed and parameterized.

3. Let Deploy analyze the repo. Deploy fetches your source and reads it — container build target, port, health-check path, infrastructure dependencies — and records a readiness report of anything that would block the deploy. If it finds a blocker, the deployment pauses and asks you rather than guessing. You can fix the issue or override the report and continue.

4. Watch the plan stream. Deploy composes the modules your service needs into a single Terraform configuration and runs terraform plan. The output streams live to your browser so you can see exactly what will be created, in which region, before anything exists.

5. Review the plan and click Apply. Nothing is provisioned until you approve. Read through the plan — resource types, names, region — and click Apply only when you’re satisfied. This is the core safety gate: no cloud spend happens without your explicit action. If the plan looks wrong, you can abandon the deployment at no cost.

6. Deploy builds and applies. After you approve, Deploy builds your repo into a container image, pushes it to the ECR repository in your account, and runs terraform apply.

7. Get your live URL. Deploy returns a live endpoint for your service on the deployment detail screen. From the same screen you can monitor progress, view logs, Redeploy, and Destroy to tear everything down cleanly.

Tip

Every deployment is fully destroyable. Terraform remote state is the source of truth, so Destroy removes all resources — no orphaned instances, load balancers, or ECR repos left behind.

What you get after a successful deploy

Once a deployment reaches Live, you have a fully managed service on AWS with:

What	Detail
Live URL	A public endpoint (via the Application Load Balancer) returned on the deployment screen.
Your image in your registry	Deploy builds your repo into a container image and pushes it to an ECR repository in your own AWS account.
Container logs	Stdout/stderr from your service streamed to a CloudWatch log group in your own AWS account.
Redeploy	Re-analyze, re-compose, and re-plan the deployment, then park at the same approval gate. Never applies on its own.
Destroy	Full teardown: every resource Terraform created is removed from your AWS account.

All infrastructure lives in your AWS account under your own credentials — Deploy provisions on your behalf but you own what it creates.

Add a database by asking for one

You don’t hand-edit configuration to change a running deployment. Open the deployment, and in its chat pane say “add a database” — Deploy appends an RDS PostgreSQL module and wires a DATABASE_URL into your service, then takes you back to the plan for approval. “Remove the database” takes both back out. Nothing is applied until you approve the new plan.

Caution

You can ask from either place: the deployment’s own chat pane, or Deploy’s chat home page — name the deployment there and it stages the same change. Either way the request lands in that deployment’s conversation, so the change stays auditable from its panel, and nothing is provisioned until you approve the plan.

How the database password is delivered

When a database is wired to your service, the resulting DATABASE_URL — including the database master password — is injected into the ECS task-definition environment. Anyone who can describe the task definition in your AWS account can read it. It is not stored in AWS Secrets Manager or SSM Parameter Store, so don’t treat it as secrets-grade handling.

App variables

Environment configuration lives at the workspace level, so every deployment in the workspace picks up the same set. Add or change a variable and Deploy suggests a redeploy — the change takes effect at the next apply, which stays your approval gate. Variables you mark as secret are masked on read (there is no reveal path) and delivered to your container as an SSM task secret.

Tear down

Destroy removes everything the deployment created:

1. Open the deployment and click Destroy.
2. Deploy runs terraform destroy. The deployment moves to destroying.
3. When it completes, the state is destroyed and your AWS account has no resources from this deployment remaining.

Note

Destroy is safe to call on a deployment that failed mid-apply. Terraform reconciles whatever partial state exists and cleans it up.

When a repo can’t be deployed

Deploy composes infrastructure from a curated catalog of vetted modules — it does not generate arbitrary infrastructure. Two modules exist today: web-service (ECS Fargate behind a load balancer) and postgres (RDS PostgreSQL). If your repo doesn’t fit — no container build target, an unsupported workload type, an incompatible structure — the readiness analyzer says so before any plan runs. Nothing is provisioned and there is no cost.

Your repo needs a buildable container definition. Alternatively you can deploy a pre-built container image directly, skipping the repo-fetch and image-build stages entirely. See the Reference for the full module catalog and inputs.

Your first deployment

When you open Deploy for the first time, you’ll see an empty deployment list. This is expected — you haven’t deployed anything yet. To get started, make sure you have an active AWS connection and at least one GitHub repo connected in Connect, then click New deployment and follow the steps above.

If Deploy shows an error loading your list rather than an empty state, check your connection and confirm your session is active at account.destesi.io. See Deploy troubleshooting for specific error patterns.

Next steps

Concepts — modules, the plan gate, and lifecycle

Reference — states, the module catalog, variables, API

Troubleshooting

Connect — where cloud credentials live