Create a managed runtime application
In the website Applications tab, inspect GET /v1/application-capabilities for the selected account. The interface supports the actually advertised Node.js/Python runtimes and versions. Enter application name, relative entry point, local health path and write-only environment secrets. Ruby is explicitly unavailable in the current menu catalogue.
The create request identifies application, account and website and uses configuration containing workload_kind, managed: true, runtime_version, health_path, start.program, start.args and a staged environment_handle. A local health URL is a process check, not proof of public DNS/TLS. Start arguments are typed application configuration, not a browser-accessible root shell.
Git source and credentials
Choose repository URL, branch/tag context and the immutable commit SHA to deploy. Review HTTPS authentication if needed: username and access token are staged write-only; they are not general Panel API tokens. Keep repository credentials narrow and do not enter them into a URL that may be logged.
Review the tenant-scoped build policy, supported requirements file and environment. Deployment goes to /v1/applications/{id}/git/deploy with the reviewed current application configuration/revision and durable idempotency key. The branch label is context; the immutable commit identifies the actual source. Build processes remain confined to the supported account boundary.
Releases, logs and rollback
Application detail exposes release inventory, logs and bounded log-content reads. Compare the deployed commit and observed health, then test the public application and database connectivity. /git/rollback targets the supported retained release through the reviewed operation. A code rollback does not reverse database migrations, remote calls, mail or other external side effects; back up and plan those independently.
Suspend and recover
Managed applications expose suspend, reactivate and terminate lifecycle routes. Review account state and current revision before submission. On ambiguous transport or failed build, inspect the original operation/release before starting another deployment. Preserve staged secret boundaries and avoid copying another tenant's material.
Shell and vendor limits
Customer application shell access is a separately reviewed /v1/accounts/{id}/application-access setting with current account ownership and capability. It is not the unimplemented general web terminal or root access. Do not infer a Softaculous/LiteSpeed licence, Ruby runtime, universal Git host compatibility or automatic database rollback from these source forms. Native service and recovery acceptance remain release-specific.