Every field in the create-application flow, what each choice changes, and what happens after you press create.
Getting here: Servers → a server → Applications → Create Application
An application is a site or service running on a server you already have. One server can host several, each with its own code, database, domain and certificate.
1. Application name
Enter application name — required.
Used throughout the panel and in paths on the server. An application saved without one appears as Unnamed App, which helps nobody in a list of six.
2. How the application starts
The most consequential choice on the page — it decides which fields appear next and how your code reaches the server.
| Option | Use it when |
|---|---|
| Fresh | Start from a clean installation of the chosen technology |
| Deploy from Git Repo | Clone and deploy an existing repository |
| Docker Image | Run a prebuilt container image |
| Custom Migration | Bring an existing site across from elsewhere |
| Blank Server | Provision nothing; configure it yourself |
3. Technology
Select Tech — what gets installed and configured.
PHP
| Stack | Notes |
|---|---|
| Laravel | Versions 9, 10, 11, 12, and 13 (Latest) |
| WordPress | |
| Magento | |
| Open Journal Systems (OJS) | 2.4.8, 3.1.2, 3.2.1, 3.3.0 (Latest) |
PHP version is selectable per application: 7.3, 7.4, 8.0, 8.1, 8.2, 8.3 — each as its own FPM pool. Two applications on the same server can run different PHP versions.
JavaScript
Node.js/Express, Next.js, MERN, Angular, Svelte, Strapi, plain HTML/CSS/JS.
Node version: 16, 18, 20 (Latest).
Python
Django, Flask.
Python version: 3.11, 3.12, 3.13 (Latest).
Other
Ruby on Rails, .NET, cal.diy.
4. Web server
Apache or nginx, where the technology allows a choice.
Both work for most stacks. Apache is required for OJS. If your project ships .htaccess rules you rely on, Apache saves translating them.
5. Database
Select the engine installed and bound to the application:
| Engine | For |
|---|---|
| MySQL | The default for most PHP applications |
| PostgreSQL | |
| MongoDB | Document storage, typical for MERN |
| SQLite | File-based; fine for small or single-user applications |
| None | No database — static sites, or an application using an external one |
The panel creates the database, a user and a password, and wires them into the application's configuration. Credentials appear on the application's page after creation — you do not need to set them by hand.
6. Fields — Deploy from Git Repo
Repository
Clone HTTPS URL — https://github.com/username/repo.git
Branch — which branch is deployed. Defaults offered include main and Master; check this rather than assuming. Deploying master when your work is on main produces an application that builds cleanly and shows the wrong code.
Public or Private
Public needs no credentials.
Private needs one of:
| Method | How it works |
|---|---|
| Access token | Paste a personal access token (ghp_xxxxxxxx…) |
| Deploy key | The panel generates an SSH key; you add it to the repository |
Prefer the deploy key. It is scoped to that one repository, whereas an access token carries whatever permissions your account has. If the generation fails the panel says Failed to generate deploy key rather than silently continuing without one.
The deploy key must be added at your Git provider before you create the application. A missing key is the most common reason the clone step fails.
7. Fields — Docker Image
Image name — myuser/myimage
Tag — defaults to latest.
Container port — e.g. 80, 3000, 8080. Must match the port the image actually listens on; a mismatch produces a container that starts and is unreachable.
Registry credentials — username and password, for private registries only.
8. Before you create
The panel checks for unpaid invoices before allowing creation. An outstanding balance blocks new applications — clear it on the Billing page first.
Creation also requires a valid session; User ID not found. Please log in again means exactly that.
9. The summary
A review panel showing the application name, technology and version, web server, database engine, and source. Read the version line — the difference between Laravel 12 and 13, or PHP 8.1 and 8.3, is not something to discover after deployment.
Create Application starts the work. The button shows Creating… while it runs.
10. What happens next
- 1The runtime is installed if not already present — the PHP FPM pool, Node version, or Python version you chose.
- 2The web server is configured with a virtual host for the application.
- 3The database is created, with its user and password, and written into the application's configuration.
- 4Your code arrives — a fresh installation, a Git clone, or a container pulled.
- 5Dependencies are installed and any build step runs.
Failures report the reason rather than leaving a half-made application: Failed to create application, with detail.
11. After it is created
The application's own page carries:
- Domains and SSL — point a domain and issue a certificate
- Deployment — redeploy, change branch, deployment script
- Database — credentials and a web database manager
- Backup and Restore — scheduled backups, with full / code-only / database-only scope
- Cronjob — scheduled tasks scoped to this application
- Staging — a copy to test against before touching production
Recommended order: point the domain, issue SSL, set up backups, then verify a restore works.
12. Common problems
| Problem | Cause |
|---|---|
| Cannot create — blocked | An unpaid invoice; clear it on Billing |
| Git clone fails | Deploy key not added at the provider, expired token, or a private repository marked public |
| Wrong code deployed | Wrong Branch — main versus master |
| OJS will not work | It requires Apache2; nginx was selected |
| Container starts but is unreachable | Container port does not match the image |
| Application cannot reach its database | Check credentials on the application page; they are generated, not chosen |
| Build fails | Runtime version mismatch — check the PHP, Node or Python version against what the project needs |
| Unnamed App in the list | Created without a name |
13. Choosing well
- Match the runtime version to the project, not to "latest". A project pinned to PHP 8.1 will not run on 8.3 without work.
- One application per site. Sharing one across two sites makes backups, domains and deployment ambiguous.
- Pick the database you will actually use. Adding one later means creating it and wiring it by hand; the automatic binding only happens at creation.
- Use a deploy key over a token for private repositories.
- Check the branch. It is the field people skip and the one that produces the most confusing outcome.
Something here not matching what you see in the panel?
Tell us