Install WordPress on your own server
This page installs WordPress into a website or a folder of one, explains every field on the install form and what it refuses, gets you into the dashboard without hunting for a password, and sets up the protections that assume the site will one day be broken into.
Before you start
What the website needs.
- A PHP website that has finished being set up. A static site has nothing to run WordPress with, and one still provisioning has no account to install as yet.
- The database module enabled on the server. WordPress needs a database, and the install creates one for it rather than asking you to.
- A database left in the allowance. Twenty per website is the ceiling, and the hosting package usually sets a lower one.
You do not need to enable any PHP extensions first. If the application needs one that is off, the install turns it on as part of the job rather than refusing and telling you to go and do it.
Step 1
Install it.
Open the website, then Install an application, and choose WordPress. Fill in the four fields below and install. What comes back is a working site with its own database and an administrator account, not an archive to unpack.
A worked example, installing a blog into a folder rather than at the root:
Application WordPress
Title Jo's Notebook
Admin user jo
Admin email jo@example.com
Folder blog
Result: https://example.com/blog with its own database,
an administrator named jo, and a password shown once
Leave the folder empty to install at the root of the website, which is what most people want.
The form
What each field means, and what it refuses.
| Field | What it is for | Limits and refusals |
|---|---|---|
| Title | The site title WordPress will use, shown in the browser tab and usually in the theme. You can change it later in WordPress. | 1 to 120 characters. Line breaks are refused. |
| Administrator username | The account you will sign in to WordPress as. It is not the website’s system account and not the database account. | 3 to 60 characters. Letters, digits, dash, underscore, dot and at only. Anything else is refused. |
| Administrator email | Where WordPress sends password resets and its own notices. Use an address you can actually read. | Must be a real address. A malformed one is refused rather than stored. |
| Folder | Where under the website it lives. Empty installs at the root; blog gives /blog. |
A plain path, at most 4 levels deep, 200 characters in all, each part at most 64 and starting with a letter or digit. No leading or trailing slash and no ... A name any known application uses for itself is refused, so wp-admin, wp-content and wp-includes are all unavailable: installing into a folder another application owns costs you that application. |
| Administrator password | Not a field. It is generated and shown once when the install finishes. | Copy it then, or use single sign-on below rather than trying to recover it. |
A website can hold several applications as long as they do not overlap. Installing into a folder that already has one, or into a folder that encloses one, is refused with which folder is in the way.
Step 2
Get into the dashboard.
Under Installed software, Sign in opens the WordPress dashboard as its administrator without a password. It works through a must-use plugin installed beside WordPress, which WordPress loads before the theme and before ordinary plugins, and which nothing a customer installs can switch off from its own dashboard.
This grants nothing new. Whoever can reach that button can already read the application’s files over SFTP and its database through phpMyAdmin, which is everything its administrator can do and more. What it saves is finding a password somebody was shown once, months ago.
The secret is posted as a form rather than put in a link, so it never reaches the address bar, the browser history, a Referer header or any log in front of the website. It is good for a couple of minutes and once only, so open it from the panel each time rather than bookmarking it.
Which version you get
The current one, checked.
An install asks api.wordpress.org which release is current and takes that, checking it against the checksum WordPress publishes for that exact version. If the publisher cannot be reached, or the answer cannot be verified, it installs the version Dashmox vouches for instead and tells you which it used. It does not install something nobody checked.
Step 3
Keep it updated, because that is the whole game.
An application nobody updates is the most common way a hosted website is lost. WordPress applies its own updates, including major versions, through the same must-use plugin, and the panel asks it what it is waiting on. Installed software is where that shows.
For the other applications the panel reads the version each is running and compares it with what its publisher has published, so the page names the release you are behind rather than leaving you to go and look. A check that could not reach a publisher says so, because “up to date” and “nobody could be asked” look the same on a page and only one of them is true.
What protects it
Rules that assume it will be broken into.
A WordPress site is code somebody else wrote, updated on somebody else’s schedule, with plugins nobody reviewed. So the protections assume a compromise rather than hoping against one. Each is a switch on the website’s protection page, so one that gets in the way of something you genuinely need can be turned off.
| Protection | What it stops | Turn it off if |
|---|---|---|
| Scripts in upload folders are served, not run | A PHP file uploaded into wp-content/uploads executing. This is how almost every compromise finishes: getting a file in is the first half, running it is the second. |
Never, realistically. Nothing legitimate puts runnable code there. |
xmlrpc.php is refused |
The oldest remote interface, used mostly for password guessing and amplification. | You use the WordPress mobile app or Jetpack, which still need it. |
| Sign-in pages are rate limited | The cheap automated attempt against wp-login.php, by making it uneconomic rather than impossible. |
A legitimate integration signs in repeatedly and is being caught. |
| PHP cannot run a command | Writing a file turning into having a shell. It is the step between a compromised plugin and a compromised server. | A plugin genuinely needs to shell out, which is worth questioning first. |
Copying a website gives the copy its own database, so a staging site is real rather than a second name for the live one. Test a plugin or a major upgrade there, and keep backups for when that is not enough.
Ten other applications install the same way; the full list says which. One works differently: Pixelfed takes a whole website rather than a folder, and installing it turns on that website’s cache and background worker.
Your servers, with nothing on them counted.
The whole panel is free on one server, with no limit on websites, mailboxes, DNS zones or customer accounts. Pro carries five servers and Business as many as you run.