Security

Security model

A control panel holds the keys to your server. This page summarises how Pushpendra Panel limits what any single component — or any single mistake — can do.

Unprivileged API

The web API runs as an unprivileged user. It cannot run arbitrary shell commands — there is no such endpoint.

Typed privileged agent

Root-level work is done by a small Go agent that only accepts a fixed allowlist of schema-validated operations over a local socket.

Modern authentication

Argon2id password hashing, opaque session tokens stored only as hashes, brute-force lockouts and per-device session revocation.

Deny by default

Workspaces cannot see each other’s resources; databases and Redis are not exposed publicly unless you choose to.

Signed updates

Release archives are published with SHA-256 checksums and ed25519 signatures and delivered over TLS.

Audit everything

Privileged and sensitive actions are recorded with actor, IP, result and redacted metadata.

Architecture

Browser ──HTTPS──▶ Web UI (Next.js)
                     │  same-origin /api
                     ▼
                   API (Node.js, unprivileged user, 127.0.0.1)
                     │  SQLite / PostgreSQL
                     │  Unix socket + bearer token + peer UID check
                     ▼
                   Agent (Go, privileged, typed operation allowlist)
                     ▼
        Nginx · PHP-FPM · systemd · DNS · mail · databases

The API never has a “run an arbitrary command” path. Every privileged action is a named, schema-validated agent operation such as creating a site, issuing a certificate or restarting an application you own. Generated configuration is validated (for example with nginx -t) before it is applied, and the last known-good configuration is kept.

Accounts and sessions

  • Passwords are hashed with Argon2id; the minimum length is 12 characters.
  • Sessions use a random 256-bit token in an HttpOnly, SameSite cookie (Secure over HTTPS). Only a SHA-256 hash of the token is stored.
  • Failed logins are throttled per account and per IP with escalating lockouts.
  • State-changing requests are protected against CSRF with Origin checks and SameSite cookies.
  • Password changes, suspensions and role changes revoke existing sessions.

Isolation

  • Every resource belongs to a workspace. Users see only workspaces they are members of; UI filtering is never the only boundary.
  • Applications and deploy builds run as their own unprivileged Linux users — never as root.
  • Databases and Redis are bound to localhost by default.

Updates and releases

Releases are published on the download page as ptpanel-<version>-linux-<arch>.tar.gz archives with a .sha256 checksum and a .sig ed25519 signature. The panel’s updater verifies both before installing, and downloads only over HTTPS.

Audit log

Privileged and sensitive actions are written to an append-only audit log with actor, IP, user agent, session, result and redacted metadata. There is no API to edit or delete audit entries.

Reporting a vulnerability

Please report security issues privately to hello@ptpanel.in rather than in the public forum. Include the version, steps to reproduce and impact. We will acknowledge your report, keep you informed while we work on a fix, and credit you if you wish.