Install WordPress manually: database, wp-config and first login

A manual WordPress install is four things: the files in the web root, a database with a user that can write to it, a wp-config.php holding those credentials and eight random salts, and one visit to /wp-admin/install.php. On a normal connection the whole job takes about ten minutes, and nine of those are waiting for an upload.

Almost everything that goes wrong afterwards is one of four mistakes: the database host is not localhost, the files are owned by the wrong user, the site address in the database does not match the address people type, or PHP is too old for the theme. This guide does the install and then goes through each of those properly, because the install itself is the easy half.

What you need before you start#

WordPress is deliberately undemanding. The project's own recommendation is PHP 7.4 or newer and a MySQL 8.0 or MariaDB 10.5 class database, with HTTPS available. The true minimum is lower, but a plugin written this year will assume PHP 8, so treat 8.1 as the floor and 8.2 or 8.3 as the sensible choice. Do not pick a PHP version newer than your theme and payment plugins have been tested against - that is the one upgrade that reliably breaks a shop.

You also need to know two things about your hosting before you type anything: which user PHP runs as, and whether you have shell access. The first decides file permissions. The second decides whether you can use WP-CLI or have to do the whole job through a file manager and phpMyAdmin. Panel-based hosting usually gives you the second route only - the console there is the web server's own output, not a login shell - and that is perfectly sufficient.

Get the files onto the server#

The canonical download is https://wordpress.org/latest.zip (or latest.tar.gz). Never install from a copy someone sent you, a "nulled" bundle, or a zip from a search result: injected code in a themes directory is the most common way a site starts life already compromised.

With shell access:

$ cd /var/www/example.com$ wget https://wordpress.org/latest.tar.gz$ tar -xzf latest.tar.gz --strip-components=1$ rm latest.tar.gz

--strip-components=1 is the part people miss. The archive contains a top-level wordpress/ folder, so without it you end up with /var/www/example.com/wordpress/index.php and a site that only answers at example.com/wordpress. That is a legitimate layout if you want it, but choose it on purpose.

Without shell access, upload latest.zip through the file manager and unpack it in place - a file manager that extracts archives server-side turns a 60 MB upload of 2,000 small files into one upload of one file, which is roughly twenty times faster over SFTP. Then move the contents of wordpress/ up one level and delete the empty folder.

The files must land in the directory the web server serves. Common names are public_html, www, htdocs or public. If you upload to the wrong one you get a directory listing or a default page, and nothing you do to wp-config.php will change that. SFTP and the file manager covers getting the credentials and finding the root.

Create the database and its user#

WordPress will not create a database for itself. It needs one that already exists, plus a user with full rights on it - and only on it. If you have a control panel with a database section, use it; the credentials it generates are better than the ones you would pick. If you have SQL access:

CREATE DATABASE wordpress CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;CREATE USER 'wp_site'@'%' IDENTIFIED BY 'a-long-random-password';GRANT ALL PRIVILEGES ON wordpress.* TO 'wp_site'@'%';FLUSH PRIVILEGES;

Three details are worth the extra seconds:

• `utf8mb4`, not `utf8`. The older utf8 in this family stores three bytes per character and cannot hold emoji or several scripts. A post that ends mid-sentence where an emoji used to be is this, and fixing it after the fact means a collation conversion on every table.
• One user per site. GRANT ALL ON wordpress.* gives that user nothing outside its own database. A shared user across three sites means one compromised plugin reaches all three.
• `ALL PRIVILEGES` is not optional. WordPress needs ALTER and CREATE at install and on every update that adds a table. A read-write-only grant installs fine and then fails on the first plugin that ships a schema.

Write down four values before you go any further: database name, user, password, and host. The host is the one people get wrong. It is localhost only when the database runs on the same machine as PHP. Anywhere else it is a hostname, and if the port is not the default it goes on the end: DB_HOST accepts db.internal.example:3307.

On RE:NODE, web plans carry two database slots created from the panel. It generates the host, user, database name and password for you, and the Open in phpMyAdmin button signs you in with a single-use token that expires after sixty seconds, so the password never gets typed into a browser form. Copy those four values straight into wp-config.php. The phpMyAdmin import and export guide covers the same panel from the other direction, for when you are moving an existing site in.

wp-config.php, line by line#

Rename wp-config-sample.php to wp-config.php and edit it. Keep the file in the site root unless you know why you are moving it, and never leave a copy named wp-config.php.bak or wp-config.old next to it - those are served as plain text and hand over your database password.

