Storage, databases, and backups

An application image can be replaced on every release. Put data that must survive in a managed Docker volume, an allowed host mount, or a linked database. Review lists the mounts a new project will keep under Data it keeps, and Settings → Storage shows the Persistent mounts you want and the mounts In the live release after creation.

Keep file-backed stateCopy Anchor Link

Add a volume for a SQLite file, uploads, key ring, or another writable directory that must outlive a release. Check its container path before the first deploy: mounting over application code can hide the code inside the image. A managed volume belongs to one project and survives new releases and rollback. A shared or unknown volume is not silently adopted. Storage settings show each volume's size, whether a backup job copies it, and a way to back up a volume nothing copies.

Compose projects can mount several services and combine multiple Compose files. The backup coverage check examines the merged service mounts rather than assuming only the first file or service matters. Anonymous or unresolved mounts cannot be counted as protected storage.

Connect a databaseCopy Anchor Link

During creation, a detected database dependency appears on the Variables step with an Add button for its engine. Add database opens a sheet where you name the variable, such as DATABASE_URL, and choose Create new to start an engine on this server or Use existing to take a saved connection. For a hosted provider whose driver speaks its own protocol, paste the provider's connection string into the variable instead. Check that the variable name and URL format match what your application reads; detection suggests an engine and variable, but the application may expect another format.

A linked connection is stored as a reference in the application's variable, so a saved password rotation or a replacement local container resolves to the current address. The deployment network gives a recognized local Docker database a stable internal hostname without changing its host-side connection. A database started from a project, from the Database tab of New project, or from the main Databases page answers on this server only unless you choose to publish its port on every interface.

For a PostgreSQL database that runs PgBouncer, a variable can hold the pooled reference ${{database.ID.pooled}} instead of the direct one. When a linked database switches to TLS, applications keep their connection string while TLS is allowed and receive one that encrypts once TLS is required. See the Databases guide.

Open Settings → Databases & backups to see Linked databases, test a connection, inspect the variables that carry it, and remove a link. If you remove a link, choose Remove the link or Remove the link and its variables. A database the application reaches through a variable that spells out this server's address and the database's published port is shown too, marked Reached by address. A successful connection test does not establish application health or prove the schema is correct. External databases keep their own hostnames and TLS options; the dashboard cannot create a private network inside a third-party provider.

Know what a backup provesCopy Anchor Link

Use Backups to create a job for the volumes, paths, SQLite files, and saved database connections the project needs. Jobs can write locally, to S3, or to Backblaze B2, run on a schedule, retain archives by count and age, and encrypt archives with the dashboard's backup key. Settings → Databases & backups shows the job a release depends on and warns when a linked database has no native dump in any job. Backup before a release makes the release wait for that job, and Require restore evidence refuses a release until a restore is verified. The gate compares the actual successful archive and its manifest with the project's writable data; editing a job after an old run does not make that old artifact cover new data.

For a saved database connection, a job can take a native or built-in dump and store it alongside its file archive. SQLite paths can use a transactionally consistent VACUUM INTO snapshot. A verified archive proves its recorded files and hashes are present; it does not by itself prove the application can start from the restored data. Verify restore can run an application checker against an isolated copy of one exact artifact when the job is configured for it. Multi-container recovery and external-service recovery require an application-specific plan. Point-in-time recovery is available for PostgreSQL servers the dashboard runs, from the Databases section, not from a project backup job.

The dashboard's own state is separate: back up JD_DATA_DIR and keep JD_MASTER_KEY separately. Both are needed to recover encrypted dashboard secrets. Read the backup guide and the release and rollback guide before a data-changing upgrade.