Add Rent to an existing app

Keep your application structure and add Rent where its database code belongs. Install the matching CLI first, then follow the steps below.

Use Rent in an existing application

Use the repository URL supplied with your preview access and compile only the database your application deploys:

[dependencies]
rent = {
  git = "<repository URL supplied with preview access>",
  tag = "v0.7.2",
  default-features = false,
  features = ["postgres"],
}

Backend features are postgres, mysql, and sqlite. MariaDB uses the mysql protocol and feature. Enable more than one only when the same binary genuinely connects to multiple database families.

Create the initial project files, naming the database the application deploys:

rent init --database postgres User Post Comment
rent describe

One command does everything: it writes rent.toml, creates the model declarations in rent/schema.rsl, generates the typed client into rent/generated, and declares that client in your crate root so it is immediately usable. There is no configuration to author by hand.

Created ./rent.toml
Created User in ./rent/schema.rsl
Generated ./rent/generated
Declared the generated client in ./src/lib.rs
        #[allow(dead_code, unused_imports)]
        #[rustfmt::skip]
        #[path = "../rent/generated/mod.rs"]
        pub mod generated;
Next: Edit the schema, then run `rent migrate dev --name describe_the_change`.

Generated code lives under rent/, outside your source tree, so the declaration carries a #[path] attribute that reaches it. That one attribute resolves the whole generated subtree.

The module is named after the final component of generated. If your crate already has a module by that name, rent init says so and changes nothing but rent.toml, so you can pick another name and run the same command again:

Created ./rent.toml
Error: `./src/lib.rs` already declares a different `generated` module; change the final component of
       `generated` in rent.toml to name this client something else

Setting generated = "rent/db" names the module db, reaching the client as crate::db. Run rent generate after later manual schema edits.

An existing package keeps ownership of its build script. Plain rent init wires the generated module without adding or overwriting build.rs. Use rent doctor for freshness checks or rent dev while editing. When rent init --crate creates a dedicated client crate, that new crate includes the same automatic fingerprint check as rent new.

rent.toml stays yours to edit afterwards, for extension manifests, a different migrations directory, or additional backends. See the configuration reference for every key. Keep credentials out of it: Rent resolves the URL from --database-url, the environment variable named by url_env, or that variable in the project-root .env, in that order.

The generated client infers the backend from the URL:

let database_url = std::env::var("DATABASE_URL")?;

let client = generated::client::Client::connect(&database_url).await?;

See Database connections for URLs, Cargo features, and local or hosted database setup.

Upgrade Rent

Treat the Rent source revision and generated client as one reviewed dependency change:

1. Select the same release for every Rent dependency.
2. Reinstall the CLI using the matching release and --force.
3. Run rent generate in each application.
4. Review the generated source and rent migrate diff output.
5. Run the application's nextest and migration tests before deployment.

Do not hand-edit generated source to adapt an update. Schema changes belong in rent/schema.rsl. Application changes belong in the code that uses the generated client.

Check an existing project

Once an application is set up, run these checks from its root:

rent doctor

rent migrate status

cargo nextest run

cargo nextest run expects the application to contain at least one test. A newly scaffolded application compiles and runs immediately, but its application-specific test suite is yours to define.

When a configuration lives below the client crate, crate is relative to that configuration's directory. For example, rent/access/rent.toml can use crate = "../.." and generated = "db" to target rent/access/db from the enclosing crate. You can expose that client with a distinct module name:

#[rustfmt::skip]
#[path = "../rent/access/db/mod.rs"]
pub mod access_db;

rent doctor checks the resolved module target, including an existing alias, and reads the formatting attribute from that declaration. This supports multiple generated clients in one crate without requiring separate crates or renaming generated directories. A new declaration created by rent init still uses the final component of generated as its default name and rejects a conflicting module.