en un clic
serverpod-migrations
// Serverpod database migrations — when and how to create/apply/repair migrations. Use whenever database schema changes are involved.
// Serverpod database migrations — when and how to create/apply/repair migrations. Use whenever database schema changes are involved.
Serverpod web server (Relic) — REST APIs, webhooks, middleware, static files, server-rendered HTML, SPAs, Flutter web. Use when adding HTTP routes, serving web pages or web apps, intercepting requests, or working with the Relic web server.
Serverpod overview — what it is, project structure, how to work with. Always use at least once when working with projects that use Serverpod.
Serverpod Authentication — Signing in users, verify if they are authenticated, assinging scopes (e.g., admin). Use when adding features that require the user to be signed in.
Serverpod ORM with PostgreSQL or SQLite — CRUD, filters, sorting, pagination, relations, transactions, raw SQL, client-side database. Use when querying the database or working with relations.
Serverpod logging — session.log, log levels, persistence, retention, console output. Use when adding logging or debugging server calls.
Real-time streaming in Serverpod — Stream parameters and return types, WebSocket lifecycle, error handling. Use when building real-time features, chat, live updates, or WebSocket streaming.
| name | serverpod-migrations |
| description | Serverpod database migrations — when and how to create/apply/repair migrations. Use whenever database schema changes are involved. |
Serverpod has a migration system that generates SQL for changes to models with table in .spy.yaml. The migrations are applied:
apply_migrations tool is called via the serverpod MCP. Typically during development with a running serverpod start.dart run bin/main.dart --apply-migrations flag. Typically when running the server in production.table models or fields in .spy.yaml.Migrations are not needed when the project has no database configured (e.g. config/<runMode>.yaml with no database section).
The standard flow for creating and applying migrations is simplified when a serverpod start is running.
serverpod start and MCP serverWhen the server is running from serverpod start use the serverpod MCP to:
create_migration tool.apply_migrations tool.ALWAYS use the MCP server if it is available.
When the server is not running from serverpod start use the CLI commands to:
serverpod generate.serverpod create-migration command.If the database is in an inconsistent state, the repair migration can be used to bring it back to a consistent state.
# Use the `--mode` flag to specify the run mode
# Use the `--version` flag to specify the target version
# Use the `--force` flag to create a migration with destructive changes
# Use the `--tag` flag to name the migration
serverpod create-repair-migration [--mode production] [--version <name>] [--force] [--tag <tag>]
Apply the repair migration by restarting the server with dart run bin/main.dart --apply-repair-migration. This can only be done through the CLI. Ask the user to run this command.