# Terminal and database console

Source: /docs/concepts/terminal-and-database-console

Under the hood of every running app there is a **terminal** and a **database console**, both in the panel on the app page. They are the way to look at what the app wrote and what it stored.

## The container is temporary, the database is not [#the-container-is-temporary-the-database-is-not]

Your app runs in a container that starts from a clean image on every deploy and every restart. Files it writes at runtime (a log file, an upload, a SQLite file) exist only until then. Everything that must survive belongs in the [database](/docs/concepts/database-migrations). The rules are in [What runs here](/docs/getting-started/what-runs-here).

That does not make the files invisible: while the container runs, the terminal shows them.

## Terminal [#terminal]

The **terminal** tab opens a shell inside the running container, as the app's own user, with the app's environment. Use it to:

* read a file the app wrote (`ls`, `cat`, `tail -f` a log),
* check what the process sees (`env` without the secret values, `ps`, the current directory),
* run a one-off command of your app (a migration script, a cache warm-up).

It is a live session with a running process. A command that changes files changes them until the next deploy; a command that stops the process stops your app.

## Database console [#database-console]

The **database** tab opens a SQL console on the app's database. Use it to look at tables and rows, to run a query your agent proposes, or to fix a record by hand. The console works on the live data, so the usual care applies: `SELECT` first, then change things.

## Why your agent cannot open them [#why-your-agent-cannot-open-them]

The coding agent connected through MCP can deploy, read logs, change variables and more, but it has no terminal and no SQL console on purpose: a shell in a running app and a console on live data are where one wrong command costs real data, and an agent cannot ask you before each line.

The way to work together is simple: ask the agent what to run, run it yourself in the terminal or the console, and paste the result back. If you prefer the agent to drive, give it a browser and let it use the panel like you would; that is your call and your responsibility.

## What the agent can do instead [#what-the-agent-can-do-instead]

* [Read the app's logs](/docs/concepts/logs-and-status) (runtime, build and deploy).
* [Inspect the database schema](/docs/mcp/tools) read-only, and measure or move the database.
* Restart the app, redeploy it, and change environment variables.