Shipping a Vibe-Coded App to Production: Infrastructure as Code, Backups and Maintenance
The top of the pyramid: how to actually ship a vibe-coded app to production with Infrastructure as Code, and keep it alive with backups, cron jobs and observability (Sentry, PostHog).
Gaetano Castaldo
In short
Shipping a vibe-coded app to production takes more than uploading it: you describe the infrastructure as code (Docker, ephemeral environments for tests), set up periodic backups, cron jobs and queues for notifications, and observability with Sentry (errors) and PostHog (user behavior). These are Levels 8 and 9, the ones that decide whether the app stays in production.
The Top of the Pyramid: Going Live and Staying There
This is the last article in the From Vibe Coding to Production series. We are at the top of the pyramid, Levels 8 and 9, the ones that decide not only whether your app goes to production, but whether it stays there.
It is the part a founder or a junior developer knows least, and exactly for that reason it is where we see the most expensive mistakes: apps that are online but fragile, with no backups, with notifications that never fire and nobody noticing until it is too late.
Level 8: Infrastructure as Code - Environments Ready in Minutes
Sound familiar?
Setting up a new environment takes you days and in the end it only works on your machine? Your infrastructure is not code yet.
Today you can describe your entire infrastructure inside files and containers. That means a development environment you can spin up in minutes, not days.
The advantage is not only setup speed. With tools like Docker you can run tests on ephemeral databases or infrastructure, created and destroyed only during the test run. You speed up development and you speed up testing, two things that usually slow a hand-built project to a crawl.
It is a level that completely changes the quality and repeatability of what you ship. Having infrastructure as code means being able to recreate an identical environment at any time, on any machine. No more "it works only on my machine".
Level 9: Maintenance - Backups, Cron Jobs and Notifications That Work
Sound familiar?
If a wrong command wiped the database tonight, could you recover? If the answer is not "yes, from the last backup", you have a serious problem.
Maintenance is the last block of the pyramid, and it is almost always the one set up worst from the start.
The classic scenarios are familiar. There are no periodic backups, so a single error can wipe out months of data. You want notifications, but they never fire, because the queues that handle them were never set up. Trivial operations like clearing the server cache do not yet fit into well-defined protocols you can fully delegate to AI.
All of this rests on technical knowledge that is hard to hand off to an assistant: cron jobs, queue management, monitoring, automatic backups. It is work you do not see, until it is missing. And when it is missing, it usually goes missing at the worst possible moment.
Observability: Knowing What Happens in Production with Sentry and PostHog
Sound familiar?
Your app has grown but you do not really know what happens inside, or why some users vanish? You are missing observability: Sentry for errors, PostHog for behavior.
There is a part of running an application that almost no founder sets up, and it is exactly the one that lets you sleep at night: observability, the ability to know what happens in your app once it is live, without waiting for an angry customer to tell you. Here two tools answer two different, complementary questions.
Sentry monitors errors. When something breaks in production, it tells you exactly where and why: which point in the code, which sequence, which user triggered the exception. Instead of discovering bugs from one-star reviews, you see them and fix them before they spread.
PostHog gives you product analytics. It reconstructs the paths and clicks of users inside the platform, down to session recording, so you understand which interactions lead to a certain journey and where people get stuck or drop off. It is not just a marketing metric: it is proof of how the product is actually used, against how you thought it would be used.
Together they answer the two questions that matter once the app is online: "what broke?" (Sentry) and "what are users doing?" (PostHog). This, on top of backups and cron jobs, is what keeps an application under control over time.
A warning that ties this level back to Level 7 on compliance: recording sessions and events means touching real people's data. It must be configured with PII masking from the start, otherwise observability turns into a privacy problem.
Does Vibe Coding Replace the Developer?
Now that we are at the top of the pyramid, the answer is clear: in part yes, and that is exactly why the developer becomes more important, not less.
Much of writing code is now accelerated by AI, and that is a good thing. But all the knowledge of production and maintenance, the ten levels of this series, is simply not replaceable. It takes experience and continuous maintenance that is too often ignored.
The good news is that building a SaaS today is simpler, faster and more cost-efficient than a few years ago. The bad news is that the early ease hides everything that comes after. Before you say the work is done, make sure you have climbed all ten levels.
FAQ: shipping a vibe-coded app to production
How do I ship a vibe-coded app to production? Uploading it online is not enough. Describe the infrastructure as code with Docker, so you can recreate an identical environment on any machine and run tests on ephemeral databases. Then set up periodic backups, cron jobs and queues for notifications, and observability with Sentry and PostHog. These are Levels 8 and 9 of going to production.
What is Infrastructure as Code and why does it matter? It means describing your entire infrastructure inside files and containers. With Docker you spin up an environment in minutes instead of days and recreate it identically anywhere, killing the classic "it works only on my machine". You can also run tests on ephemeral infrastructure, created and destroyed only during the run, speeding up development and testing.
Why are backups the first mistake to avoid? Because without periodic backups a single wrong command can wipe out months of data, with no way back. Maintenance is almost always the block set up worst from the start: automatic backups, cron jobs, queue management and monitoring are work you do not see, until it is missing, usually at the worst possible moment.
What are Sentry and PostHog for? They give you observability, knowing what happens in your app once it is live without waiting for an angry customer. Sentry monitors errors and tells you where and why something breaks in production. PostHog reconstructs user paths, clicks and sessions. They answer two questions: "what broke?" and "what are users doing?".
Does vibe coding replace the developer? In part yes for writing code, accelerated by AI. But exactly for that reason the developer becomes more important: the knowledge of production and maintenance, the ten levels of the series, is simply not replaceable. It takes experience and continuous maintenance that is too often ignored.
Let Us Take Your App to Production
If you have built an MVP in vibe coding and want to put it online in a solid way, that is exactly what we do at Castaldo Solutions: we take prototypes built by founders and bring them to production, secure, scalable and maintainable, step by step.
Talk to us about your app and we will take it to production without disasters.
Tags
Founder & CEO · Castaldo Solutions
Sono un consulente di trasformazione digitale con esperienza enterprise. Aiuto le PMI italiane ad adottare AI, CRM e architetture IT con risultati misurabili in 90 giorni.