A Web Terminal and File Manager for Every Docker Container

The two commands every Docker user types most are docker exec -it <container> sh and some variation of docker cp. A shell to poke around, and a way to get files in and out. Panelica builds both directly into the panel: every container gets a web terminal and a full file manager, working over the browser with no SSH client, no docker CLI knowledge, and no local tooling. This post shows what that enables day to day — and explains a few of the less obvious problems it solves, like editing files in containers that do not even have a shell.

The web terminal: docker exec in a browser tab

Open any running container in Panelica's Docker Manager and attach a terminal. Under the hood this is a real interactive exec session streamed over a WebSocket to an xterm.js terminal in your browser — the same mechanism as docker exec -it, with a few practical additions:

• Correct sizing and resize. The terminal reports its columns and rows to the container, so full-screen tools like top, htop, and text editors render properly instead of wrapping into garbage.
• Choose the exec user. You can attach as the container's default user or specify another one — useful when the app runs as a non-root user and you need root to install a debugging tool, or the reverse: reproducing a permissions issue exactly as the app user sees it.
• No exposure. Nothing extra is published on the network. The session rides the panel's existing authenticated HTTPS connection, so "shell access to the container" does not mean "another open port".

Typical uses: checking why an app cannot reach its database (ping myapp-db, env | grep DB_), running an app's built-in CLI (WordPress wp-cli, Laravel artisan, database clients), or watching a process live while you trigger the bug from another tab.

The file manager: browse, edit, upload — inside the container

The container file manager gives you a directory tree of the container's filesystem with the operations you would expect from a normal file manager: browse, view and edit files in the panel's code editor, create files and directories, rename, delete, search by name, upload from your machine, and download to it.

Where this earns its keep:

• Config surgery. Most containerized apps have exactly one file you need to touch — config.php, .env, a YAML file. Editing it in place beats the docker cp out, edit, docker cp back dance.
• Log spelunking. Application logs that do not go to stdout (many PHP apps, Java apps) live in files inside the container. Open them directly instead of exec-ing in with tail.
• Quick content fixes. Replace a broken image, drop in a maintenance page, pull out a generated report — upload and download work per file with no volume gymnastics.

The clever part: it works on containers without a shell

Here is a problem you hit the moment you use modern minimal images: docker exec -it mycontainer sh answers "exec: sh: not found". Distroless and scratch-based images ship no shell, no ls, no coreutils — nothing but the application binary. Great for security and size, terrible for inspection.

Panelica's file manager handles this with a three-level fallback strategy:

1. If the container has ls, directory listings use it — fastest and richest.
2. If not, it tries find as an alternative lister.
3. If the image has no usable binaries at all, the panel falls back to Docker's archive API — the same mechanism behind docker cp — which reads the filesystem through the Docker engine itself, requiring nothing inside the container.

The practical consequence: you can browse, download from, and upload into even a distroless container. The terminal obviously still needs a shell to attach to, but file access never depends on what the image author included.

Where this fits with logs and stats

Terminal and files are two of the four inspection tools each container gets in the panel; the other two are streamed logs (stdout/stderr with tail and follow, the equivalent of docker logs -f) and live resource stats — CPU, memory, network — streaming into charts. Together they cover the standard debugging loop: notice a spike in stats, check the logs, open a terminal to investigate, fix the config file, restart. All from the same page, all recorded against your panel login rather than a shared root SSH key.

Who actually needs this?

• Home labbers get the biggest quality-of-life jump: no SSH keys on your laptop, tablet-friendly, and the app you deployed from a template is inspectable in the same UI you deployed it from.
• Agencies get safe delegation: a junior developer can debug a client's containerized app through the panel — with panel permissions and an audit trail — without holding server SSH credentials.
• VPS owners get speed: the distance between "something is wrong" and "I am looking at the log line" is two clicks, from any machine, including the one at the airport.

Frequently asked questions

Is a web terminal safe to expose?

The terminal is not "exposed" in the network sense — it tunnels through the panel's authenticated HTTPS session, protected by your panel login, optional two-factor authentication, and role permissions. Compare that to the common alternative: sharing the server's root SSH password so someone can run one docker exec.

Can I edit binary files or huge logs?

The editor is for text files and enforces a size ceiling — multi-gigabyte logs should be downloaded, not opened in a browser tab. Binary files can be downloaded and uploaded, just not edited inline.

Do changes inside the container survive a restart?

Restart, yes. Recreate, no — files written to the container's writable layer disappear when the container is recreated from its image. Persistent data belongs in volumes; that distinction and how to back volumes up correctly is covered in our stack backup post.

Does this replace SSH entirely?

For container work, mostly yes. For host-level administration Panelica also ships a server web terminal — but the point of per-container tools is narrower access: someone who needs to fix one app gets exactly that container, not the host.

The takeaway

Terminal, files, logs, and stats are the inspection loop of container operations, and putting them in the browser removes the two classic barriers: needing CLI fluency and needing SSH credentials. The shell-less image fallback is the detail to remember — with archive-API file access, even a distroless container stops being a black box.