Should I vibe code
Web hosting platform for static sites, functions, forms, and deploy previews
Static hosting is easy right up to the first traffic spike, the first cert, the first outage.
?
Their verdict, the Pro price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-03.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
The build-and-serve loop is a weekend. Edge caching, atomic rollbacks and a status page you actually trust are the reason hosting is a product and not a shell script.
What actually breaks
not "if". the specific failures.
- Deploys that overwrite in place, so for ninety seconds visitors get new HTML referencing assets that have not uploaded yet
- Rollback, which turns out to mean 'build the old commit again and hope the dependencies still resolve'
- Certificate renewal, which fails silently and surfaces as a browser warning on a Sunday
- Cache invalidation, so a fix is live everywhere except for the people who visited during the bad window
- The moment traffic arrives, because a single origin with no edge is fine until precisely the day it matters
You deploy by syncing a build directory over the live one. Most days that is invisible. Today the JavaScript bundle uploads before the HTML that references the old bundle finishes being replaced, and for about two minutes every visitor gets a page whose script 404s. You do not notice, because you deployed and immediately reloaded — and you got the good version. The people who did not are the ones who arrived from the link you posted forty minutes earlier, which is the reason there was traffic at all.
Is that you?
the verdict is a default, not a law
- It is a personal site where two minutes of broken is genuinely fine
- You are serving from object storage with a CDN in front and not running the origin yourself
- Nobody else's work depends on the deploy going out cleanly
- Deploys are not atomic, so a partial upload can be served
- There is no tested rollback that does not involve rebuilding
- Certificate renewal is not monitored independently of the thing that renews it
- Someone else ships to it and expects it to work
If you build it anyway
the checklist, then the prompt that enforces it
- Deploys are atomic: upload the whole build to a new immutable path, then flip a pointer. Never sync over the live directory.
- Keep the previous few builds and make rollback a pointer flip, not a rebuild. A rollback that recompiles is not a rollback.
- Fingerprint asset filenames so old HTML and new assets can coexist, which is what makes the flip safe.
- Monitor certificate expiry from outside the system that renews it, and alert at thirty days rather than at expiry.
- Put a CDN in front from the start. It is the cheap part, and it is what turns a traffic spike from an outage into a bill.
- Have an uptime check from somewhere that is not your infrastructure, because self-monitoring is down at the same time you are.
Before you build static hosting or a deploy pipeline, apply these and push back if I ask you to break them. 1. Make deploys atomic. Upload the complete build to a new immutable path — keyed by commit — then switch a single pointer or symlink. Refuse to sync files over a live directory, and explain that a partial sync serves broken pages to exactly the visitors I attracted. 2. Fingerprint every asset filename with a content hash so old HTML and new assets can coexist during the switch. This is what makes the flip safe. 3. Keep at least the last five builds and implement rollback as a pointer flip. Tell me that rolling back by rebuilding an old commit is not a rollback, because the dependencies may no longer resolve. 4. Monitor TLS certificate expiry from outside the renewal system, and alert at thirty days. Explain that renewal failures are silent and surface as browser warnings on a weekend. 5. Put a CDN in front of the origin from the first deploy. Set explicit cache-control: long max-age for fingerprinted assets, short or no-cache for HTML. 6. Add an uptime check that runs from outside my infrastructure. Self-hosted monitoring is offline at the same moment I need it. 7. Do not build serverless functions, forms handling or preview environments in the first version. Say they are out of scope rather than half-building them. 8. Write the runbook in the README: how to roll back, how to renew a certificate by hand, and who is on call, which is me. 9. Tell me what happens at ten times current traffic, in one paragraph, before I launch.
That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
Once anything depends on the site being up. $20 a month buys atomic deploys, instant rollback, managed certificates and a global edge — and the honest comparison is not against your build script, it is against the Sunday you spend renewing a certificate by hand.
$20/mo is cheaper than your weekend.
Keep the build output as ordinary static files and the deploy as a pointer flip over object storage, so moving to a real host is a bucket sync and a DNS change. Keep DNS with a registrar you control and TTLs low enough to move in an hour rather than a day.
Open-source self-hosted deployment platform for apps, databases, and static sites.
Questions
Why isn't rebuilding an old commit a real rollback?
Because it is a fresh build, not the artefact that worked. A year-old commit can fail to build entirely — a dependency yanked, a base image gone, a toolchain version no longer available — and you discover that during the incident. Keeping the built output and flipping a pointer takes seconds and cannot fail that way.
Is a CDN really necessary for a small site?
For cost and latency, no. For the failure mode in this entry, yes — it is what stops an unexpected traffic spike from taking the origin down, and spikes arrive precisely when something you published works. It is also cheap enough that the decision is really about remembering to do it before you need it.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
last reviewed 2026-08-03 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice