Feature status & limits

1.0.0 functionality

• Web/API on six runtimes with optional project domains; long-running Workers on Node.js, Bun, Go and Python script.
• Organization permissions, scoped credentials, independent Portal/project Node majors, inline deployment progress, optional pnpm and local Prisma preparation.
• Worker process checks, release rollback, maintenance exclusion and installation recovery for participating paths.
• Separate account, updates and Monitor Settings pages; project-scoped Monitor diagnostics exclude runtime logs and failureLog.
• Domains/TLS for Web, database connectors, signed Portal updates and MIT licensing.

Boundaries to plan around

• One shared Ubuntu host; no hostile-tenant or multi-host isolation.
• Local Docker does not activate host systemd/Nginx/TLS.
• No general browser shell, public management API v1, DNS-provider automation or arbitrary Nginx editor.
• No standalone project stop/restart UI; deploy and rollback are separate supported workflows.
• Mail is not a live IMAP inbox client. Database connectors do not install database servers.
• Native PHP uses development-server launchers, not managed PHP-FPM.

Worker and operational boundaries

• Workers support no PHP, Compose, ASGI/WSGI, scheduled cron or one-shot mode.
• Service type is locked after any release, including failed releases; Worker runtime is locked too.
• Worker cutover has a short stop/start gap. Stable PID checks do not certify queue/job success or exactly-once processing; rollback cannot undo external effects.
• Maintenance is cooperative exclusion, not automatic draining of legacy versions or protection from unrelated root commands.
• Operational Mail acceptance and remote dpctl are deferred. Local/Docker evidence does not certify clean-host provisioning, real systemd/Nginx/TLS, reboot or whole-host restore.