A Stopped App Has No Shell — What You Can Still Do, and the Disk Catch-22
The shell and the file browser both need your app to be running — they work by executing commands inside the live container, so if there's no container there's nothing to execute in. Logs and the event history stay available when an app is stopped, as do its settings. That distinction is usually academic and occasionally very much not: if a disk overrun stops every app in your account, the two tools you'd reach for to clean up files are exactly the two that stop working. Knowing that in advance is the difference between a five-minute fix and a support ticket.
On a new account, the first app also stops normally when its trial run ends. Add credit and start it again to keep it running. The same persistence rules apply: configuration and volumes remain, while in-memory state does not.
What's available when
| Running | Stopped | |
|---|---|---|
| Shell | Yes | No |
| File browser | Yes | No |
| Logs | Yes | Yes (what hasn't rotated) |
| Event history | Yes | Yes |
| Settings — env vars, ports, volumes, run command | Yes | Yes (applied on next start) |
| CPU/RAM preset | Yes | Yes (pending until start) |
The pattern is simple once you see it: anything that inspects the inside of the container needs the container; anything stored about the app is available either way.
That's also why the event history is worth checking first — it's one of the few things that works in every state, including after the app is long gone.
A crash-looping app still counts as running
This is the good news, and it's counter-intuitive.
Your process being dead doesn't mean the container is. The entrypoint supervises your process in a loop — it starts, dies, gets restarted five seconds later — so the container stays up throughout. That's why a crash-looping app reports as running, and it's why the shell and file browser keep working while your app is failing.
Which is exactly when you want them. You can open a shell on a bot that's crashing every five seconds and check whether the config file is there, whether the env var is set, whether the database it needs actually exists. The tools are available during the failure, not just after you've fixed it.
The disk catch-22
Here's the scenario worth pre-empting, because it's the one where these facts collide badly.
If your total disk usage exceeds the account limit, every application in the account is stopped and can't be restarted until the total drops back below it. That's account-wide, not per-app.
Now trace it through:
- A log file or a pile of old backups grows on a volume until you cross the limit.
- Every app stops.
- You go to delete the files — and the file browser needs a running app.
- You try a shell instead. Same problem.
The escape hatch is support: the published policy is that administrators can temporarily raise the limit for an affected account, which lets you start an app and clean up. That works, but it's a ticket and a wait rather than something you can fix yourself at 2am.
Prevention is cheap and worth doing on day one:
- Bound anything that writes. Rotate log files, cap cached media, prune old dumps. Backups written into a volume and never deleted are the most common cause.
- Prune from a scheduled task, not manually — the same in-process scheduler that runs your other jobs can delete files older than N days.
- Glance at the disk gauge on the Limits page occasionally. It's the one quota with an account-wide failure mode.
Get what you need before you stop it
A small habit that saves a round trip: if you're about to stop an app — to free allocation, to pause a staging bot, to park something you're not using — pull anything you want off it first.
- Download the database or dump while the file browser still works.
- Copy out the log you were reading, since it won't survive a redeploy anyway.
- Note the timestamps of anything interesting in the events, so you can find it again.
Stopping is reversible and the app keeps its configuration and volumes, so nothing is lost permanently — but the access to look inside is gone until you start it again.
Stopping is still the right move sometimes
None of this argues against stopping apps. It's the correct action when:
- You want to free CPU/RAM allocation for another app — the limits are shared across your account.
- A staging bot is sitting idle and you're at your app-count quota.
- Something is misbehaving publicly and you want it off the internet immediately.
- You want to freeze what's left of a log rather than let a crash loop consume it.
A stopped app keeps its volumes, env vars, ports, and settings, so it's a much better first move than deleting something you might want back.
One thing to be aware of: there's an inactivity cleanup process that can mark long-stopped apps stale and eventually remove them. It isn't automatic by default, and it's staged with warnings — the notifications are the signal, and starting the app clears the state.
FAQ
Why is the shell greyed out?
The app isn't running. Both the shell and the file browser execute inside the live container, so they need one to exist.
Can I browse files on a stopped app?
No. Start it first, or retrieve what you need before stopping it.
Do logs disappear when I stop an app?
No — what hasn't rotated stays viewable, and the event history persists regardless. It's the interactive tools that need a running container.
My app is crash-looping. Can I still use the shell?
On a zip deploy, yes — the container stays up while the supervisor restarts your process, so the shell and file browser work throughout. With your own image the container restarts too, so access comes and goes with it.
All my apps stopped because of disk usage — how do I delete files?
You'll need the limit temporarily raised so an app can start, which is a support request. Avoid it by rotating logs and pruning old backups before you get near the limit.
Does stopping an app delete anything?
No. Volumes, environment variables, ports, and settings are all kept. It's reversible.
Wrapping up
The rule is one sentence — tools that look inside a container need the container — and the only time it really bites is the disk overrun, where the safety mechanism and the cleanup tools disable each other. Bound whatever your app writes, prune old dumps on a schedule, and you'll never meet that particular corner. In every other situation, stopping an app is a safe, reversible pause that keeps everything you care about.