Create and operate every application type.
Applications are managed workloads owned by a server and system user. ServerChirp gives each workload an appropriate creation flow while keeping common operations—deployments, files, logs, domains, metrics, and lifecycle controls—consistent.
| Workload | Built-in choices |
|---|---|
| PHP | Laravel, WordPress, Bedrock, Symfony, and custom PHP |
| JavaScript | Next.js server, Next.js static export, Nuxt, Astro, custom Node.js, and Bun |
| Static | Prebuilt static site |
| Containers | Public or private OCI image, or a Dockerfile build |
| Games | Catalog or custom Pterodactyl-compatible template |
| Processes | Custom console process, Laracord bot, and Discord.js bot |
| Networking | Multi-route reverse proxy |
Select New application on a server, choose a type, and then review its framework-aware defaults. Git-backed workloads select a repository and branch. Guided installers can create a fresh project and, where supported, a database and user.
Creation can reuse an existing system user or create a new passwordless user. Applications default to shared ownership; API clients can request isolated ownership where the workload supports it.
Compatible web applications can receive a temporary ServerChirp preview hostname. Add a custom domain during creation or later, choose apex and www behavior, and issue a Let's Encrypt or custom certificate when DNS is ready.
Installation is an operation with individual steps and output. A failed application remains inspectable and can be retried. Do not manually delete its files between retries unless the error specifically asks you to; the operation owns cleanup and reconciliation.
Game servers in a reinstallable state can rerun their template installer, with an explicit choice about whether to wipe their data first. Other application types do not expose this reinstall action.
Deleting an application runs a tracked removal operation. Read the confirmation carefully: deletion is separate from release rollback or backup recovery.
