Documentation menu
License

License

The License screen and state behavior are ready in the code, but license verification is currently off and the panel restricts nothing.

Current status: license verification is off

In the panel version that is published now, license verification does not run and the panel restricts nothing. The license code is ready inside the panel and is locked by tests, but the Deckpa root public key that verification depends on has not been built into the program file yet. Until the key is built in, the panel does not check licenses, does not ask for a license key, and does not block creating a site, database, FTP account, or user because of a license.

The System → License screen (page title Panel License) states this plainly: a License verification is off heading, an Off badge, and the message "This build runs without license verification. Nothing in the panel is restricted." While verification is off, the license key form is not shown, and the Check now button answers "License verification is not enabled in this build." The screen is open to administrators only.

The rest of this page describes how the panel behaves once verification is turned on. That behavior is implemented in the code and verified by tests, but it is not active in the current version. For prices and subscription terms, see the pricing page.

The License screen

When verification is active, the screen shows two cards. The left card has the status heading and badge, Subscription ends, Grace period ends during the grace period, Last checked, and the Check now button. The right card, License details, has the License ID, a Campaign if there is one, and the Server fingerprint. Below the right card there is a License key field and an Activate button; the form is shown only while verification is active.

When needed, these notice strips appear above the status card; none of them locks the panel:

  • This license is under review. Your panel keeps working normally. Nothing changes in functionality during a review.
  • This license has been revoked. The panel does not cut off at that moment; the grace period starts from the revocation date (see the next section).
  • The server clock appears to have been set back. License checks use the latest time the panel has seen.
  • The last check failed. The last refresh attempt returned an error; the panel keeps working.

States and the 7-day grace period

The panel calculates the state from the last verified subscription end date stored locally; it does not ask the license server on every request.

  • Active: the subscription period is running.
  • Grace period: the period has ended, but for 7 days after the end date the panel is fully functional. On every page, a strip says Your subscription has expired. The panel remains fully functional until ..., with a Manage license button.
  • Restricted: the grace period has ended too. The panel does not lock; only creating new resources is disabled (next section). The strip says "Creating new sites, databases, and FTP accounts is disabled."
  • Not activated: no activation has ever been done for this panel. Creating new resources is disabled in this state too; the error message says "The panel license is not activated, so new resources cannot be created."

When a renewed subscription is seen, the restriction lifts on its own; Check now triggers that without waiting.

What is disabled when restricted

The license gate is checked in only six operations that create new resources: a new site, a new subdomain, a new database, a new database user, a new FTP account, and a new panel user. When restricted, these operations are refused with the message "The panel subscription has expired, so new resources cannot be created. Your existing sites keep running."

Existing sites and services keep running; listing, editing, deleting, backing up, and restoring are not restricted because of the license. This is a design decision: the customers of an administrator whose subscription ended should not see their sites go down. Each create operation calls the gate separately, and a test verifies that every create operation with a quota check calls it.

If the license server cannot be reached

  • Daily check. The panel refreshes the license state once a day (timing is spread out). After a failed attempt, it retries an hour later. Check now refreshes immediately; it exists so that someone who has just paid does not wait 24 hours.
  • An error does not lock the panel. Server errors from the license server are swallowed quietly. If the server cannot be reached, the screen says "Could not reach the license server. Your panel keeps working; the check will be retried later." Even if the server is unreachable for 7 days, the panel keeps working according to the last known subscription end date.
  • A response that cannot be verified. If the signature of a response from the license server cannot be verified, the response is ignored and the current state is kept.
  • A license bound to another server. If the same key is bound to many servers in a short time, the license is put under review; the panel keeps working.
  • Setting the clock back. The panel stores the latest time it has seen. If the clock is set back, decisions use that time, so turning the clock back does not extend an expired subscription, while a legitimate clock correction does not lock anyone out.

What is sent to the license server

The panel talks to license.deckpa.dev (the license_base setting). The request body carries only these fields:

  • On activation: the license key, the server fingerprint, and the cloud provider's instance ID (if the server has such a local record).
  • On refresh: the license ID, the server fingerprint, and a check value that came with the previous response and prevents the response from being replayed.

The server fingerprint is a digest built from the machine ID (/etc/machine-id), the lowest MAC address among the physical network interfaces, and the cloud instance ID if there is one. The IP address is not part of the fingerprint; container and virtual interfaces are not counted either. No site content, database, or file information appears in any of the requests.

The license key is kept only in /etc/deckpa/license.json, which only root can read; the process that serves the panel interface never sees the key. Responses are accepted only after their signatures are verified with a key built into the program file (PASETO v4.public, Ed25519); the verification chain goes from the root key to an intermediate key and from there to the license token.