Ridu v0.24.0

Ridu 0.24.0

A binary built with ridu build now applies its own migrations, so a production container can run
the binary alone, with no Ridu CLI, Go or JavaScript runtime beside the server. The Railway guide
now migrates and starts with the binary.

Hosts such as Railway bill the memory a container holds, including the cache of files its processes
have read. Running ridu migrate up at startup compiled the project with Go under the package
manager before the server started. On one Railway service that left about 120 MB of file cache in
the container for as long as the server ran, beside a server using about 40 MB. A package script as
the start command, such as bun run start, also keeps the package manager running beside the server.

Changes

• <binary> migrate up applies the committed migrations from migrations/ in the working
  directory, or from --directory. It applies them only when they are exactly the history the
  binary was built with, the same history its /readyz check requires, and refuses any other. It
  selects the database like ridu migrate up, from DATABASE_URL or RIDU_SQLITE_PATH or the
  --database-url and --database-path flags, and takes the same --allow-maintenance,
  --allow-insecure-database, --allow-unbounded and timeout flags. plan, status, verify
  and stop boundaries stay in the CLI. See
  Deploy migrations.
• Generated projects register their adapter's migration driver in cmd/server/main.go, for
  example ridu.WithProjectMigrations(postgres.ProjectMigrations()). The binary migrates through
  it, and data transforms are passed to the same call.
• The Railway guide sets the pre-deploy command to
  ./dist/<project> migrate up and the start command to ./dist/<project>, and the SQLite start
  command to ./dist/<project> migrate up && exec ./dist/<project>. The
  Build and run guide lists what a production
  image needs: the binary, migrations/, trusted certificates and its environment.
• The generated build script runs ridu build --output dist/<project>, so the binary's name no
  longer depends on the directory it's built in. A platform that builds in /app, such as Railway,
  otherwise gets dist/app, which the start script and the guides don't name. On Windows,
  ridu build adds .exe to an --output path without an extension.
• The PostgreSQL and SQLite guides for switching adapters now swap the migration driver too, and the
  MongoDB guide's example of converting cmd/server/main.go, which highlighted the wrong two
  readiness lines since 0.23.0, matches the generated file.

Upgrade

Update the Go module and all Ridu npm packages to 0.24.0 together, and rebuild the admin and
application binary.

cmd/server/main.go belongs to your project, so the migration driver isn't added for you. A
project that already passes data transforms to ridu.WithProjectMigrations has it. Otherwise, to
migrate with the binary, register it outside the len(os.Args) == 1 branch, using the sqlite or
mongodb package for those databases:

options := []ridu.ExecuteOption{
	ridu.WithProjectMigrations(postgres.ProjectMigrations()),
}
if len(os.Args) == 1 {
	options = append(options, runtimeOptions(applicationConfig)...)
}

Then deploy migrations/ with the binary, run ./dist/<project> migrate up where you ran
ridu migrate up, and start ./dist/<project> itself rather than through a package script. If
your build script is plain ridu build, add --output dist/<project> so the binary has the name
your commands use. ridu migrate up keeps working unchanged.

Ridu requires Go 1.26.9 or newer. Go 1.27.0 and 1.27.1 meet that minimum but still have the
standard-library vulnerabilities described in the 0.20.0 notes, so build and deploy with Go 1.26.9
or a later 1.26 release, or with Go 1.27.2 or later.