Ship to the cloud with AI

Don't start with raw EC2 — it's the deep end. Use App Runner or Elastic Beanstalk for your first deploy so AWS handles the servers, then graduate later when you actually understand what you're skipping.

1. Ask the AI to write a Dockerfile for your Node app and confirm it builds locally with `docker build`.
2. Create an ECR repo, then push your image — the AI gives you the three `aws ecr` commands in order.
3. Point App Runner at that image, set your env vars in its console, and pick the smallest instance size.
4. Set the health check path (usually `/health` or `/`) so AWS knows when your app is actually up.
5. Hit the public URL it gives you, then check the logs to confirm it's serving real requests.

Big images come from copying everything and installing dev tooling into the final layer. Multi-stage builds fix most of it — build in one stage, copy only the output into a tiny final stage.

1. Ask the AI for a multi-stage Dockerfile: a `builder` stage that compiles/installs, and a slim runtime stage.
2. Use a slim or alpine base for the final stage and pin the exact version tag.
3. Copy only `node_modules` and built output into the final image — not your whole repo.
4. Add a `.dockerignore` so `.git`, tests, and local junk never enter the build context.
5. Run `docker images` and check the size dropped — a Node app should land well under 300MB.

Manual deploys are where 2am mistakes live. A pipeline runs your tests and ships automatically when you push to main — you stop being the single point of failure.

1. Tell the AI your platform (GitHub Actions is the safe default) and paste your test command.
2. Have it write a workflow file that runs tests, builds the image, and deploys only if tests pass.
3. Store your cloud credentials as repository secrets — the AI shows you exactly which ones and where.
4. Add a manual approval gate before the production step so nothing ships without a human nod at first.
5. Push a trivial change and watch the pipeline run end to end before you trust it with real work.

The rule: secrets never live in your repo, your Dockerfile, or your image. They get injected at runtime by the platform. If it's in git history, treat it as already compromised and rotate it.

1. Move every key out of code into environment variables — the AI can grep your repo and list them.
2. Add `.env` to `.gitignore` and commit a `.env.example` with blank values instead.
3. Set the real values in your platform's secret store (AWS Secrets Manager, Render env, GitHub secrets).
4. Ask the AI to check your git history for any key that already got committed.
5. Rotate any leaked key immediately — deleting the commit doesn't unleak it.

Almost always it's the environment, not your code: a missing env var, a port mismatch, a file path that only exists on your machine, or the container running as a user without permissions.

1. Grab the actual cloud logs and paste them to the AI — the error is usually in the first crash line.
2. Confirm your app listens on the port the platform expects (often `0.0.0.0` and `$PORT`, not `localhost:3000`).
3. Check every env var your code reads exists in the cloud env — one missing one crashes silently.
4. Ask the AI to spot hardcoded local paths or files that aren't in the image.
5. Reproduce it by running the exact container image locally, not `npm start` — that catches most of it.

Deploying is four moving parts stitched together. Once you see them separately, every platform stops feeling like magic and starts feeling like the same idea with different buttons.

• Image — a frozen snapshot of your app and everything it needs to run, built once.
• Registry — the warehouse your image gets pushed to so servers can pull it.
• Runtime — the machine or service that pulls the image and actually runs it.
• Networking — the URL, ports, and load balancer that let users reach it.
• Secrets & config — the values injected at runtime so the same image works in dev and prod.
• Health checks — the platform's way of knowing your app is alive before sending it traffic.

A VM ships a whole fake computer — its own operating system, gigabytes of it. A container ships just your app and its dependencies, and borrows the host's OS kernel. That's why containers start in seconds and VMs take minutes.

For shipping code, you almost always want containers. VMs matter when you need strong isolation or a totally different OS, but that's rarely your problem when you're just trying to get an app online.

By default containers run as root, and if someone breaks into your app, they inherit that root — which makes escaping the container into your host way easier. Running as a normal user is a cheap wall that stops a bad day from becoming a catastrophe.

The fix is two lines in your Dockerfile: create a user and switch to it before your app starts. Ask the AI to add it — there's no reason not to.

Stop reaching for AWS. For a demo tomorrow, use Render, Railway, or Fly.io — you connect your GitHub repo, it detects your stack, and you're live in minutes with a real URL. Save the 'proper' infra for after the demo.

Paste your repo details to the AI and ask for the fastest path on one of those platforms specifically. Don't let it talk you into Kubernetes the night before a demo.

Usually it's one of: a load balancer or NAT gateway running 24/7, data transfer out, an oversized instance you forgot to downsize, or a runaway auto-scaling group. The dashboard hides it; the bill breakdown doesn't.

Export your billing breakdown by service and paste it to the AI — ask it to rank what's costing you and which items are safe to kill. Then set a budget alert so it never surprises you again.

First: is it your new code or the infra? Check whether the previous version was healthy. Most platforms keep your last good image — redeploy that immediately to stop the bleeding, then debug in calm.

Paste your error logs and platform to the AI and ask for the exact rollback command plus the one check that confirms you're back. Rolling back first, diagnosing second, is not giving up — it's the professional move.

Serverless wins when your app is spiky or idle a lot — you pay nothing when nobody's using it. A plain server (VM or container) wins when you have steady traffic, need long-running processes, or want predictable cost and easier debugging.

A PaaS trades control for speed and sanity — you ship in minutes and never touch a load balancer. AWS gives you every knob and the lowest ceiling on scale, at the cost of a real learning curve and more ways to shoot yourself.

You learn if you read what it hands you and ask why each line exists, not if you paste and pray. The AI shipping your first app is fine — the trap is never understanding the four parts underneath, so the tenth deploy still terrifies you.

Treat every generated config as a worked example. Delete a line and see what breaks. That's the difference between someone who can deploy and someone who copied a deploy once.

Trust the structure, verify the specifics. The AI writes solid boilerplate, but it can pick an outdated base image, over-provision resources, or leave a security group open to the world because it doesn't know your risk. Read every network and permissions line yourself.

Never let it deploy something you don't understand to production on day one. Have it explain each risky line, test in a throwaway environment first, and keep a human hand on the production trigger until you've been burned enough to know the failure modes.