How I Setup Production-Grade Deployment for My (Somewhat) Vibe-Coded App
How I Setup Production-Grade Deployment for My (Somewhat) Vibe-Coded App êŽë š
As the CEO of Frontend Masters, I spend a lot of time thinking about what courses we publish, which instructors we bring on, and whether the content actually helps developers level up. But thinking about great content and actually using the courses to learn are different things. Recently, I got to do both at once!
On the nights and weekends, I built Goalzi, a social app for setting and sharing life goals, and it started with me wanting to actually learn Go. I worked through Melkeyâs Complete Go course on Frontend Masters to get the fundamentals down, then wrote the original main.go from scratch. It reminded me of the old PHP days, where you had one file, a bunch of functions, and raw SQL, and somehow it all worked. I leaned into that. No layers, no framework, just the Go standard library and a single file. It felt great.
That approach got me about 90% of the way there. The last 10% is where AI (Cursor, mostly) did the heavy lifting: the engagement features, the email system, the onboarding, all the polish that turns a working app into something worth shipping. Thereâs a quote, âthe last 10% of a project is 90% of the work,â and that always ends up being true. So honestly, I donât think I would have shipped it without AI. It was also a great excuse to try the latest tools and models firsthand. As someone running an ed-tech company, I need to keep my skills sharp, and thereâs no substitute for actually building something to understand whatâs going on in the industry.
And the thing I built? A social network for goal setting and cheering each other on. I think the idea is genuinely inspiring. Will people use it? I have no idea, lol. But I hope they do.
If you build a vibe-coded app, you still need to deploy it. And if youâre going to deploy it, you may as well do it in a way that scales. Thatâs where Erik Reinertâs Cloud Infrastructure: Start-Up to Scale came in. Itâs the kind of course where being technically comfortable already lets you move fast and just absorb the infrastructure patterns without getting lost.
Hereâs what I ended up with.
The Stack
Goalzi is a Go backend, Postgres, server-rendered HTML templates, and vanilla JS and CSS. No frontend framework. Users sign in with Google, set goals, post updates, follow each other, and leave cheers and comments.
The deployment stack:
- AWS App Runner to serve the app
- Docker (multi-stage build) to containerize it
- Amazon ECR to store images
- AWS SSM Parameter Store for secrets
- AWS SES for email
- Supabase for hosted Postgres
- Route 53 for DNS
Why Erikâs Cloud Deployment Course, and What it Gave Me
The course walks through three phases of deployment: Start-up, Growth, and Scale. The core idea is that you containerize from day one, even if youâre a team of one, because that decision compounds over time. A VPS might feel simpler at first, but you pay for it later when you need to grow or move.
That framing was exactly what I needed. I had gotten something running on App Runner, but I had skipped steps. The IAM roles were sloppier than they should have been. I wasnât handling secrets properly. Migrations were kind of an afterthought.
Erikâs course made each piece concrete. He shows you exactly how to set up Parameter Store entries, scope an IAM role to only what App Runner needs, push images to ECR with a real tagging strategy, and wire it all together. Watching it as a practitioner reminded me why we obsess over instructors who actually work in the systems they teach.
From âIt Works on My Machineâ to One Command
The goal was simple: make deploy handles everything. No manual steps, no âoh right, I also need to run that migration.â
Hereâs what it does:
- Runs
go testagainst the full codebase - Reads the production database URL from SSM (
/goalzi-service/postgres-url) and runs all pending SQL migrations via a one-off Docker container - Builds the Docker image for
linux/amd64, tagged with the current git SHA - Pushes the SHA-tagged image to ECR
- Retags it as
latestand pushes again, so App Runner picks it up and deploys within a couple of minutes
For deploys with no schema changes, SKIP_MIGRATE=1 make deploy skips straight to step 3. HTTPS is handled automatically. No servers to patch.
Secrets Done Right
Nothing production-sensitive is in the repo. The database connection string lives only in SSM. App Runner pulls the Google OAuth credentials directly from Parameter Store at runtime using an IAM role scoped to exactly what it needs.
This is one of the things Erik makes very concrete in the course: setting up Parameter Store, creating the IAM role, and writing the policy that limits access to only that serviceâs parameters. Seeing it done properly confirmed I had it wrong before and showed me a cleaner way to structure it.
The result: I could open-source the whole repo tomorrow, and nothing would leak.
Migrations That Run the Same Everywhere
Migrations are plain SQL files in a migrations/ directory, applied in order. Locally, they run against a Docker Compose Postgres instance. In production, the same files run via a one-off Docker container using the prod URL pulled from SSM. Same files, same order, across both environments, running automatically on every deploy.
Syncing Production Data to Local
make sync-from-prod reads the prod DB URL from SSM, dumps only the app tables, spins up local Postgres via Docker Compose if needed, and restores the dump. I use this constantly for debugging real user issues, testing features against realistic data, and verifying backfill migrations before running them on the real database.
Email That Lands in the Inbox
Goalzi sends transactional emails for cheers, comments, and follows, as well as a monthly digest. The setup includes AWS SES with SMTP credentials, domain verification via Route 53, DKIM CNAME records, SPF, and DMARC.
The thing that trips people up: SES starts in sandbox mode. Everything looks fine in testing, but it only sends to verified addresses. Requesting production access is a separate step, so donât skip it. I also built a small internal endpoint to fire off a test email before any deploy that touches email templates. Itâs saved me from shipping broken emails more than once.
The Honest Version
I built Goalzi fast. AI-assisted, single file, shipped before it was clean. But the deployment is not fast and loose. Tests run on every deploy. Secrets are managed properly. Migrations are versioned and automated. The whole thing is reproducible.
That combination works really well. I can iterate quickly because I trust the deploy. I trust the deploy because I canât skip the safety steps.
As CEO, I constantly talk about the quality of Frontend Mastersâ content. It was genuinely satisfying to sit down as a regular user, follow along with one of our courses, and walk away with a better-deployed product. Erik built something Iâd recommend to anyone doing real work on AWS, and now I can say that from experience, not just from reading the curriculum doc.
Info
Goalzi is live. Set a goal. Tell someone about it.