How to Automate PlanetScale Operations with Kestrel Workflows: Incident Response, Database Provisioning, CI/CD, Schema Migrations, and Security
PlanetScale made database branching and non-blocking schema migrations mainstream — but the operations around them are still mostly manual: someone watches the deploy request, someone rotates the credentials, someone cleans up the stale branches. Here's how to automate all of it — incident response, database provisioning, developer requests, CI/CD, security, backups, and branch lifecycle — as deterministic, approval-gated Kestrel workflows, with copy-paste prompts for each.
Every team running PlanetScale at scale carries the same operational load. A deploy request errors mid-migration and someone drops everything to work out whether to revert. An Insights anomaly flags a slow query and nobody notices until the app team does. The pre-migration backup didn't run, the reader password from a one-off analysis is still live three months later, and the database is carrying forty branches nobody remembers creating. None of this is a PlanetScale problem — each response is a known, repeatable sequence of steps that happens to be executed by a human with the dashboard open. The fix is codifying those sequences as workflows that run the same way every time, with a human approving anything destructive.
This post shows how to automate the seven domains of PlanetScale operations with Kestrel Workflows: incident response, database provisioning, developer requests, CI/CD and schema migrations, security and access, backups and disaster recovery, and branch lifecycle. Each section includes prompts written the way you'd hand them to the Workflow Agent — paste one in, review the workflow it builds, and activate it.
How it works: plain English in, deterministic workflows out
You describe the automation in plain English and the Workflow Agent assembles it from real building blocks — PlanetScale's control plane (Create and Delete Branch, Promote Branch to Production, Set Safe Migrations, the full deploy-request lifecycle from Create through Deploy, Revert, and Approve, backups, branch credentials, and an AI-powered read-only Investigate) plus the stack around it: GitHub pull requests and Actions, Slack, PagerDuty, and Jira. The AI builds the workflow once; the workflow itself runs deterministically — the exact same steps on every execution, not an agent improvising at runtime against your production databases.
PlanetScale delivers branch and deploy-request events to Kestrel through signed webhooks — every delivery is verified against the webhook's signing secret before it can fire a workflow — and backup events are detected by polling on a cadence you configure. Workflows start from the trigger that fits the job: Deploy Request Opened, Errored, or Schema Applied, Branch Ready, Branch Anomaly (Insights), Storage Threshold, Backup Completed or Failed, CI events, schedules, or plain-English developer requests. And every workflow runs inside Kestrel's access control and approval model — restrict who can invoke it and drop approval gates anywhere in the graph so nothing destructive happens until the right person signs off in the dashboard, in Slack, or by merging a PR.
The Workflow Agent building a production-ready workflow from a plain-English description.
How to automate incident response in PlanetScale
PlanetScale incidents come in three shapes: the deploy request that errors mid-migration, the Insights anomaly that degrades the app before anyone notices, and the cluster that quietly fills its storage. All three follow the same split — the investigation is safe to automate fully, and the remediation gets an approval gate.
When a PlanetScale deploy request errors during deployment, fetch the deploy request's state, run an investigation to determine what went wrong with the schema change, and post the analysis to #databases in Slack. Send a revert to a Slack approval gate for the on-call DBA; on approval, revert the deploy request and confirm the deployment state. If the revert fails, page the on-call engineer through PagerDuty with the investigation attached.
When PlanetScale reports an Insights anomaly on a production branch — a slow query or replication lag — run a read-only investigation of the affected database and branch, summarize what changed and which recent deploy requests could be responsible, and post the findings to #databases in Slack. If the anomaly is replication lag, page the on-call engineer through PagerDuty with the summary attached; otherwise create a Jira ticket for the owning team.
When a PlanetScale cluster reaches a storage threshold, fetch the database's state, list its recent backups, and run an investigation into which branches are consuming the most storage. Post a capacity report to #databases in Slack with the findings. If the database is production, page the on-call engineer through PagerDuty so capacity gets addressed before writes are at risk.
How to automate database provisioning in PlanetScale
Provisioning on PlanetScale is really three jobs: standing up the branch a new service will build on with the right guardrails from day one, keeping safe migrations enabled everywhere it matters, and provisioning staging environments without anyone sharing a production password. The first and third go behind approval gates; the audit runs on a schedule.
When a new service is being set up, create a PlanetScale branch for it off the main branch of the named database, enable safe migrations on the new branch, and post the branch name and state to #platform in Slack. Require approval from the platform team before the branch is created — new long-lived branches are a capacity and cost decision.
Every Monday at 9am, list our PlanetScale databases and the branches of each, and flag any production branch that does not have safe migrations enabled. Post the findings to #platform in Slack; for each flagged branch, send enabling safe migrations to a Slack approval gate, and enable it on approval. An unprotected production branch is one unsafe schema change away from an outage.
When a team needs a staging environment, create a PlanetScale branch off main for the named database, create a reader branch credential scoped to it, and post the branch name and credential details back to the requester in Slack. Require approval from the platform team, and include the requesting team and their stated reason in the approval message so both are recorded in the run's audit trail.
The best way to automate developer requests in PlanetScale
Databases are where self-service pays off the most, because the alternative — a developer with production database credentials, or a ticket that blocks a PR for a day — is exactly what you want to avoid. Developers ask in Slack with /kestrel-workflow, from the CLI, or on the Developer Requests page; Kestrel matches the request to an active request-triggered workflow, extracts the parameters from the phrasing, and runs it with team-scoped permissions — making database operations self-service without opening up your PlanetScale organization.
When a developer requests a database branch for a pull request, create a new PlanetScale branch off the main branch of the named database, named after their git branch, then create a branch credential for it and reply in Slack with the branch name and connection details so they can point their preview environment at it. Allow this for all developers, no approval needed — these are ephemeral preview branches.
When a developer asks for a backup before a risky migration, create a backup of the named PlanetScale branch, poll the branch's backups until the newest one reports complete, and post the backup name and timestamp back to the requester so they have a known-good restore point. Allow it for all developers with no approval gate.
When a developer requests a schema change, open a deploy request from their branch into the target branch of the named database, then send the deploy request's diff and state to a Slack approval gate for the on-call DBA. On approval, deploy the deploy request and reply with the result; on rejection, close it. Always require approval, and only allow deploys into production databases for the platform-admin group.
When a developer asks about the state of a database, branch, deploy request, or recent backups, run a read-only PlanetScale investigation to answer the question and post the findings back to the requester. Allow it for everyone with no approval gate.
This is the same pattern our internal developer platform guide builds across the whole stack — Kubernetes, AWS, Vercel, and more. Here it's scoped to PlanetScale, but the request workflows compose: the same front door serves every integration you connect.
How to automate CI/CD and schema migrations with PlanetScale
PlanetScale's deploy-request model was built for CI/CD — a schema change is a reviewable, revertible unit, just like a pull request. What's usually missing is the wiring: the merge that should open the deploy request, the approval that should gate the deploy, and the revert that should fire automatically when a deployment errors. These three workflows are that wiring.
When a pull request whose branch name starts with schema/ is merged in GitHub, create a PlanetScale deploy request from the corresponding database branch into main with the PR title as the notes, and send the deploy request's diff summary to a Slack approval gate for the on-call DBA. On approval, deploy the deploy request, confirm the deployment state is complete, and post the result to #releases in Slack with the PR link.
When a PlanetScale deploy request is opened against a production database, fetch its state and summary and post them to a Slack approval gate for the database owners. On approval, post an approval review on the deploy request so it's cleared to deploy; on rejection, close the deploy request and post the rejection and the approver's reasoning to #databases in Slack.
When a PlanetScale deploy request errors during a pipeline deployment, revert the deploy request immediately, confirm the deployment state, and post what happened to #releases in Slack — the schema that failed, the revert result, and a link to the deploy request. Create a Jira ticket for the owning team so the fix is tracked. No approval gate on the revert; reverting a failed deployment is the safe default.
How to automate PlanetScale security and access
Database credentials are the classic standing-privilege problem: created for a one-off need, never revoked, invisible until the audit. PlanetScale's branch credentials are scoped and revocable, which makes them perfect for automation — grant on request, expire on schedule, audit continuously, and keep production promotions behind a human sign-off.
When an engineer requests read access to a database branch, send the request — requester, branch, and stated reason — to a Slack approval gate for the database owner. On approval, create a reader branch credential, post the connection details to the requester, and after 8 hours delete the credential automatically and confirm the revocation in the audit channel.
Every Friday at 4pm, list the branch credentials on every production branch of our PlanetScale databases and post the inventory to #security in Slack — each credential's name, role, and branch. Then send the inventory to a Slack approval gate so the security team can flag stale credentials; delete the ones they name on approval.
When anyone requests promoting a PlanetScale branch to production, require approval from the platform-admin group in Slack before anything happens. On approval, promote the branch, confirm it now reports as production, and post the promotion — who requested it, who approved it, and when — to #security in Slack for the audit trail.
How to automate PlanetScale backups and disaster recovery
Backups fail silently — that's what makes them dangerous. PlanetScale emits backup completed and failed events (Kestrel detects them by polling the backups API on your configured cadence), which means the failure can page someone the day it happens instead of surfacing the day you need the restore.
When a PlanetScale backup fails, run an investigation into the affected database and branch — recent backup history and anything anomalous about the branch state — and page the on-call engineer through PagerDuty with the findings attached. Post the failure and the investigation summary to #databases in Slack. A failed backup on a production branch is an incident, not a log line.
Every weekday at 6pm, before the nightly deploy window, create a backup of the main branch of each of our production PlanetScale databases, then poll each branch's backups until the newest one reports complete. Post a one-line confirmation per database to #databases in Slack; if any backup doesn't complete in time, page the on-call engineer through PagerDuty instead.
Every morning at 8am, list the backups for the production branch of each PlanetScale database, then run a read-only investigation to check that the most recent backup is in a completed state and no older than 24 hours. If any database fails the check, post a warning to #databases in Slack and create a Jira ticket for the platform team. Read-only, no approval gate.
How to automate branch lifecycle and hygiene in PlanetScale
Branching is PlanetScale's superpower and its housekeeping problem: preview branches outlive their pull requests, sleeping branches sit forgotten, and production promotions happen without anyone recording why. Lifecycle automation keeps the branch model cheap — in both dollars and attention.
Every Sunday at 10am, list the branches of each PlanetScale database and run a read-only investigation to identify non-production branches that look stale — sleeping branches, branches with no recent deploy requests, or branches older than 30 days. Post the candidates to a Slack approval gate for the platform team; on approval, delete the approved branches and post a summary of what was reclaimed to #platform in Slack.
When a PlanetScale branch goes to sleep, fetch its state and its parent database's state, and post a note to #platform in Slack — the branch name, its database, and its last-known state — so the owning team can wake it or let the weekly stale-branch cleanup reclaim it. Read-only, no approval gate.
When a PlanetScale branch is promoted to production, post an audit notification to #databases in Slack recording which branch was promoted and when, then run a read-only investigation confirming the branch is healthy — ready state, safe migrations enabled, and a recent backup present — and attach the findings. If any check fails, create a Jira ticket for the platform team.
Making PlanetScale easier to manage
Twenty-two workflows, seven domains, one pattern: describe the operation in plain English, let the Workflow Agent assemble it from real PlanetScale blocks and the stack around them, review the graph, and put approval gates on anything destructive. PlanetScale keeps doing what it's best at — branching, non-blocking schema changes, and telling you when something needs attention — and Kestrel turns those events into governed action: investigations with context attached, gated schema deploys and reverts, credential lifecycle, backup verification, pages, and tickets. The recurring 80% runs itself, and your team's time goes to the judgment calls.
This isn't PlanetScale-only, either. The same workflow engine spans 30+ integrations across infrastructure, PaaS, observability, comms, databases, CI/CD, and IaC — so the workflow that reverts a failed schema migration lives next to the one that restarts a Kubernetes deployment or rolls back a Vercel deploy. For deeper dives, see the internal developer platform guide and the companion posts on automating Kubernetes operations, automating AWS cloud operations, automating Vercel operations, automating Railway operations, automating Fly.io operations, automating Nebius operations, and automating Daytona operations.
FAQ: automating PlanetScale operations
How do you automate PlanetScale operations?
Turn each recurring database event — an errored deploy request, an Insights anomaly, a failed backup, a storage threshold — into a deterministic, approval-gated workflow instead of a human watching the dashboard. With Kestrel, you describe the automation in plain English, the Workflow Agent assembles it from real PlanetScale blocks plus the stack around them (GitHub, Slack, PagerDuty, Jira), and it runs the exact same steps every time, pausing at approval gates before anything destructive.
What is the best automation tool for PlanetScale?
It depends on scope. The pscale CLI and PlanetScale API are the right primitives for scripting individual operations. For turning PlanetScale events into governed action across your whole stack — investigations, gated schema deploys and reverts, credential lifecycle, pages, and tickets in one system — Kestrel Workflows builds deterministic workflows from plain English, triggered by the deploy-request lifecycle, branch events, Insights anomalies, storage thresholds, and backup events.
Is it safe to automate schema migrations in PlanetScale?
PlanetScale's deploy-request model is what makes it safe: schema changes are non-blocking, reviewable, and revertible. Kestrel adds the governance layer — the deploy itself pauses at an approval gate until the on-call DBA signs off in Slack, an errored deployment triggers an automatic revert, and every step is recorded in the run's audit trail. Read-only workflows (investigations, backup checks, branch inventories) are always safe to run ungated.
How do you make PlanetScale easier to manage?
Reduce the number of database events a human has to react to. Automate the recurring responses — errored deploy requests, failed backups, stale branches, credential audits — give developers self-service branches, backups, and schema deploys without production credentials, and keep humans in the loop only where judgment matters: approving schema changes and production promotions, not babysitting migrations.
Getting started
Connect PlanetScale — a service token plus a per-database webhook, about five minutes end to end — then pick the domain that hurts most. For most teams that's the schema-migration path: the merged PR that should become a gated deploy request. Paste one of the prompts above into the Workflow Agent, review the workflow it builds, tighten the scoping and approvals, activate it, and add the next one. The Workflows Quickstart walks through your first workflow end to end, and the Create Workflows guide and Integrations Setup cover connecting GitHub and the rest of your stack. Prefer the terminal or an AI coding agent? Workflows can also be created and managed through the CLI, Python SDK, and MCP. Within a few weeks every deploy request, backup, and branch event that matters will have a workflow behind it — and an audit trail to prove it.
Automate your PlanetScale operations with $1,000 in credits
Incident response, database provisioning, developer requests, schema migrations, security, backups, and branch lifecycle — describe each workflow in plain English and Kestrel builds it. New accounts get $1,000 in usage credits to get started.
Get Started