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

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. The rules are in What runs here.

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

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

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

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

• Read the app's logs (runtime, build and deploy).
• Inspect the database schema read-only, and measure or move the database.
• Restart the app, redeploy it, and change environment variables.