There's a File Browser in the Panel — Download a Backup Without a Shell

Every application has a file browser in the panel that operates on the running container — you can navigate the filesystem, download a file, upload one, edit a text file in place, and rename, create, or delete. It opens at your app's working directory, so your code is usually the first thing you see. The most useful thing it unlocks is downloading a database backup straight to your machine without a shell, an S3 bucket, or any scripting. The rule that decides whether anything you change actually sticks is the same one that governs everything else in a container: inside a volume it persists, anywhere else it's discarded on the next redeploy.

What it's genuinely good for#

Downloading a backup. This is the headline. Take a dump with the app's shell, then download it from the browser:

sqlite3 /data/bot.db ".backup '/data/backup.db'"

…then find /data/backup.db in the file browser and click download. For a small bot or side project, that's a complete backup routine with no object storage, no credentials, and no cron — which makes it far more likely to actually happen than a pipeline you keep meaning to build.

Checking a file is where you think it is. Half of "my app can't find its config" is a path assumption. Browsing beats guessing, and it's faster than opening a shell to run ls.

Seeing whether a volume mounted. Navigate to your volume path. If the directory is empty when it shouldn't be, or your file is sitting one level up in the container's own filesystem, that's your bug — and it's the classic cause of data disappearing on redeploy.

Uploading a seed file. A starter database, a lookup table, a certificate. Easier than baking it into the image for something you'll change occasionally.

Editing a config to test a theory. Change a value, restart, see what happens — with the caveat below.

The rule: volume or nothing#

Anything you upload or edit lands in the container's filesystem, and that filesystem is discarded when the container is recreated on redeploy.

So:

• A file uploaded into a volume path — /data, or wherever you mounted one — persists.
• A file uploaded anywhere else survives until your next deploy, then quietly disappears.

That makes the file browser excellent for getting things out and risky as a way of putting things in permanently. If you upload a config fix and don't also change it in your repository or image, you've built a system that works until the next deploy and then breaks for reasons nobody remembers.

Same framing as the shell: it's for looking and retrieving, not for making permanent changes. Anything permanent belongs in your image, a volume, or configuration.

It works even in a minimal image#

Worth knowing if you followed the advice to ship a small container: the file browser works by running commands inside your container, and a static busybox is mounted into every container regardless of what your image ships.

So a distroless Go service with nothing but a binary in it is still browsable. You don't have to choose between a small image and being able to see inside it.

Where it fits in a backup routine#

Be honest about what this is: a manual step. That's fine for some projects and not others.

• For a hobby bot or side project, dump-and-download once a week is genuinely better than the automated backup you haven't written. Done beats perfect.
• For anything you'd be upset to lose, it isn't enough. A manual routine stops the week you're busy, and you won't notice until you need it. Automate the dump and ship it off-platform.

The middle ground works well: automate the dump on a schedule so a recent copy always exists on the volume, then use the browser to pull one down whenever you want a local copy. That way the automation handles consistency and the manual step is just retrieval.

One thing to watch: dumps accumulating on a volume count against your disk quota, and total disk overruns stop every app in the account. Prune them.

It needs the app to be running#

The browser executes commands inside the live container, so it's unavailable on a stopped app — as is the shell. Retrieve anything you want before you stop something, and be aware that a disk overrun stops every app at once, which takes the file browser with it exactly when you'd want it for cleaning up.

The good news: on a zip deploy, a crash-looping app still counts as running, because the container stays up while the supervisor restarts your process — so the browser works during the failure, not just after you've fixed it. With your own image the container itself restarts, so you may need to catch it between restarts.

Be careful with delete and edit#

Two things have no undo:

• Delete removes the file. There's no trash. On a volume that means it's gone unless you have a backup.
• Edit writes immediately to a live application's filesystem. If your app reads that file at startup, nothing changes until it restarts; if it reads it per-request, the change takes effect mid-flight.

Neither is a reason to avoid the feature — just don't treat a live container's filesystem as a scratchpad while users are on it.

FAQ#

How do I download a file from my app?#

Open the app's file browser tab, navigate to the file, and use the download action. It reads from the running container.

Can I download my database?#

Yes — take a consistent dump first (sqlite3 .backup or pg_dump, not a raw copy of a live file), then download the dump.

Will a file I upload survive a redeploy?#

Only if you upload it into a volume path. Anywhere else lives in the container's writable layer and is discarded when the container is recreated.

Does it work with a distroless or scratch image?#

Yes. A static busybox is mounted into every container, so browsing works regardless of what your image contains.

Is editing a config here a permanent fix?#

No, unless the file is on a volume. Change it in your repository or image too, or the fix disappears on the next deploy.

Is this a backup solution?#

It's a manual one. Good enough for a hobby project; for anything important, automate the dump and store it off the platform.

Wrapping up#

The file browser is the kind of feature you don't look for until you need it and then use constantly — mostly to answer "is the file actually there?" and to pull a copy of something down. Keep the one rule in mind and it won't bite you: retrieving is always safe, and anything you put in only counts if it lands on a volume.