CommyPanel 0.8.0-rc.1 (release candidate)

Release candidate for testing. Not for production. This build has not yet been run end to end on a real server. If you try it, please use a test server and tell us what breaks.

Install this candidate (the normal one-line installer only installs the latest stable release):

curl -fsSL https://github.com/CommyPanel/panel/releases/download/v0.8.0-rc.1/install.sh | sudo bash -s -- --version 0.8.0-rc.1

Upgrade an existing install to it:

sudo commypanel upgrade --version 0.8.0-rc.1

Most useful to check: the upgrade itself, nginx reloads and the new nginx editor, a first Let's Encrypt certificate, a deploy with a release command, deploy on push from your Git host, and the live usage figures against docker stats.

---

CommyPanel 0.8.0

This release adds three things: the panel in seven languages, alerts that tell you when something needs attention, and backups that cover more: restore over an existing database, restore a volume, nightly volume archives and a look into your off-server copies. Please read Before you upgrade.

CommyPanel is still pre-1.0.

What's new

The panel in your language

• English, French, German, Spanish, Russian, Ukrainian and Turkish, all installed with the panel. The first-run setup page has a language box (it starts with your browser's language when it is offered), and that becomes the first admin's language.
• A language for every person. When you add a user you choose their language, and it starts as your own. Everyone changes theirs from the language menu in the top bar or under Settings → Appearance; it affects only their account. The login page uses the browser's language, with a box to change it for that visit.
• About 1,660 sentences are translated, with the permission names and explanations, status names, messages and Laravel's own form errors. Dates, numbers and durations follow the language. English is the fallback, so a sentence that is not translated yet shows in English.
• The translations are drafts, not yet reviewed by native speakers: see lang/README.md. Corrections and new languages are welcome as pull requests (one JSON file per language, checked by npm run i18n:check); see Translating the panel in CONTRIBUTING.md.

Alerts

• Settings → Notifications now has a list of targets (up to 10): Slack (also Mattermost and Rocket.Chat), Discord, Microsoft Teams, ntfy, Telegram or a generic JSON webhook. Each target has its own events, can be switched off, and has a Test button; the page shows when its last message arrived or why it failed. Email is not supported.
• Events: a deployment failed, was rolled back automatically, or succeeded; an app stopped answering or is back; a certificate could not be issued or renewed, or is about to expire; the disk reached 85% or 95%; a backup failed; a database server stopped or runs again. New targets start with the problems turned on.
• Messages are sent when something changes, not on every check: an app is called down after three failed checks in a row (one message), and one more when it answers again. Apps that are stopped, being deployed or watched after a release are not reported.
• An "Alerts for this app" switch on each app's Settings tab mutes one app.
• Your earlier single webhook became a target called Default, with the same address and format.
• Addresses are stored encrypted and never shown again, every address must be https and may not be this server or a reserved range, redirects are never followed, and messages never hold logs or secrets. See docs/notifications.md.

Backups that cover more

• Restore over an existing database. Next to Restore (into a new database), Restore over… replaces an existing database with a dump. It shows which apps use it, asks you to type its name and confirm your password, first takes a safety dump of the database as it is, then drops and recreates it and loads the dump. If loading fails, the safety dump is put back. The dump's engine must match the server. It is recorded in the audit log as a high-risk action.
• Restore a volume. Next to a volume archive, Restore stops the app, replaces the volume's files (a safety archive is taken first, the archive is unpacked next to the folder and swapped in at the end), and starts the app again, also when it failed. The agent restores only archives it made itself.
• Nightly volume archives. A switch per volume (off by default) archives it every night at 03:30 and keeps the newest 3; failures raise a backup.failed alert.
• Copies on remote storage. With the S3 copy on, Settings → Backups lists what is in your bucket and lets you download a file through the panel (password, audited). Nothing is restored from it automatically; the docs show how to recover a lost server.

Before you upgrade

• The upgrade adds tables and columns (alert targets and states, an alerts switch per app, a language per user, a nightly switch per volume) and moves your webhook into the new target list. It needs the agent from this release too: sudo commypanel upgrade.
• Volume archives made before 0.8.0 cannot be restored from the page, because the agent now records its archives. Make a new archive, or unpack an old one by hand as the docs describe.
• Existing users keep English until they choose another language.
• No new ports and no new permissions. notifications.manage covers all of the notification targets, and the per-app switch needs apps.update.
• The panel contacts the outside only for what you add: your alert targets, plus what it already did (update checks, the S3 copy, the address lookup).

Security notes

• Restoring a dump over a database and restoring a volume are new, privileged agent actions. Both accept only files the agent made itself (checked against its own record), validate every name, run one heavy job at a time within limits, and the volume restore refuses while any container uses the volume. The database restore runs the engine's fixed SQL with names and passwords validated, as before.
• A compromised panel still cannot make the agent load someone else's SQL or files: a downloaded copy from remote storage is never restored automatically.
• Alert addresses are secrets: encrypted at rest, never sent to a page, never in the audit log.

Known limitations

• Alerts have no email, and targets are not chosen per app (an app can be muted).
• The translations are unreviewed drafts, and text saved by background work (deployment errors and build logs, rollout notes) and the command line stay in English.
• Restoring from remote storage onto a new server is manual: the agent loads only what it made on this server. Keep a copy of APP_KEY from /etc/commypanel/env, since backups never hold it.
• A restore over a database makes linked apps see errors while it runs.

Requirements

Unchanged: Ubuntu 24.04 or 26.04, or Debian 13 or newer, with systemd; amd64 or arm64; root access; at least 1 GB of RAM.

# Install
curl -fsSL https://github.com/commypanel/panel/releases/latest/download/install.sh | sudo bash

# Upgrade
sudo commypanel upgrade

CommyPanel 0.7.0

CommyPanel 0.7.0

This release makes deployments safer: CommyPanel now looks at the real requests your app answers, rolls back by itself when a new release is clearly worse, and can release a new version to your visitors gradually. It also lets you open a database server to the internet for a limited time, and colours the audit log by risk. Please read Before you upgrade: the agent and the nginx sites change.

CommyPanel is still pre-1.0.

What's new

Request statistics (always on)

• nginx reports one line per proxied request to the agent through a Unix socket (no log files). The agent keeps ten-second counts of requests, errors and response times per container for the last hour, in memory. No addresses, paths, headers or cookies are recorded.
• The app's Usage tab has a Traffic card with requests, errors and response times, and marks when each release went live.

Watch after the switch, with automatic rollback

• After a release goes live, the previous container stays running for the watch time (5 minutes by default, 1 to 60). If the new release is clearly worse (more errors, or much slower, over enough requests, twice in a row) traffic is moved back at once and the release is marked Rolled back with the reason. A stopped container rolls back immediately. Too little traffic ends the watch without a verdict.
• On by default, switchable per app on the new Safe deploys tab. End the watch accepts a release early; a new deployment ends it too.
• Go live again on a rolled-back release puts it live with the same image, without a watch, for when the rollback was wrong.

Gradual rollout

• Off for every app. Turning it on lists what it asks of your app and needs your confirmation.
• Choose up to four steps (10 and 50 by default) and a hold time (5 minutes by default), automatic or manual. Visitors get a cookie that keeps them on one version, and raising the share never moves anybody back. A bad step moves everybody back; you can move on, give everybody the release, or abort at any time. New deployments wait while one is rolling out.
• A rollout that gets too few requests to judge waits (up to three times the hold time) and then asks you.
• The deployment page shows the share, the time left and the old and new release side by side.

Remote access to a database

• On a database server's page, Remote access opens it to the internet on a random port (10000 to 19999), only for the real IP addresses you list (never "everybody"), only with TLS, and for a time you choose (15 minutes to 7 days). When the time is up the port is closed completely and open connections are cut, active or not. Never is possible, with a red warning and a confirmation.
• The agent opens the port itself and checks every connection's source address; a client that does not ask for TLS is refused. The server gets its own certificate authority (the keys stay with the agent) and restarts once the first time to use it. Download the authority's certificate from the card to verify the server.
• Change the addresses or the time while it is open, or Close now. Deleting the server closes its port first.
• New permission databases.remote, a recent password for every change, and every change is in the audit log. See docs/databases.md.

Audit log colours

• Entries are graded: red for high-risk actions (opening a database to the internet, deleting data, access or an app), orange for sensitive ones (secrets viewed, access or settings changed, failures), plain for everything else. A legend sits above the table. You can filter the log by time (today, last 7 days, last month, last year or a date range) and by risk, and search the person, the action or the IP address (IPv4 or IPv6, whole or in part, in any spelling).

Smaller changes

• New deployment statuses rollout and rolled_back in the UI, in deployment messages (a rollback is reported as a failure) and in the API.
• A scheduler job (every minute) restarts a watch or rollout whose job was lost, for example after a restart.
• Switches on the app pages now use FlyonUI's switch class everywhere.

Before you upgrade

• Upgrade the agent and the installer files together: sudo commypanel upgrade. The agent's service file gets a new socket (/run/commypanel-metrics/metrics.sock, group www-data), and every app's nginx site is rewritten to report to it. If the agent runs without the socket, nothing is counted, the watch ends without a verdict, and a rollout waits for you.
• The upgrade adds columns to apps and deployments and a rollouts table. Back up /var/lib/commypanel as usual.
• One new permission: databases.remote (open a database to the internet). The built-in admin role gets it; give it to other roles on purpose. Safe deployments add none: changing the settings needs apps.update; moving a rollout on or aborting it needs apps.deploy.
• Remote access needs your firewall to allow the port you open, and the agent to be upgraded. Nothing is open after an upgrade. The ports come from 10000 to 19999, apart from the ones apps use (20000 to 29999), so you can allow that range for your own addresses in advance. If you tried a release candidate with a port opened in the older 20000 range, open that server again after upgrading.
• The watch is on for your existing apps from the first deployment after the upgrade. Turn it off per app if you do not want it.

Security notes

• The agent now listens on TCP for the first time, but only while you have opened a database. The public port is a fixed-purpose proxy: it accepts the listed source addresses only, requires TLS from the client, closes itself at the end time, and closes everything when the agent stops. The panel cannot ask it for anything else, and a compromised panel can open a database only to addresses it names, which is the same power as databases.remote.

• The TLS keys and the certificate authority's key live in the agent's own state directory, outside the panel's data directory; the panel never reads them.

• The metrics socket accepts datagrams only and is writable by nginx's group, so any local process in that group could send forged lines. They can only skew statistics, never run anything. The agent parses each line against a strict format and caps the number of tracked sites and containers.

• Gradual rollouts are rendered by the agent from validated numbers and ports; the generated nginx code never contains text from a request.

• The rollout cookie is HttpOnly, SameSite=Lax, and Secure over https.

Known limitations

• Only errors and response times are judged, and only requests that pass nginx.
• Two versions run at once during a rollout against the same database and volumes. Migrations must work with both.
• Clients that refuse cookies can switch between versions during a rollout.
• Statistics are kept in memory and start empty when the agent restarts.
• Remote access does not work through Cloudflare's proxy, needs a firewall rule you make yourself, and the certificate covers the server's addresses at the time it was made.
• Not in this release: wildcard certificates.

Requirements

Unchanged: Ubuntu 24.04 or 26.04, or Debian 13 or newer, with systemd; amd64 or arm64; root access; at least 1 GB of RAM.

# Install
curl -fsSL https://github.com/commypanel/panel/releases/latest/download/install.sh | sudo bash

# Upgrade
sudo commypanel upgrade

CommyPanel 0.7.0-rc.3 (release candidate)

Release candidate for testing. Not for production. This build has not yet been run end to end on a real server. If you try it, please use a test server and tell us what breaks.

Install this candidate (the normal one-line installer only installs the latest stable release):

curl -fsSL https://github.com/CommyPanel/panel/releases/download/v0.7.0-rc.3/install.sh | sudo bash -s -- --version 0.7.0-rc.3

Upgrade an existing install to it:

sudo commypanel upgrade --version 0.7.0-rc.3

Most useful to check: the upgrade itself, nginx reloads and the new nginx editor, a first Let's Encrypt certificate, a deploy with a release command, deploy on push from your Git host, and the live usage figures against docker stats.

---

CommyPanel 0.7.0

This release makes deployments safer: CommyPanel now looks at the real requests your app answers, rolls back by itself when a new release is clearly worse, and can release a new version to your visitors gradually. It also lets you open a database server to the internet for a limited time, and colours the audit log by risk. Please read Before you upgrade: the agent and the nginx sites change.

CommyPanel is still pre-1.0.

What's new

Request statistics (always on)

• nginx reports one line per proxied request to the agent through a Unix socket (no log files). The agent keeps ten-second counts of requests, errors and response times per container for the last hour, in memory. No addresses, paths, headers or cookies are recorded.
• The app's Usage tab has a Traffic card with requests, errors and response times, and marks when each release went live.

Watch after the switch, with automatic rollback

• After a release goes live, the previous container stays running for the watch time (5 minutes by default, 1 to 60). If the new release is clearly worse (more errors, or much slower, over enough requests, twice in a row) traffic is moved back at once and the release is marked Rolled back with the reason. A stopped container rolls back immediately. Too little traffic ends the watch without a verdict.
• On by default, switchable per app on the new Safe deploys tab. End the watch accepts a release early; a new deployment ends it too.
• Go live again on a rolled-back release puts it live with the same image, without a watch, for when the rollback was wrong.

Gradual rollout

• Off for every app. Turning it on lists what it asks of your app and needs your confirmation.
• Choose up to four steps (10 and 50 by default) and a hold time (5 minutes by default), automatic or manual. Visitors get a cookie that keeps them on one version, and raising the share never moves anybody back. A bad step moves everybody back; you can move on, give everybody the release, or abort at any time. New deployments wait while one is rolling out.
• A rollout that gets too few requests to judge waits (up to three times the hold time) and then asks you.
• The deployment page shows the share, the time left and the old and new release side by side.

Remote access to a database

• On a database server's page, Remote access opens it to the internet on a random port (20000 to 29999), only for the real IP addresses you list (never "everybody"), only with TLS, and for a time you choose (15 minutes to 7 days). When the time is up the port is closed completely and open connections are cut, active or not. Never is possible, with a red warning and a confirmation.
• The agent opens the port itself and checks every connection's source address; a client that does not ask for TLS is refused. The server gets its own certificate authority (the keys stay with the agent) and restarts once the first time to use it. Download the authority's certificate from the card to verify the server.
• Change the addresses or the time while it is open, or Close now. Deleting the server closes its port first.
• New permission databases.remote, a recent password for every change, and every change is in the audit log. See docs/databases.md.

Audit log colours

• Entries are graded: red for high-risk actions (opening a database to the internet, deleting data, access or an app), orange for sensitive ones (secrets viewed, access or settings changed, failures), plain for everything else. A legend sits above the table. You can filter the log by time (today, last 7 days, last month, last year or a date range) and by risk, and search the person, the action or the IP address (IPv4 or IPv6, whole or in part, in any spelling).

Smaller changes

• New deployment statuses rollout and rolled_back in the UI, in deployment messages (a rollback is reported as a failure) and in the API.
• A scheduler job (every minute) restarts a watch or rollout whose job was lost, for example after a restart.
• Switches on the app pages now use FlyonUI's switch class everywhere.

Before you upgrade

• Upgrade the agent and the installer files together: sudo commypanel upgrade. The agent's service file gets a new socket (/run/commypanel-metrics/metrics.sock, group www-data), and every app's nginx site is rewritten to report to it. If the agent runs without the socket, nothing is counted, the watch ends without a verdict, and a rollout waits for you.
• The upgrade adds columns to apps and deployments and a rollouts table. Back up /var/lib/commypanel as usual.
• One new permission: databases.remote (open a database to the internet). The built-in admin role gets it; give it to other roles on purpose. Safe deployments add none: changing the settings needs apps.update; moving a rollout on or aborting it needs apps.deploy.
• Remote access needs your firewall to allow the port you open, and the agent to be upgraded. Nothing is open after an upgrade.
• The watch is on for your existing apps from the first deployment after the upgrade. Turn it off per app if you do not want it.

Security notes

• The agent now listens on TCP for the first time, but only while you have opened a database. The public port is a fixed-purpose proxy: it accepts the listed source addresses only, requires TLS from the client, closes itself at the end time, and closes everything when the agent stops. The panel cannot ask it for anything else, and a compromised panel can open a database only to addresses it names, which is the same power as databases.remote.

• The TLS keys and the certificate authority's key live in the agent's own state directory, outside the panel's data directory; the panel never reads them.

• The metrics socket accepts datagrams only and is writable by nginx's group, so any local process in that group could send forged lines. They can only skew statistics, never run anything. The agent parses each line against a strict format and caps the number of tracked sites and containers.

• Gradual rollouts are rendered by the agent from validated numbers and ports; the generated nginx code never contains text from a request.

• The rollout cookie is HttpOnly, SameSite=Lax, and Secure over https.

Known limitations

• Only errors and response times are judged, and only requests that pass nginx.
• Two versions run at once during a rollout against the same database and volumes. Migrations must work with both.
• Clients that refuse cookies can switch between versions during a rollout.
• Statistics are kept in memory and start empty when the agent restarts.
• Remote access does not work through Cloudflare's proxy, needs a firewall rule you make yourself, and the certificate covers the server's addresses at the time it was made.
• Not in this release: wildcard certificates.

Requirements

Unchanged: Ubuntu 24.04 or 26.04, or Debian 13 or newer, with systemd; amd64 or arm64; root access; at least 1 GB of RAM.

# Install
curl -fsSL https://github.com/commypanel/panel/releases/latest/download/install.sh | sudo bash

# Upgrade
sudo commypanel upgrade

CommyPanel 0.7.0-rc.2 (release candidate)

Release candidate for testing. Not for production. This build has not yet been run end to end on a real server. If you try it, please use a test server and tell us what breaks.

Install this candidate (the normal one-line installer only installs the latest stable release):

curl -fsSL https://github.com/CommyPanel/panel/releases/download/v0.7.0-rc.2/install.sh | sudo bash -s -- --version 0.7.0-rc.2

Upgrade an existing install to it:

sudo commypanel upgrade --version 0.7.0-rc.2

Most useful to check: the upgrade itself, nginx reloads and the new nginx editor, a first Let's Encrypt certificate, a deploy with a release command, deploy on push from your Git host, and the live usage figures against docker stats.

---

CommyPanel 0.7.0

This release makes deployments safer: CommyPanel now looks at the real requests your app answers, rolls back by itself when a new release is clearly worse, and can release a new version to your visitors gradually. It also lets you open a database server to the internet for a limited time, and colours the audit log by risk. Please read Before you upgrade: the agent and the nginx sites change.

CommyPanel is still pre-1.0.

What's new

Request statistics (always on)

• nginx reports one line per proxied request to the agent through a Unix socket (no log files). The agent keeps ten-second counts of requests, errors and response times per container for the last hour, in memory. No addresses, paths, headers or cookies are recorded.
• The app's Usage tab has a Traffic card with requests, errors and response times, and marks when each release went live.

Watch after the switch, with automatic rollback

• After a release goes live, the previous container stays running for the watch time (5 minutes by default, 1 to 60). If the new release is clearly worse (more errors, or much slower, over enough requests, twice in a row) traffic is moved back at once and the release is marked Rolled back with the reason. A stopped container rolls back immediately. Too little traffic ends the watch without a verdict.
• On by default, switchable per app on the new Safe deploys tab. End the watch accepts a release early; a new deployment ends it too.
• Go live again on a rolled-back release puts it live with the same image, without a watch, for when the rollback was wrong.

Gradual rollout

• Off for every app. Turning it on lists what it asks of your app and needs your confirmation.
• Choose up to four steps (10 and 50 by default) and a hold time (5 minutes by default), automatic or manual. Visitors get a cookie that keeps them on one version, and raising the share never moves anybody back. A bad step moves everybody back; you can move on, give everybody the release, or abort at any time. New deployments wait while one is rolling out.
• A rollout that gets too few requests to judge waits (up to three times the hold time) and then asks you.
• The deployment page shows the share, the time left and the old and new release side by side.

Remote access to a database

• On a database server's page, Remote access opens it to the internet on a random port (20000 to 29999), only for the real IP addresses you list (never "everybody"), only with TLS, and for a time you choose (15 minutes to 7 days). When the time is up the port is closed completely and open connections are cut, active or not. Never is possible, with a red warning and a confirmation.
• The agent opens the port itself and checks every connection's source address; a client that does not ask for TLS is refused. The server gets its own certificate authority (the keys stay with the agent) and restarts once the first time to use it. Download the authority's certificate from the card to verify the server.
• Change the addresses or the time while it is open, or Close now. Deleting the server closes its port first.
• New permission databases.remote, a recent password for every change, and every change is in the audit log. See docs/databases.md.

Audit log colours

• Entries are graded: red for high-risk actions (opening a database to the internet, deleting data, access or an app), orange for sensitive ones (secrets viewed, access or settings changed, failures), plain for everything else. A legend sits above the table.

Smaller changes

• New deployment statuses rollout and rolled_back in the UI, in deployment messages (a rollback is reported as a failure) and in the API.
• A scheduler job (every minute) restarts a watch or rollout whose job was lost, for example after a restart.
• Switches on the app pages now use FlyonUI's switch class everywhere.

Before you upgrade

• Upgrade the agent and the installer files together: sudo commypanel upgrade. The agent's service file gets a new socket (/run/commypanel-metrics/metrics.sock, group www-data), and every app's nginx site is rewritten to report to it. If the agent runs without the socket, nothing is counted, the watch ends without a verdict, and a rollout waits for you.
• The upgrade adds columns to apps and deployments and a rollouts table. Back up /var/lib/commypanel as usual.
• One new permission: databases.remote (open a database to the internet). The built-in admin role gets it; give it to other roles on purpose. Safe deployments add none: changing the settings needs apps.update; moving a rollout on or aborting it needs apps.deploy.
• Remote access needs your firewall to allow the port you open, and the agent to be upgraded. Nothing is open after an upgrade.
• The watch is on for your existing apps from the first deployment after the upgrade. Turn it off per app if you do not want it.

Security notes

• The agent now listens on TCP for the first time, but only while you have opened a database. The public port is a fixed-purpose proxy: it accepts the listed source addresses only, requires TLS from the client, closes itself at the end time, and closes everything when the agent stops. The panel cannot ask it for anything else, and a compromised panel can open a database only to addresses it names, which is the same power as databases.remote.

• The TLS keys and the certificate authority's key live in the agent's own state directory, outside the panel's data directory; the panel never reads them.

• The metrics socket accepts datagrams only and is writable by nginx's group, so any local process in that group could send forged lines. They can only skew statistics, never run anything. The agent parses each line against a strict format and caps the number of tracked sites and containers.

• Gradual rollouts are rendered by the agent from validated numbers and ports; the generated nginx code never contains text from a request.

• The rollout cookie is HttpOnly, SameSite=Lax, and Secure over https.

Known limitations

• Only errors and response times are judged, and only requests that pass nginx.
• Two versions run at once during a rollout against the same database and volumes. Migrations must work with both.
• Clients that refuse cookies can switch between versions during a rollout.
• Statistics are kept in memory and start empty when the agent restarts.
• Remote access does not work through Cloudflare's proxy, needs a firewall rule you make yourself, and the certificate covers the server's addresses at the time it was made.
• Not in this release: wildcard certificates.

Requirements

Unchanged: Ubuntu 24.04 or 26.04, or Debian 13 or newer, with systemd; amd64 or arm64; root access; at least 1 GB of RAM.

# Install
curl -fsSL https://github.com/commypanel/panel/releases/latest/download/install.sh | sudo bash

# Upgrade
sudo commypanel upgrade

CommyPanel 0.7.0-rc.1 (release candidate)

Release candidate for testing. Not for production. This build has not yet been run end to end on a real server. If you try it, please use a test server and tell us what breaks.

Install this candidate (the normal one-line installer only installs the latest stable release):

curl -fsSL https://github.com/CommyPanel/panel/releases/download/v0.7.0-rc.1/install.sh | sudo bash -s -- --version 0.7.0-rc.1

Upgrade an existing install to it:

sudo commypanel upgrade --version 0.7.0-rc.1

Most useful to check: the upgrade itself, nginx reloads and the new nginx editor, a first Let's Encrypt certificate, a deploy with a release command, deploy on push from your Git host, and the live usage figures against docker stats.

---

CommyPanel 0.7.0

This release makes deployments safer: CommyPanel now looks at the real requests your app answers, rolls back by itself when a new release is clearly worse, and can release a new version to your visitors gradually. Please read Before you upgrade: the agent and the nginx sites change.

CommyPanel is still pre-1.0.

What's new

Request statistics (always on)

• nginx reports one line per proxied request to the agent through a Unix socket (no log files). The agent keeps ten-second counts of requests, errors and response times per container for the last hour, in memory. No addresses, paths, headers or cookies are recorded.
• The app's Usage tab has a Traffic card with requests, errors and response times, and marks when each release went live.

Watch after the switch, with automatic rollback

• After a release goes live, the previous container stays running for the watch time (5 minutes by default, 1 to 60). If the new release is clearly worse (more errors, or much slower, over enough requests, twice in a row) traffic is moved back at once and the release is marked Rolled back with the reason. A stopped container rolls back immediately. Too little traffic ends the watch without a verdict.
• On by default, switchable per app on the new Safe deploys tab. End the watch accepts a release early; a new deployment ends it too.
• Go live again on a rolled-back release puts it live with the same image, without a watch, for when the rollback was wrong.

Gradual rollout

• Off for every app. Turning it on lists what it asks of your app and needs your confirmation.
• Choose up to four steps (10 and 50 by default) and a hold time (5 minutes by default), automatic or manual. Visitors get a cookie that keeps them on one version, and raising the share never moves anybody back. A bad step moves everybody back; you can move on, give everybody the release, or abort at any time. New deployments wait while one is rolling out.
• A rollout that gets too few requests to judge waits (up to three times the hold time) and then asks you.
• The deployment page shows the share, the time left and the old and new release side by side.

Smaller changes

• New deployment statuses rollout and rolled_back in the UI, in deployment messages (a rollback is reported as a failure) and in the API.
• A scheduler job (every minute) restarts a watch or rollout whose job was lost, for example after a restart.
• Switches on the app pages now use FlyonUI's switch class everywhere.

Before you upgrade

• Upgrade the agent and the installer files together: sudo commypanel upgrade. The agent's service file gets a new socket (/run/commypanel-metrics/metrics.sock, group www-data), and every app's nginx site is rewritten to report to it. If the agent runs without the socket, nothing is counted, the watch ends without a verdict, and a rollout waits for you.
• The upgrade adds columns to apps and deployments and a rollouts table. Back up /var/lib/commypanel as usual.
• No new permissions. Changing the settings needs apps.update; moving a rollout on or aborting it needs apps.deploy.
• The watch is on for your existing apps from the first deployment after the upgrade. Turn it off per app if you do not want it.

Security notes

• The metrics socket accepts datagrams only and is writable by nginx's group, so any local process in that group could send forged lines. They can only skew statistics, never run anything. The agent parses each line against a strict format and caps the number of tracked sites and containers.
• Gradual rollouts are rendered by the agent from validated numbers and ports; the generated nginx code never contains text from a request.
• The rollout cookie is HttpOnly, SameSite=Lax, and Secure over https.

Known limitations

• Only errors and response times are judged, and only requests that pass nginx.
• Two versions run at once during a rollout against the same database and volumes. Migrations must work with both.
• Clients that refuse cookies can switch between versions during a rollout.
• Statistics are kept in memory and start empty when the agent restarts.
• Not in this release: wildcard certificates.

Requirements

Unchanged: Ubuntu 24.04 or 26.04, or Debian 13 or newer, with systemd; amd64 or arm64; root access; at least 1 GB of RAM.

# Install
curl -fsSL https://github.com/commypanel/panel/releases/latest/download/install.sh | sudo bash

# Upgrade
sudo commypanel upgrade

CommyPanel 0.6.0

CommyPanel 0.6.0

This release adds four things: opening a database in phpMyAdmin or pgAdmin, API tokens for scripts and CI, deployment messages to a chat, and a one-click GitHub connection. Please read Before you upgrade: the database tools need a new port open in your firewall.

CommyPanel is still pre-1.0.

What's new

Apply changes without redeploying

• After you change environment variables, volumes or links, the app page offers Apply changes: a new container is made from the version that is already running, with the new settings, and swapped in with the usual zero-downtime switch. No clone, no build, and a failed health check changes nothing. Before, these only took effect with the next full deployment.

Database tools

• A phpMyAdmin / pgAdmin button next to each database (phpMyAdmin for MySQL and MariaDB, pgAdmin for PostgreSQL). pgAdmin's image is about 600 MB, so the first opening of a PostgreSQL database takes a while to download. It starts a short-lived container, shows progress while it pulls and starts, and opens the tool in a new tab by itself.
• You are logged in as that database's own user, never as the administrator, and the password never reaches your browser and is written to no file or setting of the tool's container (pgAdmin holds it only in memory, unsaved, for your session).
• A session ends after 15 minutes without use (4 hours at most) and the container is removed; at most 6 run at once. The page tells you this before you open one.
• The tools are served on port 2053 (COMMYPANEL_TOOLS_PORT), a port of their own, because a browser treats another port as another origin: a flaw inside a tool cannot read the panel's pages. 2053 is one Cloudflare also proxies, for panels behind Cloudflare.
• New permission databases.tools, password confirmation, and an audit entry for every opening. Treat it like the database's password.

API tokens

• Settings > API tokens (permission tokens.manage) creates tokens for scripts and CI: list apps, start a deployment and follow it. Abilities are apps:read and apps:deploy; a token can be limited to chosen apps and lasts 30 days to a year, or never expires (with a clear warning, and revoking or deleting the owner ends it). Creating one has a page of its own. It is shown once, only a hash is stored, and it is checked against its owner's current permissions on every call.
• Failed attempts are counted before the token is looked up, a token gets 60 calls a minute, and there is no CORS. See docs/api.md, which has a GitHub Actions example.

Deployment messages

• Settings > Notifications sends the result of a deployment to Slack (and Mattermost, Rocket.Chat), Discord or any webhook as JSON: only failures, or every result. Messages hold the app, commit and reason, never logs or secrets. The address is stored encrypted and must be https; this server, reserved ranges and the cloud metadata address are refused. New permission notifications.manage. See docs/notifications.md.

GitHub

• Settings > GitHub creates a GitHub App for the panel through GitHub's manifest flow: no tokens or deploy keys to paste. New apps can pick a repository from a list; each clone uses a read-only token for that one repository that expires after an hour.
• Deploy on push is a switch when you create the app from a GitHub repository, and later on its Settings tab, where it asks you to confirm turning it on or off. It is off unless you turn it on; every other app has it off too.
• New permission github.manage. Anyone who may create apps can deploy any repository the GitHub app may read, so give it access only to what should be deployable. See docs/github.md.

Before you upgrade

• Open port 2053 in your firewall (next to 80, 443 and 8443) if you want to use the database tools. The installer prints the reminder.
• The upgrade adds a few columns to apps and deployments, rewrites the agent's service file (a second socket for the tools) and the panel's nginx site. Back up /var/lib/commypanel as usual and upgrade with sudo commypanel upgrade.
• New permissions: databases.tools, tokens.manage, notifications.manage and github.manage. The built-in admin role gets them; give them to other roles on purpose.
• The panel contacts the outside in more cases, all started by you: api.github.com and github.com when you use the GitHub page, create an app from it or deploy one, and your chat's webhook address once you switch messages on. Update checks, your S3 copy and the address lookup are as before.

Security notes

• The database tools' proxy is the security boundary: single-use ticket (60 s), a cookie limited to its own session path, only the tool's own cookies forwarded, redirects kept inside the session, no WebSocket upgrades, a body limit. The agent chooses the tool image and network; a request cannot.
• API tokens, deployment messages and the GitHub App keep their secrets encrypted and never show them again. The GitHub return works once, bound to your session, within ten minutes; its webhook accepts only this app's signed pushes.

Known limitations

• Cookies ignore ports, so a script running inside a database tool could still fill the cookie jar of the host and read cookies that are not HttpOnly. A separate host name for the tools (planned with wildcard certificates) is the real fix.
• Deployment messages are one webhook for the whole panel, and not email. GitHub Enterprise Server is not supported, and GitLab, Gitea and Bitbucket stay on deploy keys.
• Not in this release: wildcard certificates.

Requirements

Unchanged: Ubuntu 24.04 or 26.04, or Debian 13 or newer, with systemd; amd64 or arm64; root access; at least 1 GB of RAM.

# Install
curl -fsSL https://github.com/emrecanful/commypanel/releases/latest/download/install.sh | sudo bash

# Upgrade
sudo commypanel upgrade

CommyPanel 0.6.0-rc.3 (release candidate)

Release candidate for testing. Not for production. This build has not yet been run end to end on a real server. If you try it, please use a test server and tell us what breaks.

Install this candidate (the normal one-line installer only installs the latest stable release):

curl -fsSL https://github.com/emrecanful/commypanel/releases/download/v0.6.0-rc.3/install.sh | sudo bash -s -- --version 0.6.0-rc.3

Upgrade an existing install to it:

sudo commypanel upgrade --version 0.6.0-rc.3

Most useful to check: the upgrade itself, nginx reloads and the new nginx editor, a first Let's Encrypt certificate, a deploy with a release command, deploy on push from your Git host, and the live usage figures against docker stats.

---

CommyPanel 0.6.0

This release adds four things: opening a database in phpMyAdmin or pgAdmin, API tokens for scripts and CI, deployment messages to a chat, and a one-click GitHub connection. Please read Before you upgrade: the database tools need a new port open in your firewall.

CommyPanel is still pre-1.0.

What's new

Apply changes without redeploying

• After you change environment variables, volumes or links, the app page offers Apply changes: a new container is made from the version that is already running, with the new settings, and swapped in with the usual zero-downtime switch. No clone, no build, and a failed health check changes nothing. Before, these only took effect with the next full deployment.

Database tools

• A phpMyAdmin / pgAdmin button next to each database (phpMyAdmin for MySQL and MariaDB, pgAdmin for PostgreSQL). pgAdmin's image is about 600 MB, so the first opening of a PostgreSQL database takes a while to download. It starts a short-lived container, shows progress while it pulls and starts, and opens the tool in a new tab by itself.
• You are logged in as that database's own user, never as the administrator, and the password never reaches your browser and is written to no file or setting of the tool's container (pgAdmin holds it only in memory, unsaved, for your session).
• A session ends after 15 minutes without use (4 hours at most) and the container is removed; at most 6 run at once. The page tells you this before you open one.
• The tools are served on port 2053 (COMMYPANEL_TOOLS_PORT), a port of their own, because a browser treats another port as another origin: a flaw inside a tool cannot read the panel's pages. 2053 is one Cloudflare also proxies, for panels behind Cloudflare.
• New permission databases.tools, password confirmation, and an audit entry for every opening. Treat it like the database's password.

API tokens

• Settings > API tokens (permission tokens.manage) creates tokens for scripts and CI: list apps, start a deployment and follow it. Abilities are apps:read and apps:deploy; a token can be limited to chosen apps and lasts 30 days to a year, or never expires (with a clear warning, and revoking or deleting the owner ends it). Creating one has a page of its own. It is shown once, only a hash is stored, and it is checked against its owner's current permissions on every call.
• Failed attempts are counted before the token is looked up, a token gets 60 calls a minute, and there is no CORS. See docs/api.md, which has a GitHub Actions example.

Deployment messages

• Settings > Notifications sends the result of a deployment to Slack (and Mattermost, Rocket.Chat), Discord or any webhook as JSON: only failures, or every result. Messages hold the app, commit and reason, never logs or secrets. The address is stored encrypted and must be https; this server, reserved ranges and the cloud metadata address are refused. New permission notifications.manage. See docs/notifications.md.

GitHub

• Settings > GitHub creates a GitHub App for the panel through GitHub's manifest flow: no tokens or deploy keys to paste. New apps can pick a repository from a list; each clone uses a read-only token for that one repository that expires after an hour.
• Deploy on push is a switch when you create the app from a GitHub repository, and later on its Settings tab, where it asks you to confirm turning it on or off. It is off unless you turn it on; every other app has it off too.
• New permission github.manage. Anyone who may create apps can deploy any repository the GitHub app may read, so give it access only to what should be deployable. See docs/github.md.

Before you upgrade

• Open port 2053 in your firewall (next to 80, 443 and 8443) if you want to use the database tools. The installer prints the reminder.
• The upgrade adds a few columns to apps and deployments, rewrites the agent's service file (a second socket for the tools) and the panel's nginx site. Back up /var/lib/commypanel as usual and upgrade with sudo commypanel upgrade.
• New permissions: databases.tools, tokens.manage, notifications.manage and github.manage. The built-in admin role gets them; give them to other roles on purpose.
• The panel contacts the outside in more cases, all started by you: api.github.com and github.com when you use the GitHub page, create an app from it or deploy one, and your chat's webhook address once you switch messages on. Update checks, your S3 copy and the address lookup are as before.

Security notes

• The database tools' proxy is the security boundary: single-use ticket (60 s), a cookie limited to its own session path, only the tool's own cookies forwarded, redirects kept inside the session, no WebSocket upgrades, a body limit. The agent chooses the tool image and network; a request cannot.
• API tokens, deployment messages and the GitHub App keep their secrets encrypted and never show them again. The GitHub return works once, bound to your session, within ten minutes; its webhook accepts only this app's signed pushes.

Known limitations

• Cookies ignore ports, so a script running inside a database tool could still fill the cookie jar of the host and read cookies that are not HttpOnly. A separate host name for the tools (planned with wildcard certificates) is the real fix.
• Deployment messages are one webhook for the whole panel, and not email. GitHub Enterprise Server is not supported, and GitLab, Gitea and Bitbucket stay on deploy keys.
• Not in this release: wildcard certificates.

Requirements

Unchanged: Ubuntu 24.04 or 26.04, or Debian 13 or newer, with systemd; amd64 or arm64; root access; at least 1 GB of RAM.

# Install
curl -fsSL https://github.com/emrecanful/commypanel/releases/latest/download/install.sh | sudo bash

# Upgrade
sudo commypanel upgrade

CommyPanel 0.6.0-rc.2 (release candidate)

Release candidate for testing. Not for production. This build has not yet been run end to end on a real server. If you try it, please use a test server and tell us what breaks.

Install this candidate (the normal one-line installer only installs the latest stable release):

curl -fsSL https://github.com/emrecanful/commypanel/releases/download/v0.6.0-rc.2/install.sh | sudo bash -s -- --version 0.6.0-rc.2

Upgrade an existing install to it:

sudo commypanel upgrade --version 0.6.0-rc.2

Most useful to check: the upgrade itself, nginx reloads and the new nginx editor, a first Let's Encrypt certificate, a deploy with a release command, deploy on push from your Git host, and the live usage figures against docker stats.

---

CommyPanel 0.6.0

This release adds four things: opening a database in phpMyAdmin or Adminer, API tokens for scripts and CI, deployment messages to a chat, and a one-click GitHub connection. Please read Before you upgrade: the database tools need a new port open in your firewall.

CommyPanel is still pre-1.0.

What's new

Database tools

• A phpMyAdmin / Adminer button next to each database (phpMyAdmin for MySQL and MariaDB, Adminer for PostgreSQL). It starts a short-lived container, shows progress while it pulls and starts, and opens the tool in a new tab by itself.
• You are logged in as that database's own user, never as the administrator, and the password never reaches your browser or the tool's container.
• A session ends after 15 minutes without use (4 hours at most) and the container is removed; at most 6 run at once. The page tells you this before you open one.
• The tools are served on port 2053 (COMMYPANEL_TOOLS_PORT), a port of their own, because a browser treats another port as another origin: a flaw inside a tool cannot read the panel's pages. 2053 is one Cloudflare also proxies, for panels behind Cloudflare.
• New permission databases.tools, password confirmation, and an audit entry for every opening. Treat it like the database's password.

API tokens

• Settings > API tokens (permission tokens.manage) creates tokens for scripts and CI: list apps, start a deployment and follow it. Abilities are apps:read and apps:deploy; a token can be limited to chosen apps and lasts 1 to 365 days. It is shown once, only a hash is stored, and it is checked against its owner's current permissions on every call.
• Failed attempts are counted before the token is looked up, a token gets 60 calls a minute, and there is no CORS. See docs/api.md, which has a GitHub Actions example.

Deployment messages

• Settings > Notifications sends the result of a deployment to Slack (and Mattermost, Rocket.Chat), Discord or any webhook as JSON: only failures, or every result. Messages hold the app, commit and reason, never logs or secrets. The address is stored encrypted and must be https; this server, reserved ranges and the cloud metadata address are refused. New permission notifications.manage. See docs/notifications.md.

GitHub

• Settings > GitHub creates a GitHub App for the panel through GitHub's manifest flow: no tokens or deploy keys to paste. New apps can pick a repository from a list; each clone uses a read-only token for that one repository that expires after an hour.
• Deploy on push is a switch on each such app's Settings tab. It is off by default and asks you to confirm turning it on or off.
• New permission github.manage. Anyone who may create apps can deploy any repository the GitHub app may read, so give it access only to what should be deployable. See docs/github.md.

Before you upgrade

• Open port 2053 in your firewall (next to 80, 443 and 8443) if you want to use the database tools. The installer prints the reminder.
• The upgrade adds a column to apps, rewrites the agent's service file (a second socket for the tools) and the panel's nginx site. Back up /var/lib/commypanel as usual and upgrade with sudo commypanel upgrade.
• New permissions: databases.tools, tokens.manage, notifications.manage and github.manage. The built-in admin role gets them; give them to other roles on purpose.
• The panel contacts the outside in more cases, all started by you: api.github.com and github.com when you use the GitHub page, create an app from it or deploy one, and your chat's webhook address once you switch messages on. Update checks, your S3 copy and the address lookup are as before.

Security notes

• The database tools' proxy is the security boundary: single-use ticket (60 s), a cookie limited to its own session path, only the tool's own cookies forwarded, redirects kept inside the session, no WebSocket upgrades, a body limit. The agent chooses the tool image and network; a request cannot.
• API tokens, deployment messages and the GitHub App keep their secrets encrypted and never show them again. The GitHub return works once, bound to your session, within ten minutes; its webhook accepts only this app's signed pushes.

Known limitations

• Cookies ignore ports, so a script running inside a database tool could still fill the cookie jar of the host and read cookies that are not HttpOnly. A separate host name for the tools (planned with wildcard certificates) is the real fix.
• Deployment messages are one webhook for the whole panel, and not email. GitHub Enterprise Server is not supported, and GitLab, Gitea and Bitbucket stay on deploy keys.
• Not in this release: wildcard certificates.

Requirements

Unchanged: Ubuntu 24.04 or 26.04, or Debian 13 or newer, with systemd; amd64 or arm64; root access; at least 1 GB of RAM.

# Install
curl -fsSL https://github.com/emrecanful/commypanel/releases/latest/download/install.sh | sudo bash

# Upgrade
sudo commypanel upgrade

CommyPanel 0.6.0-rc.1 (release candidate)

Release candidate for testing. Not for production. This build has not yet been run end to end on a real server. If you try it, please use a test server and tell us what breaks.

Install this candidate (the normal one-line installer only installs the latest stable release):

curl -fsSL https://github.com/emrecanful/commypanel/releases/download/v0.6.0-rc.1/install.sh | sudo bash -s -- --version 0.6.0-rc.1

Upgrade an existing install to it:

sudo commypanel upgrade --version 0.6.0-rc.1

Most useful to check: the upgrade itself, nginx reloads and the new nginx editor, a first Let's Encrypt certificate, a deploy with a release command, deploy on push from your Git host, and the live usage figures against docker stats.

---

CommyPanel 0.6.0

This release adds four things: opening a database in phpMyAdmin or Adminer, API tokens for scripts and CI, deployment messages to a chat, and a one-click GitHub connection. Please read Before you upgrade: the database tools need a new port open in your firewall.

CommyPanel is still pre-1.0.

What's new

Database tools

• A phpMyAdmin / Adminer button next to each database (phpMyAdmin for MySQL and MariaDB, Adminer for PostgreSQL). It starts a short-lived container, shows progress while it pulls and starts, and opens the tool in a new tab by itself.
• You are logged in as that database's own user, never as the administrator, and the password never reaches your browser or the tool's container.
• A session ends after 15 minutes without use (4 hours at most) and the container is removed; at most 6 run at once. The page tells you this before you open one.
• The tools are served on port 2053 (COMMYPANEL_TOOLS_PORT), a port of their own, because a browser treats another port as another origin: a flaw inside a tool cannot read the panel's pages. 2053 is one Cloudflare also proxies, for panels behind Cloudflare.
• New permission databases.tools, password confirmation, and an audit entry for every opening. Treat it like the database's password.

API tokens

• Settings > API tokens creates tokens for scripts and CI: list apps, start a deployment and follow it. Abilities are apps:read and apps:deploy; a token can be limited to chosen apps and lasts 1 to 365 days. It is shown once, only a hash is stored, and it is checked against its owner's current permissions on every call.
• Failed attempts are counted before the token is looked up, a token gets 60 calls a minute, and there is no CORS. See docs/api.md, which has a GitHub Actions example.

Deployment messages

• Settings > Notifications sends the result of a deployment to Slack (and Mattermost, Rocket.Chat), Discord or any webhook as JSON: only failures, or every result. Messages hold the app, commit and reason, never logs or secrets. The address is stored encrypted and must be https; this server, reserved ranges and the cloud metadata address are refused. New permission notifications.manage. See docs/notifications.md.

GitHub

• Settings > GitHub creates a GitHub App for the panel through GitHub's manifest flow: no tokens or deploy keys to paste. New apps can pick a repository from a list; each clone uses a read-only token for that one repository that expires after an hour.
• Deploy on push is a switch on each such app's Settings tab. It is off by default and asks you to confirm turning it on or off.
• New permission github.manage. Anyone who may create apps can deploy any repository the GitHub app may read, so give it access only to what should be deployable. See docs/github.md.

Before you upgrade

• Open port 2053 in your firewall (next to 80, 443 and 8443) if you want to use the database tools. The installer prints the reminder.
• The upgrade adds a column to apps, rewrites the agent's service file (a second socket for the tools) and the panel's nginx site. Back up /var/lib/commypanel as usual and upgrade with sudo commypanel upgrade.
• New permissions: databases.tools, notifications.manage and github.manage. The built-in admin role gets them; give them to other roles on purpose.
• The panel contacts the outside in more cases, all started by you: api.github.com and github.com when you use the GitHub page, create an app from it or deploy one, and your chat's webhook address once you switch messages on. Update checks, your S3 copy and the address lookup are as before.

Security notes

• The database tools' proxy is the security boundary: single-use ticket (60 s), a cookie limited to its own session path, only the tool's own cookies forwarded, redirects kept inside the session, no WebSocket upgrades, a body limit. The agent chooses the tool image and network; a request cannot.
• API tokens, deployment messages and the GitHub App keep their secrets encrypted and never show them again. The GitHub return works once, bound to your session, within ten minutes; its webhook accepts only this app's signed pushes.

Known limitations

• Cookies ignore ports, so a script running inside a database tool could still fill the cookie jar of the host and read cookies that are not HttpOnly. A separate host name for the tools (planned with wildcard certificates) is the real fix.
• Deployment messages are one webhook for the whole panel, and not email. GitHub Enterprise Server is not supported, and GitLab, Gitea and Bitbucket stay on deploy keys.
• Not in this release: wildcard certificates.

Requirements

Unchanged: Ubuntu 24.04 or 26.04, or Debian 13 or newer, with systemd; amd64 or arm64; root access; at least 1 GB of RAM.

# Install
curl -fsSL https://github.com/emrecanful/commypanel/releases/latest/download/install.sh | sudo bash

# Upgrade
sudo commypanel upgrade

CommyPanel 0.5.1

CommyPanel 0.5.1

This release is about backups you can rely on, a server that finds its own address, and pages that follow along while you wait. It also contains the fixes from a security review of the agent, so please read Before you upgrade. It covers everything since 0.4.2; there was no stable 0.5.0.

CommyPanel is still pre-1.0.

What's new

Backups

• Restore a database dump from the panel. Press Restore next to a dump on a database server's page, choose a name, and it is loaded into a new database, so nothing that exists is overwritten. It shows "Restoring" until done (or "Restore failed" with the reason). Link the new database to the app, deploy again, and delete the old one when you are sure.
• Copy backups to another place (S3). Under Settings > Backups, every new panel backup, database dump and volume archive can be copied to any S3-compatible storage: Hetzner Object Storage, Cloudflare R2, Backblaze B2, Wasabi, MinIO, Amazon S3. Test the connection checks the settings. The newest 14 copies of each backup are kept there (changeable); files that are not CommyPanel backups are never touched. The secret key is stored encrypted and never shown again.
• Back up app volumes. A Back up button per volume on the app's Volumes tab makes a compressed archive in the background (the newest 3 of each are kept). Nothing is backed up by itself, because volumes can be large. Downloads and deletes need your password and are audited.

The server's address

• Found automatically. CommyPanel finds the server's public IP address by itself, in the background, the first time a page needs it; there is no button to press. It reads the server's own network connection first, so on most servers (Hetzner, DigitalOcean, bare metal) nothing leaves the machine. Only a server with no public address on its interface (behind a NAT, as on some clouds) is looked up through api.ipify.org, once; COMMYPANEL_ADDRESS_LOOKUP=false switches that off.
• A "Wrong IPs detected?" button is next to the address everywhere it is shown (Domains, an app's Domains tab, the first-run page, a domain's page). It opens the two fields (IPv4 and optional IPv6) with a Detect again button. What you enter is never replaced by a detection, and every change is audited with what it replaced. If nothing can be found, you are asked.

Pages that wait follow along

• While a domain's DNS does not point at the server yet, or a certificate is being issued, the first-run page, an app's Domains tab, the app wizard's domain step and a domain's page refresh every 5 seconds, re-check DNS every 15 seconds (if you may manage domains), and stop the moment everything is in place. Before, they changed only after you pressed "Check DNS again". They pause while the tab is hidden and give up after half an hour (the server still re-checks every five minutes). A failed certificate is never retried by the automatic check, only by the button.
• The installation is one centered page, start to finish. Creating the admin account and the welcome steps (Let's Encrypt, panel domain) share a layout with no sidebar or menu, the three steps across the top, and a card for each.

Server health and apps

• A warning when the disk is nearly full, on every page, from 85% used (an error from 95%; DISK_WARN_PERCENT and DISK_CRITICAL_PERCENT). The Server page has a new Disk card with a usage bar and the five biggest app volumes.
• The name other apps call an app by moves with the traffic. Before, the old and the new release both answered to a provider app's link name during a deployment. The new release takes the name only once it is healthy and has traffic, and the old one gives it up right after.

Installing

• CI installs each release on Debian 13, Ubuntu 24.04 and Ubuntu 26.04 before it is published, and the tests also run on PHP 8.3.

Before you upgrade

• Back up /var/lib/commypanel as with any upgrade, and upgrade with sudo commypanel upgrade. The migration adds three columns to managed_databases.
• The agent has a new private folder, /var/lib/commypanel-agent, outside the data directory, created by systemd. It holds the agent's scratch files, the record of the dumps it made, the TLS private keys, the ACME account key and the ACME challenge files, which used to sit under /var/lib/commypanel. Only root can change anything in it. The upgrade rewrites the agent's service file for it. Certificates are not moved: apps get theirs again from Let's Encrypt, so a server that already has certificates should expect them to be requested again after upgrading.
• No new permissions. Restoring a dump needs databases.manage, volume backups need apps.volumes, and the S3 copy needs backups.manage.
• The panel contacts the outside in two more cases, both only when you or the server's situation call for it: your S3 storage once you switch the copy on, and api.ipify.org only on a server with no public address of its own (and not at all with COMMYPANEL_ADDRESS_LOOKUP=false). Update checks remain the only call it makes without either.
• An address you saved before stays as it was, marked as entered by you; use Detect again if you want it looked up anew.

Security notes

• The agent's own files are out of the panel's reach. A compromised panel could swap a temporary dump file for a link to a root-only file (the agent would then send its contents back), forge a record of a dump, or replace the certificate folder so that new private keys were written where it can read them. The scratch files, the dump records, the TLS keys, the ACME account key and the ACME challenge files now live in a folder only root can change.
• Only dumps the agent made itself can be restored, checked by checksum, always into a new database; a restore runs as the database's own user for PostgreSQL.
• Extra networks are link networks only, and a link network is never a container's own: a container can no longer join another app's or a database server's network, or put a name on it that answers in their place.
• MySQL and MariaDB grants no longer treat _ in a database name as a wildcard, so a user cannot reach a database that only matches the pattern.
• A command that is still running when its output ends is a failure, not an exit code of 0, so a dump cut off by the time limit is no longer kept as a good backup.
• Database tools run only in database servers: managed containers named db-* started from an official database image. An app and a database server can only mount their own kind of folder, and a mount source cannot carry bind options.
• Big jobs are limited: at most two dumps, restores or volume archives run at once, and none starts with less than 2 GB of free disk. The data of a database server is never deleted when Docker cannot be asked whether something still uses it.
• The build context is read through a root that cannot be left, and each file is checked again when it is opened.
• The S3 address must be https and not this server or a link-local address, redirects are never followed, and the secret key is encrypted.

Known limitations

• Backups are not read back from the S3 storage by the panel: download the file there and load it by hand (the docs show the command). The same goes for restoring onto a new server, since the Restore button only loads dumps that server's agent made itself. Single uploads are limited to 5 GB.
• A volume archive is put back by hand (stop the app, tar -xzpf as root), and a database dump is restored into a new database only; there is no "replace" mode yet.
• A server with several public IPv4 addresses and no clear default route gets the first one; correct it with Wrong IPs detected? if it is not the one your domains should use. A server behind a NAT with the outside lookup switched off has to be given its address by hand.
• The S3 client was tested against AWS's published test vectors and a real S3-compatible server, not yet against every provider; please report what you find, with the provider's name.
• Not in this release: API tokens, one-click GitHub connection, wildcard certificates.

Requirements

Unchanged: Ubuntu 24.04 or 26.04, or Debian 13 or newer, with systemd; amd64 or arm64; root access; at least 1 GB of RAM.

# Install
curl -fsSL https://github.com/emrecanful/commypanel/releases/latest/download/install.sh | sudo bash

# Upgrade
sudo commypanel upgrade