Running and troubleshooting

Start, stop, restart

The application’s detail carries the whole lifecycle in one row of buttons: Deploy, then Stop or Start depending on where it is, Restart, Edit and Delete.

Only one of Start and Stop is offered at a time — the one that would change something — and all of them are unavailable while a deploy, a rollback or another action is still running, so two conflicting operations cannot be started by clicking twice.

The same, from corepanel:

corepanel app stop    <account-id> api
corepanel app start   <account-id> api
corepanel app restart <account-id> api

start and stop also decide whether the application comes back after a reboot; restart does not change that. A stopped application keeps its releases, its data and its route — the path answers 502 until you start it again, which is the honest answer: the site is up, that path is not.

What the machine says

Two things are on screen at once, and they are not the same question:

• State — the badge next to the name, and what CorePanel last recorded: Running, Starting, Stopped, Failed, or Not deployed for one that has never shipped a release.
• Status — the System status card, and what systemd answers right now: unit, active state, main pid, last exit code, restart count, since when, whether it starts at boot, and whether the socket is there.

They agree while everything works and disagree exactly when something is wrong. An application CorePanel believes is running can be crash-looping, and the restart count is what tells you. The card re-reads itself every 15 seconds, and Refresh asks again on the spot.

An application registered but never deployed has no unit at all, and the card says so rather than reporting it as dead: the unit is written by the first successful deploy. If corepanel-sys cannot be reached, the card says that instead — the live status is missing, the application itself is unaffected.

The same, from corepanel:

corepanel app show <account-id> api

Logs

The Logs card at the bottom of the application fetches the journal on demand: press Show logs, and the refresh button beside it re-reads the last 400 lines.

There is no live streaming yet, so the button is what advances it.

The same, from corepanel:

corepanel app logs <account-id> api          # last 200 lines
corepanel app logs <account-id> api -n 1000  # up to 2000

The journal carries your program’s own output and the gateway’s, so a failure to bind the socket and a panic inside your handler both land in the same place. There is nothing to configure and no log file to rotate: write to stdout and stderr.

To follow it live, on the server:

journalctl -fu corepanel-app-<account>.<app>

Diagnosing

An application that failed says why on its own detail, before you open the journal: the state badge reads Failed, a Last failure band carries the reason, and the System status card underneath tells you whether it is dead or looping.

Read the three together. Above, the release did not answer within 45 seconds, the program exited with status 1, and it could not bind its socket — the port was already taken inside its namespace. Restarts: 5 and Socket: Missing confirm it never got far enough to listen, so this is a startup failure, not a request that went wrong.

The path answers 502

The web server reached the socket and got nothing back. In order of likelihood:

1. The application is stopped. The state badge says so — start it.
2. It is crash-looping. A rising restart count and a repeating error in the journal. The most common causes are a missing environment variable and a port mismatch.
3. It is not listening on $PORT. The program binds a hardcoded port different from the one configured. Either read $PORT or pass the same number in the start command.
4. It is wedged, not dead. Accepting connections and never answering. restart is the fast answer; a health path is what stops the next deploy from shipping it.

The deploy rolled itself back

That is the safety net working: the release did not answer, so the previous one was put back. The reason is on the application (lastError) and in the journal, and the tail of the journal is included in what the deploy reported.

Reproduce it outside CorePanel before deploying again: unpack the same archive on your machine, cd into it, and run the same command with the same variables. The working directory is the release root, and a program that only works because your shell exported something is the most frequent cause.

It was killed with no message

Look at the memory ceiling. A process that exceeds --mem is killed by the kernel — there is no graceful signal, no stack trace, and often nothing in the journal but the restart.

The limits are on the summary card (256 MB · 50% CPU · 64 tasks) and the restart count right below it; Edit raises the ceiling. From the command line:

corepanel app show <account-id> api           # limits and restart count
corepanel app update <account-id> api --mem 512

If it is killed again at a higher ceiling, it is a leak, not a limit.

Deploys are refused with “a deploy is already running”

One deploy at a time per application, shared by the panel, the CLI and the webhook. Wait for the running one; it finishes in seconds or fails on its own timeout. This also blocks deleting the application while a deploy is in flight, which is deliberate — a delete halfway through an extraction would leave files behind.

Deleting

Delete on the application asks once, and the question that matters is the toggle:

The same, from corepanel:

corepanel app delete <account-id> api

The application is unpublished, stopped, and its unit, program tree and socket are removed. The path goes back to being served from the document root, and the site is left healthy — there is no window in which it 502s.

The data directory is kept unless you turn Also delete its data on, or pass --purge-data. It is the one thing a redeploy cannot recreate, so destroying it takes saying so — and the toggle starts off every time the dialog opens, however you left it last.

Deleting a domain that still publishes applications is refused with a message naming them; corepanel domain delete --force removes them in cascade. Deleting the account removes them with their data, as with everything else the account owns.

Application data is not backed up yet

Know this before you put state in an application

$CP_APP_DATA survives deploys, rollbacks and deletion — but it is not included in the account backup. Neither are the applications themselves: a restored account comes back without them, and without their environment variables.

Until that gap closes, if your application keeps state on disk you cannot lose:

• Back that directory up yourself. A cron job that copies /var/opt/userapps/<account>/<app>/data off the server is enough, and CorePanel’s own cron jobs can run it.
• Or keep the state in a database. MySQL databases created through CorePanel are covered by the account backup as usual, so an application whose state lives there is already protected.

The program itself needs no backup: it is rebuilt from your repository and redeployed in one command.

What survives what

	Deploy	Rollback	delete	delete --purge-data	Account backup
Program tree	replaced	replaced	removed	removed	not included
$CP_APP_DATA	kept	kept	kept	removed	not included
Environment variables	kept	kept	removed	removed	not included
Releases (last 3)	pruned to 3	kept	removed	removed	not included
The route	kept	kept	removed	removed	n/a
MySQL databases	kept	kept	kept	kept	included