Logs and shell

Logs

Environment → Logs follows your containers’ output live. KamalCloud opens an SSH session to the machine on its own thread, tails the container, and streams it to the browser. It touches the database only to start and stop.

This is the running application’s log – not the deploy log. A deployment’s own output lives on the deployment and is kept.

Container logs are not stored by KamalCloud. Close the page and the stream ends; what you are watching is Docker’s own output on the machine. Anything you want kept should go to wherever you keep logs.

What the stream shows can be narrowed:

• The app or an accessory – follow the app’s container, or one of the environment’s accessories
• Lines – how much history to start from: 100, 200, 500 or 1000
• Since – only output after a point, as docker logs --since takes it: 42m, or a timestamp
• Filter – only lines containing a fixed string

Accessory console

An accessory opens its own client rather than a shell: psql for Postgres, mysql for MySQL, redis-cli and valkey-cli for the caches, with credentials already in the container’s environment. It is the fastest way to answer a question about the data without putting a password on a command line.

Shell

Environment → Shell is a terminal inside the running container, in the browser. KamalCloud opens SSH to the first machine of the primary role and runs docker exec -it into the app’s container there, starting bash where the image has it and sh where it does not. Pick an accessory instead and it opens that accessory’s container. It is admin only.

It is not a shell on the machine itself. It is a real shell in the container, though: it can change what is in there, and KamalCloud does not record what was typed.

Each session is saved with who opened it, when, and how long it lasted, and the page lists the last 10. A session is cut off after an hour, so a forgotten tab lets go.

What to use when

• Is it serving? Inspect a domain – it fetches the hostname and reports the certificate and headers.
• What is running here? The server’s Containers page reads Docker live.
• Why did the deploy fail? The deployment’s log, which is kept.
• Why is the app throwing? Logs.
• What does the database say? The accessory console.
• What does the app see from inside? Shell.
• Something on the machine itself. The provider’s console, or your own SSH session.