Terminal
Terminal opens a real shell in your browser, running as your account's system user in your home directory, with the same runtimes, files, and resource limits as your applications.
It asks for no credentials; your panel sign-in is the authentication.
When a session closes or the connection drops, that session is gone. Use the browser terminal for work you watch, not for something that must keep running.
The shell runs as your login user, one of the three system users behind your account. The user security model explains who owns what, and how to run a command as the web user when a task needs it.
The browser terminal authenticates through the panel, so it works before you add an SSH key and after you lose the one you had.
Move files in and out of the terminal
Two commands connect the browser terminal and the computer in front of you:
| Command | What it does |
|---|---|
elup [DIRECTORY] | Opens your browser's file picker and uploads what you choose into DIRECTORY, or the current directory if none is given. |
eldown FILE | Sends one normal file at a time to your browser's downloads. For a directory, use tar or zip first. |
Both ask the browser to make the transfer, so they only work inside the
Elpan browser terminal. Over SSH, use scp or sftp. See SSH.
The terminal uploads nothing you didn't choose and downloads nothing you didn't name. Each request is valid for two minutes and usable once, so a request you ignore expires on its own.
When nothing happens
Run elup --check or eldown --check. It asks the terminal whether it can
make a transfer and prints the answer, transferring nothing:
$ elup --check
elup: this terminal supports Elpan file transfers (user example, capabilities up,down)
If it reports that the terminal didn't answer, the request isn't reaching a browser. The usual causes:
| Cause | Fix |
|---|---|
| You're in an SSH session, or another terminal that isn't the panel's. | Use scp or sftp. |
You're in tmux with passthrough off. tmux drops a request like this until told not to. | Run tmux set -g allow-passthrough on; to keep it, add set -g allow-passthrough on to ~/.tmux.conf. The commands say this themselves when they detect tmux. screen has no equivalent setting, so transfers don't work inside screen. |
| The browser tab is old. | Reload the terminal page. |
The terminal can report that it belongs to a different user than the one
running the command. Then you almost certainly used ssh to reach another
machine from inside the browser terminal. The request still reaches your
browser, but the files would move on the machine running the terminal,
not the one your shell is on.
Show an image in the terminal
The browser terminal draws images inside the text, so you can look at a screenshot, a chart, or a photo before publishing it, without downloading it first. It understands two protocols:
| Protocol | How to produce it |
|---|---|
| sixel | chafa -f sixels FILE is the first choice. Anything else that produces sixel works too, e.g. img2sixel or matplotlib's sixel backend. |
| iTerm2 inline images | A PNG, JPEG, or GIF sent as one sequence. This is what imgcat does. |
Nothing appears, and nothing is broken. With chafa:
-f kittyuses the kitty graphics protocol, which the terminal doesn't support.-f itermproduces TIFF, which a browser can't decode.
Both do nothing here. Ask for -f sixels.
What to expect from an image on screen:
- It's a picture inside the text grid, not a window floating above it. Text over those cells erases what it covers, and the shell prompt counts as text, so the next prompt covers part of an image from a command that doesn't end with a newline.
- Nothing moves. You get the first frame of an animated GIF.
- Resizing the terminal reflows the text, and an image doesn't survive that.
- One image can transfer at most 8 MB. A larger one is ignored, not drawn.
- Each terminal keeps the most recent 64 MB of images. As you scroll down, it forgets older ones and leaves a marker where each was.
- Images only work in the browser terminal. Over SSH, your own terminal program decides, and most support neither protocol.
A log page that looks like a terminal shows text from other people's software, which must not be able to draw a picture into the panel.
Long-running processes
A process you start in a terminal belongs to that session, whether from this page or from SSH.
Your provider must turn persistent services on for your account. Until then, the system stops your processes when your last session ends. A server you start by hand in the terminal stops when you disconnect.
That's not a limit to work around. Anything that must keep running belongs in an app server or a container, where the panel supervises, restarts, and logs it.