What the client does, who it trusts, and what stays the project's responsibility.
The instance token is a 64-character hexadecimal value from 32 random bytes. It's the only secret between instance and server.
manage-client/config.php.If compromise is suspected, in the Manage server go to Instances → "Rotate token". The old token becomes invalid immediately.
manage-client/config.php
data/manage/
A compromised token allows: downloading releases and uploading backups — so, access to the application code and the ability to use up storage. It does not allow downloading backups or changing releases; both require logging into the Manage server.
Every request runs over HTTPS. The client uses PHP's default certificate verification; it is not disabled. A server with a self-signed certificate therefore doesn't work without a matching CA bundle on the system — that's intentional.
Redirects are not followed (follow_location => 0). A redirected request
fails instead of sending credentials to a different destination.
An update deploys someone else's code on the server. That's secured by:
MANAGE_UPDATE_SANITY_PATHS.The limit of this model: the checksum comes from the same server as the package. Whoever takes over the Manage server can publish a package and the matching checksum. A signature backed by a public key held in the client deliberately doesn't exist — the Manage server has to be secured accordingly.
A backup gets transferred to the Manage server, stored there, and can be downloaded by anyone who logs into the Manage server. It follows that:
config.php with database passwords or
API keys doesn't belong in MANAGE_BACKUP_SOURCES.These directories must not be reachable over the web:
| Path | Content |
|---|---|
data/manage/backups/ |
complete operational data |
data/manage/updates/ |
copies of the application files an update overwrote |
data/manage/work/ |
extracted packages during an update |
manage-client/config.php |
instance token |
The bundled manage-client/.htaccess locks config.php, lib/ and
bin/. For data/, the project's own .htaccess is responsible. On
nginx, the matching location rules have to be set by hand — .htaccess
has no effect there.
This can be checked directly:
curl -s -o /dev/null -w "%{http_code}\n" https://myproject.example.org/manage-client/config.php
curl -s -o /dev/null -w "%{http_code}\n" https://myproject.example.org/data/manage/backups/
Both must return 403 or 404, never 200.
ui/panel.php allows deploying updates and downloading backups — it's the
application's most powerful page. Because of that:
$_SESSION["admin_logged_in"].MANAGE_PANEL_SKIP_AUTH_GUARD disables only this extra check. Setting it
without checking the login yourself publishes update and backup functions
on the network.Where possible, the page should be accessible only to administrators, not to every logged-in user.
bin/manage-client.php refuses to run over HTTP (a PHP_SAPI check) and
is additionally locked via .htaccess. On the server, the file should
still avoid living in the public directory tree where that can be helped.
The client log contains filenames, versions, HTTP status and error
messages. Credentials are filtered out: from target configurations, the
client only picks up an allowlist of non-sensitive keys; access_key,
secret_key, password and the instance token never appear in the log.
Response excerpts from failed uploads are truncated to 500 characters.
manage-client/config.php is in .gitignoreconfig.php and manage-client/config.php are excluded from the release packagedata/manage/ is not reachable over the web (checked with curl)manage-client/config.php is not reachable over the web (checked with curl)MANAGE_SERVER_URL uses https://