App dependencies

Anything your app relies on, such as a managed Postgres database, an embedded SQLite database, an object storage bucket, a volume, AI access or another app in your organization, is a dependency. You attach, edit and detach every kind the same way. Each one gives your app its connection details as environment variables under names you choose, and Nimbus Land keeps those values current: rename a variable, rotate a credential or detach the dependency, and the app's environment follows in one update and one restart.

The Dependencies panel#

Open the app's Resources tab. The Dependencies panel lists everything the app depends on, with its kind, name, status and a one-line summary.

Add dependency offers what the app can still use:

• Database: managed Postgres, or SQLite (embedded) (see SQLite).
• Bucket: S3-compatible object storage (see object storage).
• AI gateway: platform AI access paid from your organization's prepaid AI credits (see AI gateway).
• Linked app: another app in your organization, reachable over the private network.
• Volume: persistent disk mounted into the app (see volumes).

An app has at most one AI gateway and one SQLite database. Static sites have no Dependencies panel, because they have no server to connect anything to.

Each entry has an Edit button. The Edit dialog holds the variable names, Detach (or Remove and Delete for SQLite), the data protection status, key rotation for buckets and AI, and Retry for an entry whose last change failed. A failed dependency leaves its previous variables untouched until the retry succeeds.

A database you create from this panel is connected as soon as it is running: the entry appears straight away as being set up, and the variables are set when the database is ready. You can leave the page while that happens.

Variable names#

Every kind provides a fixed set of values, each with a default name. You can type a prefix into Fill all names from a prefix to rename them all at once, or choose Customize names to set each one. Names must be upper case with underscores, start with a letter, and be unique within the dependency. Values marked optional can be left blank to skip them.

Laravel apps get Laravel's own names by default (DB_URL, DB_HOST, DB_PORT, DB_DATABASE, DB_USERNAME, DB_PASSWORD, DB_SSLMODE for Postgres; DB_URL and DB_DATABASE for SQLite).

The managed Postgres DATABASE_URL uses the postgresql:// scheme and contains the password, so it is a secret. DATABASE_CA_CERT holds the database's CA certificate for drivers configured to verify the server.

A linked app with no names set still opens the network path between the two apps; it just injects nothing.

Managed variables#

Everything a dependency injects is a managed variable:

• The environment editor and the secrets list show it with a Managed badge naming the dependency, and offer no edit or delete for it. Saving the editor never changes it.
• The HTTP API and the nimbus CLI refuse to write it.
• Credentials (database passwords and URLs, a bucket's secret key, the AI API key) are secret variables: your app receives them, but nobody can read them back. A bucket's access key ID is an identifier, not a credential, and stays visible.

To take a name back, detach the dependency, or rename it under Edit so the name is free.

If a name you choose is already set on the app by hand, the dialog flags it and offers Replace the variables I set by hand with the managed values. Tick it to have the dependency take those variables over, which is the usual way to move a manually configured app onto managed variables.

Managed Postgres#

Managed Postgres databases live under Storage → Databases, where you can also create one directly (name, Postgres version 16, 17 or 18, storage from 10 to 100 GB, and availability). From the Dependencies panel, Database creates a new database (Postgres 18, 10 GB) or attaches an existing one. The dialog shows what the database costs per month before you create it. A database can be linked to more than one app.

From the CLI:

nimbus databases create --name orders --storage 25
nimbus databases list
nimbus databases show --database <id>

To read the connection URL or password yourself, open the database's page and use the show-password control.

Backups and point-in-time restore#

Every managed database takes a nightly backup at 03:00 UTC and continuously backs up every change in between. Backups are kept for 30 days. Back up now on the database page takes one on demand.

A restore always creates a new database, at the latest moment or at a time you choose (UTC) between the first completed backup and now. The database you restore from is never touched. Use Restore… in the database page's Backups section, or:

nimbus databases restore --database <id> --name orders-restored --at "2026-10-20 14:30:00+00"

From the app's Resources tab, the database's Edit dialog has Restore to a point in time (needs the Manage storage permission). When the restored database is ready, Switch app to it points the app's variables at it under the same names, with one restart (needs Manage apps). The previous database is kept, unlinked.

Availability and durability#

The Availability and durability section of the database page sets the number of instances:

• Single instance. No standby. If the machine it runs on fails, the database comes back from its storage, but the most recent writes can be lost.
• High availability, 2 or 3 instances. Standbys are kept in sync, and one of them is synchronous: a write is confirmed to your app only once that standby has it, so when the primary fails and a standby takes over, no confirmed write is lost.

With 2 or 3 instances, Durability decides what happens while no synchronous standby is available:

• Preferred (the default): the remaining instance keeps accepting writes. Writes made in that window exist on one instance only.
• Strict: writes pause until a standby is back. With 2 instances, one instance down stops writes (reads continue); 3 instances tolerate one down without pausing.

Changing durability doesn't restart the database or your apps.

nimbus databases update <id> --instances 2 --durability strict

Connecting from your machine#

The database has no public address. To reach it with psql, pg_dump or a GUI client, the CLI opens a short-lived, read-only session (add --write for read-write) tunnelled through Nimbus Land:

nimbus db shell orders      # psql
nimbus db connect orders    # a local port for any Postgres client

The database page's Connect from your machine section shows both commands. You need the Connect to databases permission (owners and admins have it).

Deleting a database#

The database page offers two deletes:

• Delete, keep backups. The database is removed and connected apps lose its variables, but its backups are kept for the 30-day retention window. It moves to Recently deleted on the Databases page, where Restore to a new database brings it back as a new database, and Purge now removes the backups early. Its name is free for reuse straight away.
• Delete everything. The database and its backups are removed. Nothing can be restored.

From the CLI, nimbus databases list --deleted lists deleted databases, nimbus databases restore works on them, and nimbus databases delete --database <id> on an already deleted database purges it.

Data protection#

Every dependency that holds data has a Data protection section in its Edit dialog: a status (Protected, Backups behind, Backups need attention, Not backed up or Status unavailable), what is covered and how far back you can recover. An entry that is Backups behind also shows that badge in the list.

Keep your own copy of anything irreplaceable.

Deleting things safely#

Deleting an app, a volume, a managed database, a bucket or a SQLite database with its data opens a dialog that lists what is destroyed and what is kept, and asks you to type the resource's name (the app's name for a SQLite database). The HTTP API requires the name as confirm, and the CLI asks for it or takes --yes in scripts. Detaching keeps a one-step confirm, because nothing is lost. Every delete is recorded in your organization's audit log.

When you delete an app, any database the deploy wizard created for it that no other app uses is listed under Also delete, checked, with its monthly price. Uncheck it to keep the database. A database you created or attached yourself is never offered. Databases deleted this way keep their backups, so they appear in Recently deleted. From the CLI, nimbus apps delete asks, or takes --delete-databases or --keep-databases.

Databases from the deploy wizard#

When the deploy wizard finds a Postgres client in your repository's manifests (package.json, mix.exs, requirements.txt, pyproject.toml, Gemfile, composer.json, go.mod and others), it suggests a managed Postgres database and says which file it read. The database it creates becomes a dependency of the new app, under the variable names you set in the wizard. You can also add Postgres or a volume yourself before the first deploy.

Postgres is the only managed database. MySQL and Redis are not offered today: when the wizard sees that your app needs one, it adds a note so you can enter the address of one you run elsewhere.

When the wizard finds a SQLite client, it suggests a volume for the database file instead of a server database.