Deploy A Website from a Prompt.

You can go from nothing to a live website with one request to the Cycle MCP. This page walks through that request, and shows what the LLM (I'll be using Claude for this guide) checks, what it asks you to confirm, and how it proves the result works.

The concept

A public web app on Cycle needs three things:

• An environment that gives the app a private network and the built-in environment services, including the load balancer.
• A container running the app in the environment.
• A LINKED record that points a domain at the container, so the load balancer knows where to send requests and Cycle knows which TLS certificate to issue.

Claude builds them in that order, with one tool for each: create_environment, then deploy_application, then manage_dns_record. Each of these changes your hub, so the connector needs the write scope. If it's read-only, see this guide first.

Before a change, Claude tells you exactly what it's about to do and waits for your OK. For deploy_application and manage_dns_record, Claude first runs the tool with preview: true, which returns the exact change and a list of problems it found, and changes nothing. create_environment has no preview, so Claude states the name, cluster, and network mode before asking.

Do it

This example deploys the getting-started app as the container web in a new environment acme-web, served at acme.example.com.

1. Ask Claude in one prompt. Say what you want built, and say how you want changes handled:
   "Create a new environment called acme-web in the production cluster, then deploy the Docker Hub image cycleplatform/getting-started:latest into it as a container named web, serving on port 80. Give it a LINKED record at acme.example.com with TLS on. Before each change, tell me exactly what you're about to do and wait for my OK. When it's done, verify the URL end to end."
2. Claude checks the ground first. Before changing anything, it reads your hub with list_servers, list_environments, and list_dns_zones. It confirms that the production cluster has live servers, that no environment is already called acme-web, that example.com is a hosted DNS zone, and that no record for acme exists yet. Every one of these tools only reads.
3. Confirm the environment. Claude asks something like:
   "I'm about to create environment acme-web on the production cluster, with legacy networking off (IPv6-only private network; this setting is permanent), and start it. OK to proceed?"
   You answer with OK or Stop. After you confirm, create_environment creates the environment and starts its services. It reports the environment as live, with discovery, gateway, and scheduler running and the load balancer "not created". That's expected at this point.
   Choosing: leave legacy networking off unless the app can't use IPv6. Cycle's private network is IPv6-native, and turning on legacy IPv4 can't be undone.
4. Confirm the container. Claude previews the deploy, then describes it:
   "I'm about to create container web in acme-web: image cycleplatform/getting-started:latest, 1 instance, public network enabled, ports 80:80 and 443:80. This also restarts the environment's services so the load balancer comes up, and then I'll start web. The preview found no problems. OK to proceed?"
   The preview also reports whether an image source for the image already exists, such as getting-started-src. If one does, the tool reuses it instead of creating a duplicate. After you confirm, deploy_application creates web in a stopped state and restarts the environment's services. Claude then starts web with cycle_control_container.
   Choosing: deploy_application can deploy through a stack (the default), or create the container directly with stack: false. A stack keeps the deployment as a versioned build you can redeploy and resume. Creating the container directly leaves nothing else behind, which suits a single container you'll delete later. This example created web directly.
5. Confirm the domain. Claude previews the record, then asks:
   "I'm about to create a LINKED record acme in the hosted zone example.com (so acme.example.com), pointing at container web with TLS on and GeoDNS off. This is a new record; nothing existing is overwritten. OK to proceed?"
   After you confirm, manage_dns_record creates the record.
6. Claude verifies the URL. It runs check_dns_propagation on acme.example.com, then diagnose with the unreachable focus on web. In this example, the domain resolved to the same addresses on the zone's own nameservers and on public resolvers. The diagnosis ran nine checks and was healthy. Its live HTTPS request to https://acme.example.com/ returned 200.
7. Open the URL yourself. Visit https://acme.example.com. You should see the "Getting Started Completed!" page, with no certificate warning.

What just happened

The order of the steps matters because of the load balancer. Cycle creates an environment's load balancer only when the environment's services start while a public container exists. Right after step 3 there was no public container, so there was no load balancer. That's why step 4 restarted the services after creating web. Once web existed, the restart brought the load balancer up. If you create a public container some other way, start the environment's services again afterwards, or the domain has nothing to route through.

The port list is Cycle notation, not two ports on the container. 80:80 sends the load balancer's port 80 to the container's port 80. 443:80 means the load balancer takes HTTPS on port 443, terminates TLS there, and forwards plain HTTP to the container's port 80. The app never handles TLS itself. Without both entries, the LINKED record's TLS setting has no HTTPS port to serve on.

Each verification step proves something different. check_dns_propagation shows that the name resolves, and its result names the Cycle record that answered. That lets you tell your new record apart from a wildcard record in the same zone. The live request in diagnose shows that the whole path works, from DNS through the load balancer to the container. Your own browser loading the page over HTTPS without a warning confirms that the certificate was issued for your domain.

The confirmations are yours to enforce. Claude waited for an OK before each of the three changes because the prompt asked it to, and because the tools are designed around a preview step. None of the reads in step 2 needed a confirmation. If you'd rather approve the whole plan at once, say so in the prompt. Claude still describes each change before making it.

If a step times out, don't ask Claude to run it again from scratch. Cycle may already have accepted the change, and a second call can create a duplicate. Ask Claude to check first. For a stack deploy, get_deployment_status reports where the deployment stands, and deploy_application with stack_id continues from there. For a container created directly, listing the environment's containers shows whether it exists. No step timed out in this example.