define( 'DB_NAME',     'wordpress' );define( 'DB_USER',     'wp_site' );define( 'DB_PASSWORD', 'a-long-random-password' );define( 'DB_HOST',     'localhost' );define( 'DB_CHARSET',  'utf8mb4' );define( 'DB_COLLATE',  '' );$table_prefix = 'wp_';define( 'WP_DEBUG',         false );define( 'WP_DEBUG_LOG',     false );define( 'WP_DEBUG_DISPLAY', false );define( 'FS_METHOD',          'direct' );define( 'DISALLOW_FILE_EDIT', true );define( 'WP_MEMORY_LIMIT',    '256M' );define( 'WP_ENVIRONMENT_TYPE', 'production' );

What each of those is actually doing:

• `DB_COLLATE` should stay empty. WordPress picks the right collation for the charset; setting it by hand is how sites end up with mixed collations that break joins after a migration.
• `$table_prefix` is wp_ by default. Changing it is often sold as security; it is not, because anything that can read your tables can read the prefix out of wp_options equivalents in seconds. It is genuinely useful for putting two sites in one database, which is the only reason to change it.
• `WP_DEBUG` off in production, always. When you need it, set WP_DEBUG and WP_DEBUG_LOG to true and WP_DEBUG_DISPLAY to false: errors then go to wp-content/debug.log instead of to your visitors, who do not need your file paths.
• `FS_METHOD` set to `direct` stops WordPress asking for FTP credentials every time you install a plugin. It only works when the PHP user can write to wp-content, which is the permission section below.
• `WP_MEMORY_LIMIT` defaults to 40M for the front end and WP_MAX_MEMORY_LIMIT to 256M for admin pages. 40M is not enough for a modern theme. This constant can only lower or raise within what PHP itself allows, so it is half of the story - the php.ini settings that matter is the other half.
• `WP_ENVIRONMENT_TYPE` tells plugins whether they are on production, staging, development or local. Set it correctly on every copy of the site, and backup and payment plugins that respect it will stop emailing customers from your staging clone.

Two more you will want eventually, but not during the install:

define( 'WP_HOME',    'https://example.com' );define( 'WP_SITEURL', 'https://example.com' );

These override whatever is stored in the database. They are the fastest fix for a site that redirects to the wrong hostname, and the reason a cloned staging site sends visitors back to production. They also make the Settings screen fields read-only, which is a feature.

Salts, and what they actually protect#

The sample file has eight placeholder constants: AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY, and the matching AUTH_SALT, SECURE_AUTH_SALT, LOGGED_IN_SALT and NONCE_SALT. They are not passwords and you never type them anywhere. WordPress uses them to sign the login cookies and the nonces in admin forms.

Leave them as put your unique phrase here and every session cookie your site issues is forgeable by anyone who has read the sample file - which is everyone. Generate real ones:

$ curl https://api.wordpress.org/secret-key/1.1/salt/

That endpoint returns eight ready-made define() lines. Paste them over the placeholders. If the machine has no outbound access, any eight strings of 64 random characters work just as well; they only need to be long, random and secret.

File ownership and permissions#

This is where manual installs get stuck, and the correct answer depends on one thing: the user PHP runs as. Call it www-data here; on your host it might be nginx, apache, or a per-site user.

$ cd /var/www/example.com$ chown -R www-data:www-data .$ find . -type d -exec chmod 755 {} \;$ find . -type f -exec chmod 644 {} \;$ chmod 640 wp-config.php

Never use 777. It is the answer on a hundred forum threads and it means "anyone on this machine may rewrite this file", which on shared hardware includes the site next door. If uploads fail at 755, the problem is ownership, not the mode - the directory belongs to the wrong user, usually because the files were uploaded over SFTP as your personal account rather than the PHP one.

On a container-based panel there is only one user inside the container, so ownership is not a question you have to answer: whatever the file manager writes, PHP can read and update. That is one of the few genuine simplifications of a panel over a bare virtual server, and it is why FS_METHOD set to direct works there without any further thought.

Run the installer#

Visit https://example.com/wp-admin/install.php. If WordPress can reach the database it asks for four things.

1. Site title. Changeable later, no consequences.
2. Username. Not admin, not the site name, not your first name if that is also your author name. Automated login attempts try exactly those three.
3. Password. Use the generated one and put it in a password manager.
4. Email. A real, monitored mailbox. Password resets and critical error notices go there, and a site whose admin email bounces has no recovery path.

There is also a Discourage search engines checkbox. It sets one option and writes a noindex header; it is right for a site you are building and catastrophic if it stays ticked after launch. Check Settings, then Reading, on the day you go live. A site that "will not rank" a month after launch has this box ticked about a third of the time.

The installer creates the tables, writes the first user, and drops you at /wp-admin. There is nothing to clean up afterwards - install.php stays, and re-running it on an installed site just shows a message.

If you have shell access, WP-CLI does the same work in two commands and is much easier to script:

$ wp core config --dbname=wordpress --dbuser=wp_site --dbpass='...' --dbhost=localhost$ wp core install --url=https://example.com --title="Example" \    --admin_user=owner --admin_email=you@example.com --prompt=admin_password

