cloud-deploy

The four rules that are the same on every cloud

The CLIs differ; the ways to get hurt do not.

1. Read before you write. Every provider has a "what exists" call and a "what would this do" flag. Use them and show the output before changing anything: terraform plan, aws ... --dry-run, az ... --what-if, gcloud ... --dry-run, doctl list commands. A deploy applied to the wrong account or region is not undone by an apology.

2. Know which account and region you are in. This is the single most common serious mistake, and it takes one call to prevent:

aws sts get-caller-identity          gcloud config list
az account show                      oci iam region list
doctl account get                    hcloud context active

Say out loud which account and region you are operating in before the first change, every session. Production and staging look identical from a terminal.

3. Credentials never go in an argument. Every one of these CLIs has a config file and an environment variable, and both are better than a command line that lands in the transcript and the action log forever:

• AWS — aws configure writes ~/.aws/credentials (0600); prefer an instance role or SSO when there is one.
• Azure — az login opens a device-code flow: print the URL and code and let the person authenticate. browser_goto can put the page on screen for them.
• GCP — gcloud auth login (device code) or a service-account key file whose path you pass, never its contents.
• Oracle / Huawei / DigitalOcean — an API key in the provider's config file, mode 0600.

If no credential is configured, that is an ask_human, not a prompt to invent one. See the rule in your system prompt.

4. Things cost money and keep costing it. A VM, a load balancer, a NAT gateway and a static IP bill by the hour whether or not anybody uses them. Say what a change will create and that it has an ongoing cost, before you create it. When a task is a test, say how to tear it down — and offer to.

Installing a CLI

None of these are in the base image. install_packages where the distribution has it; otherwise the vendor installer, as a job, and say what you are about to run because it is a script from the internet:

job_start   curl -fsSL https://... -o /tmp/install.sh
run_command cat /tmp/install.sh | head -40      ← look at it
job_start   bash /tmp/install.sh

Long operations are jobs, and their state outlives the job

Creating a cluster, a database or a large VM takes minutes. job_start, then job_wait, and a wait that times out has not cancelled the creation — call job_wait again, or ask the provider for the resource's state. Running the create a second time because the first "timed out" is how somebody ends up with two production databases and one bill they did not expect.

Provider quirks worth knowing

• AWS — everything is regional; a resource "missing" is usually a wrong --region. See the aws-cli skill for the detail.
• Azure — resource groups are the unit of deletion, which makes az group delete both the cleanest teardown and the most dangerous command in the whole CLI.
• GCP — project is the top-level scope: gcloud config set project before anything, and an API must be enabled before it answers.
• Oracle (OCI) — compartments are the scoping concept, and almost every command needs a compartment OCID.
• Huawei — the API and CLI mirror AWS closely; region names and endpoints do not.
• DigitalOcean / Hetzner — simpler, flat, and fast; doctl/hcloud are pleasant. Snapshots before resizing are cheap insurance.

Terraform and friends

When the task is repeatable, state it as code: terraform plan is the read step rule 1 asks for, and the plan output is what you show a person before apply. Never run apply -auto-approve on infrastructure somebody else depends on. The state file is the source of truth and losing it is worse than losing the resources — say where it lives (local vs remote backend) before you touch it.