# Dashboard

Everything the CLI does, in your browser: deploy, watch builds live, read logs and metrics, roll back, scale, and manage domains, databases, variables, workers, and your team.

Sign in at your Deplane sign-in page with your passkey. The dashboard uses the same API as the CLI, so plan limits, permissions, and the activity log are the same whichever you use. Risky actions (deleting an app, creating a CI token, inviting someone) ask you to confirm it's you.

## Deploy from the browser

On **New app**, either:

- **Drop a folder or a .zip.** Deplane reads the project's manifest files (`package.json`, `requirements.txt`, `go.mod`, `Dockerfile`, …), says what it found ("Next.js 15, Node 22, port 3000"), and suggests a name. Git data, `.env` files, `node_modules` and Python virtual environments never leave your computer, and your `.gitignore` and `.dockerignore` are respected, exactly as with `deplane deploy`.
- **Start from a template**: an open-source app or a starter for a common stack (see [Templates](#templates) below).
- **Deploy a Docker image.** Type a public image such as `nginxinc/nginx-unprivileged:1.27`, its port, and optionally a name, and press Deploy. Deplane creates the app, sets the port, and deploys the image. Only public images work, and they run as user 10001, not root; see [Deploy a Docker image](quickstart.md#deploy-a-docker-image).

The deployment page shows each step (Uploaded, Building, Starting, Live) and streams the build log. When the app is live you get its address.

## Templates

The New app page has a gallery of templates: self-hosted open-source apps and starters for common stacks. Search, or pick a category. Each card shows what the template needs (Postgres, a disk, memory) and whether your team can deploy it:

- **Deploy**: it fits. Pick a name and press Deploy; each step shows live (create app, create database, attach, add disk, set secrets, build, deploy), and at the end you get the address and what to do first.
- **Deploy is disabled with a reason** such as "Needs 1 GB; you have 512 MB free": your plan can hold it, but your team's free room cannot. Free some room in [Apps](/apps) and it becomes available.
- **Greyed out, with Upgrade**: your plan is too small for it at all, for example "Needs 2.5 GB memory; Hobby has 1.5 GB".

If a step fails, everything made so far is kept and listed. **Retry** continues from the failed step. **Delete all of it** removes only the app, database and disk this deploy made, after you confirm with your passkey. A template's Deploy button can be linked from anywhere as `https://deplane.io/new?template=NAME`. See [Templates](templates.md).

## An app's page

| Tab | What it shows |
|---|---|
| Overview | A live preview, the production address, status, release, who deployed it and when, instances, size, domains, database, workers, five metric cards, recent deployments, and the live log |
| Deployments | Every release, with its [release command](release-command.md) state and, if it failed, the command's output, one-click rollback to an earlier good one (automatic rollbacks are marked Automatic), and every build with its log |
| Logs | The app's output (web instances, workers, and cron jobs), live, with pause and filter |
| Metrics | Requests, 5xx errors, p95 response time, CPU, and memory over 1 hour, 24 hours, 7 days, or 30 days (one point per day; p95 is not kept that long) |
| Workers & cron | [Workers and cron jobs](workers.md) |
| Domains | [Custom domains](domains.md), with the DNS records to copy |
| Variables | [Secrets](secrets.md), write-only |
| Settings | Instances and size, [autoscaling and sleep when idle](scaling.md), the app's [disk](disks.md), port and health check, the [release command](release-command.md), the [private network](private-networking.md) switch, [automatic rollback](cli.md#automatic-rollback), the [GitHub](github.md) connection with previews and preview databases, and deleting the app |

### Disk

The **Disk** card on the Settings tab adds a [disk](disks.md) to the app: type its path (`/data` unless you change it; the card checks the path as you type) and click **Add disk**. An app with a disk runs one instance; each deploy stops it for a few seconds.

Once the app has a disk, the card shows its path, its size (5 GB), the last backup, and every backup with its date, size, status and message (a failed backup says why). **Back up now** starts a backup, at most once an hour. **Restore** on a finished backup replaces all files on the disk with that backup, after you confirm and confirm it's you; the app stops while the restore runs, and the card shows the restore until it is done or, if it failed, that the disk may be empty. **Destroy disk** deletes the disk and its files, after you confirm it's you. While the app has a disk, the Scale card allows 0 or 1 instance and no autoscaling, and **Delete app** says the disk goes too.

## Databases

The Databases page lists your databases with their size, status, and the apps attached. Open one to see whether it has a live copy on another server (**Live copy on another server**, or a notice that it is running without one because its server is down; see [Live copy and failover](databases.md#live-copy-and-failover)), and for the **Backups** card (status, the restore window, the last full copy, **Restore...**), **Switch apps to this database** after a restore, and **Recently deleted** databases you can still restore. See [Databases](databases.md#backups-and-restore).

## Redis

On **Databases**, the **Redis** card lists your team's Redis with their status, apps and last backup. Create one by name; open one to see its address, attach or detach apps, back it up now, restore a backup (passkey), or destroy it (type its name, then passkey). An app's overview shows its Redis. See [Redis](redis.md).

## MySQL

On **Databases**, the **MySQL** card lists your team's MySQL with their status, size, apps and last backup, and says: "Single instance: down while its server is down. Backups nightly." Create one with a name and a size; open one to attach or detach apps, back it up now, restore a backup (passkey), or destroy it (type its name, then passkey). The card also lists the backups of MySQL you destroyed, which you can restore into another one. An app's overview shows its MySQL. See [MySQL](mysql.md).

## ClickHouse

On **Databases**, the **ClickHouse** card lists your team's ClickHouse databases with their status, size, disk used at the last backup against the 4.5 GB backup line, apps and last backup, and says: "Single instance: down while its server is down. Backups nightly; keep data under about 4.5 GB so backups have room." Create one with a name (it needs 2 GB of your plan's memory); open one to attach or detach apps, back it up now, restore a backup (passkey), or destroy it (type its name, then passkey). A separate card, **Backups of destroyed ClickHouse databases**, lists the backups of ones you destroyed: **Restore into…** puts one into a live ClickHouse database, which then uses the password of the backup's database, and its attached apps get the new `CLICKHOUSE_URL` and restart. If a restore brings back data saved under an older password, the card says that saved connections inside the data may fail to sign in until a newer backup is restored. If your plan cannot hold one, the card says "Upgrade to use ClickHouse" with the reason and a link to the plans, instead of the create form. An app's overview shows its ClickHouse database. See [ClickHouse®](clickhouse.md).

## Usage

**Usage** shows what your team used, over the last 24 hours, the last 7 days, the last 30 days, this month, or last month (dates are UTC). The dashboard remembers the range you picked. **Download CSV** saves the same numbers: one line per hour or day, then one line per app, database and disk.

| Number | What it means |
|---|---|
| Requests | Requests to your apps, counted at Deplane's edge. |
| Bandwidth out | Bytes your apps sent in responses, in 1000-based units (1 GB = 1,000,000,000 bytes), as the CLI shows them. |
| CPU hours | CPU time your apps used. One vCPU busy for one hour is one CPU hour. |
| Memory | **Reserved** GB-hours: the memory of every running instance's size, for as long as it ran, whether or not the app used it. **Used** is what your apps actually had in use; the card shows the average. Plan limits count reserved memory. |
| Build minutes | Build time this month, against your plan's monthly build minutes. This card always shows the current month, whatever the range. |
| Instances | How many instances run now, against your plan's limit, and the instance-hours in the range. |
| Database disk | Storage your databases held, in GB-hours. |
| App disks | Storage your apps' [disks](disks.md) held, in GB-hours (5 GB per disk). |

The charts stack requests and CPU hours by app (the six busiest, then Other); memory draws reserved as the area and used as a line; build minutes show the build time in each hour or day of the range. **By app** lists every app, database and disk (named after its app, such as "shop disk") with its totals, including apps deleted during the range, and each app's instances and size now (– for databases, disks and deleted apps). Databases and disks show their storage under Disk GB-h and – for requests, bandwidth and build minutes; disks have no CPU or memory either. Click an app to open its metrics over a matching period (30 days for the monthly ranges). Usage is kept for 400 days. The CLI shows the same numbers with `deplane usage --range month`.

## Team

**Activity** lists everything done in the team, by whom, and from where (dashboard, CLI, CI). **Members** is where owners invite people ([Team](team.md)), and **Tokens** lists CI tokens and CLI logins.