Permalinks, HTTPS and the site address#

Three settings decide whether the site behaves. Do them in this order.

Permalinks. Settings, then Permalinks, then Post name, then Save - saving is what regenerates the rules. On Apache this writes a block into .htaccess, and if that file is not writable WordPress prints the rules for you to paste in. On nginx there is no .htaccess; the rewrite lives in the server configuration and looks like this:

location / {    try_files $uri $uri/ /index.php?$args;}

If every URL except the home page returns 404, this is why - the rule is missing, or you are on nginx expecting .htaccess to do something. On managed hosting the rule is normally already in place and you never see it.

HTTPS. Get the certificate working before you install, so the site address is https:// from the first row written to the database. Changing it later means a search-replace across the whole database, which is a chapter of migrating WordPress to a new host rather than a setting.

The proxy header. When TLS terminates in front of PHP - any reverse proxy, any CDN - PHP does not see an encrypted request, so WordPress builds http:// URLs, redirects to them, gets redirected back, and the browser reports a redirect loop. The fix goes in wp-config.php above the require_once ABSPATH . 'wp-settings.php'; line at the bottom:

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] )    && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https' ) {    $_SERVER['HTTPS'] = 'on';}

Only add it if a proxy you control really does set that header, otherwise you have made it trivial to fake HTTPS. RE:NODE web plans carry a proxy slot: point an A record at the address shown on that tab and the certificate is issued and renewed automatically, with the visitor's real address arriving in X-Forwarded-For. What a reverse proxy does explains the rest of the headers, and your domain and its certificate covers the DNS half.

When it does not work#

Error establishing a database connection. One of the four credentials is wrong, or the database server is not reachable from PHP. Test the credentials in phpMyAdmin first - if they work there and not in WordPress, the difference is almost always DB_HOST, and almost always localhost where a real hostname is needed.

A white screen. A PHP fatal error with display off. Set WP_DEBUG and WP_DEBUG_LOG to true, reload, read the last lines of wp-content/debug.log. Nine times in ten it names the plugin or the function, and the answer is a PHP version mismatch or an exhausted memory limit.

Allowed memory size exhausted. PHP hit memory_limit. Raise WP_MEMORY_LIMIT, and if that changes nothing then PHP's own limit is lower and has to be raised first.

The upload failed to write to disk, or the uploads folder is not writable. Ownership of wp-content/uploads, or a full disk. Check free space before you change any permissions.

A file exceeds the upload_max_filesize directive. PHP's limit, not WordPress's. It needs upload_max_filesize and post_max_size raised together, and possibly a body-size limit on the proxy in front.

Mixed content warnings. The page came over HTTPS and asked for an image over HTTP. The URLs are stored in the database with the old scheme; fix them with a search-replace tool that understands serialised data, never a plain SQL REPLACE.

Redirect loop straight after install. The proxy header case above, or WP_HOME and WP_SITEURL disagreeing with the hostname in the address bar - including the www and non-www versions being treated as different sites.

FAQ#

Do I need a one-click installer?

No, and there is an argument for not having one. A manual install takes ten minutes, puts the exact version you chose on disk, and leaves nothing behind that you did not put there. Installers often pin a version, add their own must-use plugins, or create a database user with wider rights than the site needs.

Can I install WordPress in a subfolder and serve it at the root?

Yes. Put the files in /wordpress, set WP_SITEURL to https://example.com/wordpress and WP_HOME to https://example.com, then copy index.php and .htaccess to the root and edit the one line in index.php that requires wp-blog-header.php so it points into the subfolder. It keeps the web root tidy; it is not a security measure.

How do I get WordPress to send email?

Not from the web server, in practice. Mail from a hosting IP with no SPF, DKIM or DMARC alignment lands in spam or is refused outright, and many hosts - RE:NODE included - do not run mail at all. Install an SMTP plugin and point it at a transactional mail provider or your own mailbox. SPF, DKIM and DMARC explained covers why the records matter even then.

Should I change the wp_ table prefix?

Only to put multiple sites in one database. As a security measure it buys nothing: any code that can query your tables can also list them. Changing it on a live site means renaming every table plus editing two rows in the options and user-meta tables, and getting that half-right breaks the admin.

What should I do immediately after the first login?

Delete the unused default theme and any bundled plugin you will not use, set permalinks, untick the search-engine box if you ticked it, add a second administrator account you can recover with, and take a backup before you install a single plugin. Then read WordPress security hardening.

How much does a fresh WordPress site need in terms of resources?

A 1 GB, 0.5 vCPU plan runs a small brochure site comfortably. Memory becomes the limit when plugin count and PHP worker count rise together, not when traffic does - which is why a plugin-heavy site with fifty visitors a day can need more memory than a lean one with five thousand.