Stop Teaching Beginners to Deploy Like It's 2013

A beginner's write-up made the rounds on dev.to this week, and if you've been doing this a while you can recite the steps from memory: create an IAM user, launch an EC2 instance, download the .pem file, SSH in, apt update, install Node, git clone, hand-type your secrets into a .env with vim, open port 3000 in the security group, hit the public IP in a browser. It works. The author is thrilled. It's genuinely a milestone — the first time your code answers requests from the actual internet.

It's also, step for step, the same tutorial we were writing in 2013. And that's the interesting part, because almost everything around this ritual has changed — the pricing, the security baseline, AWS's own product lineup — while the ritual itself hasn't moved an inch. Worse: nearly every habit it teaches is one you'll spend the next year unlearning.

The gap between "live" and "deployed"

Follow those steps exactly and here's what you actually have. A Node process running in a foreground SSH session — close your laptop and the app dies, because nothing in the recipe mentions systemd, pm2, or even nohup. Plain HTTP on a raw IP and a weird port, so no TLS and no domain. Secrets typed by hand into a file that exists only on that one box. A deploy process that is "SSH in and git pull." And a server whose entire configuration lives in your shell history: if the instance dies, so does everything you did to it.

None of this is the author's fault. It's what the genre teaches. The localhost-to-EC2 tutorial optimizes for the dopamine hit of the browser loading, and stops exactly at the point where deployment actually starts. The distance between "my app loaded once" and "my app is deployed" — supervision, TLS, restarts, repeatable provisioning — is the whole discipline, and the ritual skips all of it.

The security posture deserves its own paragraph. An internet-facing port 22 starts collecting brute-force attempts within minutes of boot — watch /var/log/auth.log on any fresh instance if you want a formative experience. Key-based SSH holds up fine against that noise, but the modern answer is to not open the port at all: SSM Session Manager gives you a shell through the AWS API with no inbound rules and no .pem file to lose. It's been the recommended pattern for years. It appears in approximately zero beginner tutorials.

The free-forever sandbox is gone

The economics underneath this genre quietly changed too. Every one of these tutorials was written against the old free tier: 12 months of a free t2.micro, so a forgotten instance cost you nothing. AWS killed that model on July 15, 2025. New accounts now get $100 in credits (up to $200 with onboarding tasks) on a Free plan that closes itself after six months. On top of that, since February 2024 every public IPv4 address bills at $0.005/hour — about $3.60/month just for the IP.

So the mental model the tutorial inherits — "spin it up, poke at it, forget about it, it's free" — is now wrong in the expensive direction. A beginner today should set a billing alarm before launching anything, and the tutorials that would tell them so haven't been updated.

Why beginners still land on raw EC2

Here's the uncomfortable question: why, in 2026, is SSH-into-a-VM still the default first contact with AWS? Because AWS never shipped a beginner path that stuck. App Runner — the closest thing AWS had to a Heroku-style "point at a repo, get HTTPS" experience — stopped accepting new customers on April 30, 2026. Elastic Beanstalk works but reads as legacy. Amplify is aimed at frontend frameworks. The paved road AWS actually invests in is ECS on Fargate behind an ALB, which is a terrific production answer and a brutal first lesson: task definitions, target groups, and IAM roles before you've served a single request.

That leaves Lightsail — $5/month with IPv4, $3.50 IPv6-only, bundled static IP and DNS — as the one AWS product genuinely shaped like a first deployment. Almost nobody writes tutorials about it, because Lightsail doesn't feel like "learning AWS," and learning AWS is the resume line people are actually chasing. The EC2 ritual persists because it's the credential, not because it's the tool.

Do it once, then never again

My actual advice splits on what you're optimizing for.

If the goal is learning, the EC2 ritual is worth doing exactly once — but finish it. Write a systemd unit so the app survives reboots. Put Caddy or nginx in front so you get 443 and automatic TLS instead of :3000. Close port 22 and use Session Manager. Then terminate the instance, write a script or a few lines of Terraform that recreates all of it, and run that instead. The lesson that servers are disposable and configuration is code is the single highest-leverage idea in operations, and you learn it precisely by feeling how fragile the hand-built version is.

If the goal is shipping a side project, skip the ritual. Fly.io, Railway, and Render all give you git-push deploys, HTTPS, and process supervision for roughly what the EC2 instance plus its IPv4 address would cost — and they're selling exactly the gap this tutorial falls into. That's not a knock on AWS; it's the market pricing the distance between "live" and "deployed."

The beginner who wrote that post did nothing wrong. They followed the map we keep handing out. But the map describes a territory from a decade ago, and the most useful thing an experienced engineer can tell them isn't "well done" — it's that the real deployment lesson starts the moment the SSH session closes and the app dies with it.