SYSTEMS. is privileged infrastructure. It controls Docker, the reverse proxy, uploaded source, env vars, routes, and logs. It's built to be hardened, private, least-privilege, and admin-only. It is not claimed to be unhackable.

The dashboard and API must be unreachable unless you're authenticated as an admin.

The "not yet" column is the genuinely unbuilt work, not a release timeline.

• The Docker socket and Docker API are never exposed publicly; the frontend never talks to Docker directly. Only the API/deploy worker controls Docker, internally.
• The reverse proxy admin/API is never public.
• Production dashboard/API traffic must use TLS. The session cookie is Secure, HttpOnly, SameSite=Strict, path-scoped to /, and uses the __Host- prefix in production.
• TRUST_PROXY stays false unless the API is reachable only through the trusted Caddy/nginx hop; otherwise forwarded client IP headers are attacker-controlled.
• The internal database is never public.
• Uploaded code is untrusted. Extraction is zip-slip-guarded with entry-count and per-file size limits.
• Path traversal is prevented on extraction (resolved paths must stay under the destination).
• The reserved route-attestation path is owned by Caddy/nginx, before uploaded application handlers. Generated proxy config carries a per-slug HMAC credential to the private API upstream; it is never injected into the app.
• Attestation payloads use AES-256-GCM authenticated encryption, a random challenge nonce, a five-second expiry, strict size limits, no redirects, and Cache-Control: no-store. Modification, cross-system substitution, and replay fail closed. TLS is still required on public routes.
• Attestations expose only a hashed deployment fingerprint and minimal observed status. They never contain secrets, environment values, ports, container IDs, logs, or arbitrary app data. A malicious app remains untrusted; application health and Docker metrics are measured independently.

• Env var masking in the UI with explicit reveal + audit on reveal.

Schema, Docker, proxy, and server-level changes are dangerous, so they go in as dedicated, reviewable steps rather than alongside unrelated work.

Open publicly (inbound):

• 80/tcp, 443/tcp
• remote admin (RDP/SSH) only if needed, restricted to your IP

Never public:

• Postgres 5432
• Docker API / socket (2375/2376)
• Caddy admin API (2019)
• internal backend/API ports, deployment worker ports
• project internal container ports
• Redis/queues (if added later)

Verify with PowerShell / the helper script:

Get-NetFirewallRule -Direction Inbound -Enabled True | Get-NetFirewallPortFilter | Sort-Object LocalPort
Get-NetTCPConnection -State Listen | Sort-Object LocalPort
.\scripts\check-firewall-windows.ps1 -PublicIp <SERVER_IP>

Checklist:

• Postgres 5432 not externally reachable
• Docker API not listening publicly (no 0.0.0.0:2375)
• Caddy admin 2019 not public
• only 80/443 open
• systems.acronym.sk behind admin auth
• private/internal systems have no public Caddy route
• wildcard DNS does not imply every subdomain serves something

• Every deployed container gets memory/CPU/PIDs limits, a restart policy, and log rotation from DEFAULT_CONTAINER_* (see OPERATIONS). One project can't exhaust the host.
• Destructive actions are split: delete stops the container and pulls the public route but keeps history, while purge removes everything and requires typing the system slug to confirm.
• Before a destructive action, the UI shows whether a recent backup exists and warns when none does.

These features are built and off by default. Each one enables only through its explicit .env flag.

Default posture: every high-risk feature ships disabled and stays that way until it's been validated on the real host. None are claimed working live.

See also: HARDENING.md (verification), BACKUPS.md, DISASTER_RECOVERY.md.