What Happens When the Panel Itself Won't Load
Panelica Rescue Mode is an independent recovery service that runs on port 8444, in its own binary, with no dependency on the panel backend, the database, or nginx. When the main panel at port 8443 stops responding, Rescue Mode stays reachable and gives you a system overview, the same fix engine used by the Repair Tool, and a full root terminal — all from a browser, without a support ticket or a rescue-boot reinstall.
Every panel has a blind spot: what do you do when the panel is the thing that is broken? If the backend crashes, the database goes down, or nginx fails to start after a bad config change, the usual answer is opening a support ticket with your hosting provider for console access, or waiting for a rescue-mode reboot.
Panelica ships with its own answer to that problem: Rescue Mode, a separate recovery service that stays up independently of the panel it is rescuing. If you have already gone through our initial VPS setup guide, think of Rescue Mode as the safety net that sits underneath everything you set up there.
What It Does
Rescue Mode runs on port 8444, as its own standalone binary with no dependency on the main backend, the database, or nginx. It is built to start on boot and stay running through a crash of everything else on the server — including a watchdog that restarts it if it ever hangs, and out-of-memory protection so it is not the first thing killed if memory runs low. Because it only waits on the network coming up rather than a fully online network stack, it is designed to start accepting connections earlier in the boot sequence than services with heavier startup dependencies.
Once you log in with the server's root system password, Rescue Mode gives you three things:
System Overview
A single screen with hostname, OS, kernel version, uptime, load average, CPU count, memory and swap usage, disk usage, listening ports, the top resource-consuming processes, any failed background services, recent login history, and recent error log lines — everything you would normally piece together with five different commands.
Diagnostics and Repair
The same fix engine used by the panel's Repair Tool is available here: restart a specific service, regenerate a broken configuration, free up disk space, or fix a user's file permissions — all from Rescue Mode, even while the main panel is completely unreachable. A dedicated Quick Actions panel also offers a service restart selector and a server reboot option, both requiring confirmation.
Root Terminal
A full terminal session, connected over a WebSocket to a real shell on the server, embedded directly in the Rescue Mode page. No separate SSH client needed — just a browser.
Login, TLS, and Brute-Force Protection
Rescue Mode is served over HTTPS: it reuses the panel's own TLS certificate when one is available, and falls back to generating a self-signed certificate automatically if it cannot. Login attempts are rate-limited per source address — enough failed attempts from one address locks that address out temporarily — and a separate global counter briefly locks the login page if failed attempts arrive from many addresses at once, a backstop against distributed brute-force attempts against an internet-facing port.
What Keeps It Running When Everything Else Fails
Rescue Mode is only useful if it survives the exact conditions that take the rest of the server down, so it is hardened specifically for that job, following the same boot-time service model covered in our systemd guide:
- It never stops retrying. The service restarts automatically on crash, and the usual systemd rule that gives up after repeated failures in a short window is disabled specifically for this service — it keeps restarting no matter how many times it crashes.
- A watchdog catches hangs, not just crashes. The process pings systemd on a fixed interval; if the event loop ever locks up without actually crashing, systemd notices the missed pings and restarts it anyway.
- It is the last process the kernel kills. When memory runs out, Linux's out-of-memory killer has to pick a victim. Rescue Mode's priority is set so the kernel sacrifices panel processes first, and a small slice of memory is reserved for it so it keeps running under memory pressure.
- It logs to the journal, not to a file. A full disk is one of the more common outages, and a service that logs to a file can fail to even start when the disk has no space left. Rescue Mode logs to the systemd journal instead, which keeps working when the disk is full — exactly when disk cleanup is needed most.
Rescue Mode vs. the Main Panel
| Main Panel | Rescue Mode | |
|---|---|---|
| Port | 8443 | 8444 |
| Process | panelica-server | Separate, standalone binary |
| Depends on | Database, nginx | None of the above |
| Login | Panel account (JWT, optional 2FA) | Server root system password |
| If it crashes | Panel becomes unreachable | Watchdog and systemd restart it automatically |
Common Scenarios Rescue Mode Is Built For
- A bad nginx configuration edit. Diagnostics and Repair can regenerate and validate the affected configuration, the same fix engine documented in the Repair Tool.
- A database that will not start after the disk filled up. The System Overview tab surfaces disk usage and failed services on the same screen, and Diagnostics and Repair includes a disk cleanup action.
- A backend process that hung instead of crashing. The Root Terminal lets you inspect and restart it manually, the same way you would over SSH, without needing a separate session.
- A fix that requires a full reboot. Quick Actions includes a server reboot option, gated behind a confirmation step so it is never triggered by accident.
How to Use It
- If your Panelica panel at port 8443 stops responding, open
https://your-server-ip:8444in a browser instead. - Log in with the server's root system password — the same one used for SSH.
- Check the Overview tab first: failed services, high load, or a full disk are usually visible immediately.
- Use Diagnostics & Repair to apply the fix that matches what you found — restarting the crashed service is often enough.
- If you need to run something manually, open the Root Terminal tab instead of starting a separate SSH session.
- Once the underlying problem is fixed, the main panel at port 8443 comes back on its own.
Why It Matters
A hosting panel that goes down with no way back in except a provider ticket or a rescue-boot reinstall is a single point of failure. Rescue Mode exists because the panel, the database, and nginx crashing should not mean losing access to the server that is still running underneath them. It is a lightweight, independent safety net that is there specifically for the moment everything else is not working. If the panel itself is healthy but a specific site is returning errors, the 502 Bad Gateway troubleshooting guide covers the same class of fixes from the command line for when you are not ready to reach for Rescue Mode.
Get it now: Rescue Mode is available on the latest Panelica release and starts automatically on boot. Update your panel, then keep https://your-server-ip:8444 bookmarked for the day you need it.
Frequently Asked Questions
Does Rescue Mode need the main panel to be running?
No. It runs as an independent process with no dependency on the panel backend, the database, or nginx.
What password do I use to log into Rescue Mode?
The server's root system password — the same one you would use for SSH.
Does Rescue Mode start automatically?
Yes. It is installed as a system service that starts on boot and restarts itself if it ever stops responding.
Does Rescue Mode use HTTPS?
Yes. It serves over TLS, reusing the panel's certificate when one is available and generating a self-signed certificate automatically if it cannot.
What happens if I enter the wrong password too many times?
Repeated failed logins from one address are locked out temporarily, and a separate global counter briefly locks the login page if failed attempts arrive from many addresses at once.