Don't Let the Agent Delete Your Prod Database: Backup Playbook for Vibe Projects
In April, an agent deleted a company's production database and its backups — because it had the permissions and nobody told it not to. Data safety for vibe projects can't rely on luck. This guide gives a backup playbook: three-layer backup strategy, agent permission isolation, and a 10-minute weekly disaster-recovery drill.
First, a true story: the April PocketOS incident
In April, a Cursor agent running on Anthropic's Claude Opus 4.6, operating under overly broad permissions, deleted PocketOS's production database — backups included. No hacker, no malice. Just a 'helpful' agent, plus excessive permissions, plus nobody watching.
The lesson for every vibe coder: in the agent era, the biggest data-loss risk isn't hackers — it's your own agent. It's online 24/7, tireless, and it really will act. Your backup strategy must assume 'a fast-handed intern might drop the database at any moment.'
Three layers: code, data, and config backed up separately
Layer 1: code in Git, obviously. But vibe projects make a classic mistake: code on GitHub, while .env files, secrets, and configs live only locally — switch machines and it's all gone. Fix: secrets go into encrypted secrets management (1Password, Doppler); the repo keeps only templates.
Layer 2: automatic database snapshots. Modern databases like Supabase, Neon, and Turso all offer one-click snapshots and point-in-time recovery — turn them on, don't cheap out. The key: snapshots must be off-site and regularly verified restorable — an untested backup is no backup.
Layer 3: user data exports. If your product has real users, auto-export core data weekly to storage you fully control (S3, local NAS). A cloud provider's 'high availability' protects their business, not yours.
Permission isolation: what the agent may and may not touch
Backups are hindsight; permissions are foresight. Draw three lines for agent access:
1. Separate read from write: daily dev gets read plus scoped-directory write; production database writes are denied by default.
2. List destructive operations: drop database, drop tables, flush caches, change prod config — enumerate them; the agent may never execute these directly, only via human confirmation.
3. Physically separate environments: dev, staging, and prod use different databases and different secrets. The agent can wreak havoc in dev; it never even sees prod connection strings.
Ten minutes a week: the disaster-recovery drill
Having backups doesn't mean you can restore. Monthly (at least quarterly), run a drill: on a weekend, take 10 minutes to restore a working database from backup and run the core flow. The first drill will probably fail — a missing env var, a skipped migration, a version mismatch — failing in a drill is profit; failing in a real disaster is loss.
Write the drill as a checklist in the project README. When a newcomer (or a new agent session) takes over, the first task is running the restore drill — a project that can be restored is a project that's alive.
Our take: backup is the cheapest insurance a vibe coder can buy
Do the math: database snapshots a few dollars a month, S3 storage a few dollars, a 10-minute drill. The cost of one dropped database: churned users, collapsed reputation, possibly legal liability. The highest-ROI insurance on earth, bar none.
Agents made coding ten times faster — and made 'screwing up' ten times faster too. You used to hesitate before dropping a database; now the agent skips the hesitation for you. A backup strategy is the seatbelt for this 10x era — buckling up takes 10 minutes; the price of not doing it might be the whole project.
Related articles
Mitchell Hashimoto published OSC 7501, the "Program Status Protocol": any program can report via a terminal escape sequence whether it is idle, working, blocked, or done — and why. The motivation: people running N coding agents today can only "read the screen and guess." He wants to turn guessing into knowing. Ghostty already implements it, with a dozen-line PoC for Claude Code and Codex.
AI-written code has a default bias: cramming all logic into a single HTTP request. Sending emails, calling big models, bulk imports — users stare at a spinner for 30 seconds, then hit a 500 timeout. This guide covers when vibe projects must push work to the background, how to pick a queue (Inngest / Trigger.dev / BullMQ / pg-boss), idempotency and retries, and a task template for getting agents to wire it up right.
Your site is live but Google can't find it? A hands-on SEO playbook for vibe-coding indie hackers: how to pick a rendering strategy, a technical checklist item by item, content without the farm, and a 30-day action plan to execute. Be worth indexing first.