Web console

Every instance pod has a built-in browser terminal. No SSH client required.

When to use it

• You are on a network that blocks outbound SSH.
• You are on a borrowed machine and do not have your keys.
• You are debugging firewall rules and just locked yourself out.
• You just want to poke around quickly.

Open the Shell

1. Open Pods in the console, or click Pods in the side panel.
2. Find your pod in the table. The Running tab above the list narrows it down, and Search pods... filters by name.
3. Click the pod's name. You land on the pod's page, on the Overview tab.
4. Click Shell, the filled button at the top right of the page, just left of the ... menu. It is drawn only on a Running instance pod, so if it isn't there, check the status pill next to the pod's name: a pod that is Off needs Start from the ... menu first.
5. A black Terminal panel slides up over the bottom half of the window. It shows Connecting... for a moment, then gives you a prompt.
6. Click the x at the top right of the panel to close it. Leaving the page closes it too.

What you get

A root shell on the pod, opened for you:

root@i-6a4d5b83b7006ccae6391810:~# whoami
root
root@i-6a4d5b83b7006ccae6391810:~# pwd
/root

No password, no key, no port number, and no firewall rule. That last part is the useful one: the terminal talks to our API over HTTPS on port 443, not to the pod's public port, so an allow-list that has locked you out of SSH does not apply here. It is the way back in.

You are root, not the pod's login user, so files you create belong to root. If you are setting up something that runs as ubuntu, su - ubuntu first, or chown afterwards.

What it is not

• Not a replacement for SSH. No port forwarding, no scp, no agent forwarding, no rsync, no editor integration.
• Not a place to leave things running. The shell dies with the panel. Long jobs belong in tmux, screen, or a systemd unit.
• Not on database pods. Database pods have no Shell button at all - connect to those with a MySQL client, using the Public MySQL connection string on the pod's Connection Strings tab (see connection details).

How it works (briefly)

When you click Shell, the console asks the API for a short-lived access ticket (POST /api/pods/:id/console-ticket). The ticket is valid for 30 seconds and works exactly once. The browser then opens a WebSocket with that ticket attached.

So even if someone snags a console URL, they cannot replay it.

When it won't connect

What you see	What it means
Failed to obtain console ticket	The API refused the ticket. Either the pod isn't an instance pod, or your API key or role lacks the pod console permission.
Failed to connect to console	The ticket was fine but the WebSocket didn't open. Usually a proxy or corporate network that blocks WebSocket upgrades. Try another network, or SSH.
Connection closed. after an idle hour	The idle timeout. Sessions close after an hour with no input or output. Close the panel, click Shell again.
The panel opens but nothing happens for a long time	The console starts the pod's shell for you; a pod under heavy load can be slow to answer. Close the panel and reopen it for a fresh session.

Limitations

• Fixed size. The pod's terminal is 120 by 32 no matter how big your browser window is, so htop and vim can draw to the wrong size. stty rows 50 cols 200 fixes it for the session; use SSH for anything seriously full-screen.
• Scrollback is 5000 lines. Pipe anything longer to a file and read it back.
• No file transfer. Use scp, rsync, or an HTTP-based tool you install yourself. There is no upload button: a terminal in a browser is still a terminal.
• One tab, one session. Opening the Shell somewhere else gets you a second, separate session, not the first one back.