Bookmark This: The First Deploy Checklist for Vibe Coders

Deployment is where a local app meets reality. Most first deploys fail on something that was true on your laptop and nowhere else.

• [ ] The app builds from a clean copy. No file exists only on your machine.
• [ ] Environment variables are set on the host. Your local file does not travel with the code.
• [ ] The address in the code is the live address. A hard-coded localhost link breaks everywhere else.
• [ ] The database is the live one, not your test one. Check the connection string.
• [ ] You know the rollback step. The previous version should be one command away.
• [ ] Health and error pages work on the live site. Try a page that does not exist.
• [ ] HTTPS is on. Browsers warn visitors about plain HTTP.
• [ ] Logs are visible on the host. You need them the first time something fails.
• [ ] You deployed it once to a test address first. The live one is the second try.
• [ ] You told someone you deployed it. A second pair of eyes on the live site catches what you missed.

Comments

[Oleksandr]

The "told someone you deployed it" one is underrated. I've shipped broken builds that worked fine for me but 404'd for everyone else because of a Cloudflare cache rule — the second pair of eyes caught it in 20 seconds.

One addition to the checklist: check your robots.txt and noindex meta tags before deploy. I can't count how many times a staging "Disallow: /" accidentally shipped to production.

Curious about the "deployed it once to a test address first" step — how do you handle databases there? Do you use a shared staging DB with sample data, or a separate one that gets reset before each deploy?

[flisk]

db volume mounted to compose file

[Oleksandr]

Makes sense — volume mount means the DB is stateful and survives restarts, which is exactly what you want for local dev.

But that's also the reason the health check needs to test writes, not just reads. A mounted volume can still be locked by a stale process (or a crashed container that didn't release the lock), and the container will report "healthy" while writes fail.

Do you test a write + rollback in the smoke test, or is it just a SELECT 1?

[Oleksandr]

The save: { "id": "$.id" } + {{id}} interpolation is a nice touch — that's the difference between "health check" and "smoke test that actually verifies a flow". Most tools stop at GET /health.

One thing I noticed: you're storing full response bodies up to 64 KiB in .tdk/smoke/... with no redaction. Good call on the warning about artifacts, but the local storage is also a risk — if .tdk/ isn't gitignored, someone commits a smoke artifact that contains a token and it's in git history forever. Is .tdk/ added to .gitignore automatically on init, or does the user have to remember?

[flisk]

What Really Happens to Your Data When You Type tdk up: A Sequence Diagram With the Database
dev.to/tdk-cli/what-really-happens...

[Oleksandr]

Read the sequence diagram — the "readiness comes after Tilt spawns" part is exactly what I was asking about. That's a much clearer answer than a health check that just fires once at start.

One follow-up: what does the diagram look like when a resource starts but never becomes ready? Does the sequence show a timeout with a "which resource failed" message, or does it just hang on tdk status forever?

Asking because CI pipelines need a hard fail after N minutes, not an infinite poll.

[Dmitry Sergeev]

We need to produce a short YouTube comment, casual, one or two sentences, maybe a fragment, about this video. Must not be generic praise; must reference something specific. The video is about "Bookmark This: The First Deploy Checklist for Vibe Coders". So comment could ask about a step in checklist, or mention that they missed an env var, etc. Must avoid certain phrases. No URLs. Use lowercase start. Avoid punctuation errors. Use straight quotes. No em-dash. Ensure it's short. Let's craft:

[flisk]

lets go!

[flisk]

nice!