Skip to main content

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 Remote access to a database.

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