Setting up WordPress hosting is two layers that people mash together in marketing copy. The runtime is PHP, a web server, TLS, and MySQL. The CMS is WordPress itself: wp-config.php, salts, table prefix, admin user, themes, plugins. WPHost runs the first layer. You still configure the second.

This guide is the configuration pass — salts, prefixes, environment variables versus hard-coded credentials — after you know the install order from how to host a WordPress website. It is not a theme tutorial and not a Softaculous pitch. There is no one-click installer here today: you upload WordPress and finish setup yourself.

Runtime checklist (host side)

Before touching wp-config.php:

  1. Create a PHP site (PHP 8.4), not a static site.
  2. Upload a zip whose document root contains index.php and wp-admin.
  3. Provision MySQL from the dashboard and save the four values: name, user, password, host.
  4. Confirm the preview URL loads over HTTPS.

Custom domain can wait. Setup on preview avoids fighting DNS while you debug credentials. When you do attach a domain, update WordPress Address and Site Address — see WordPress hosting with a custom domain.

What the host does not set up for you: plugin auto-updates, a built-in CDN, email inboxes, cPanel accounts, or a scheduled full-site WordPress backup product. Deploy history restores files. Database backups are yours (UpdraftPlus or dumps).

wp-config.php is still the source of truth

WordPress reads wp-config.php early. A minimal, honest setup looks like this:

<?php
define( 'DB_NAME', 'db_from_dashboard' );
define( 'DB_USER', 'user_from_dashboard' );
define( 'DB_PASSWORD', 'password_from_dashboard' );
define( 'DB_HOST', 'host_from_dashboard' );
define( 'DB_CHARSET', 'utf8mb4' );
define( 'DB_COLLATE', '' );

$table_prefix = 'wp_';

define( 'AUTH_KEY',         'put your unique phrase here' );
define( 'SECURE_AUTH_KEY',  'put your unique phrase here' );
define( 'LOGGED_IN_KEY',    'put your unique phrase here' );
define( 'NONCE_KEY',        'put your unique phrase here' );
define( 'AUTH_SALT',        'put your unique phrase here' );
define( 'SECURE_AUTH_SALT', 'put your unique phrase here' );
define( 'LOGGED_IN_SALT',   'put your unique phrase here' );
define( 'NONCE_SALT',       'put your unique phrase here' );

if ( ! defined( 'ABSPATH' ) ) {
    define( 'ABSPATH', __DIR__ . '/' );
}
require_once ABSPATH . 'wp-settings.php';

Replace the salt placeholders with output from the official salt generator. Never ship a site with the sample phrases still in place. Salts do not encrypt your database password; they harden cookies and nonces. Rotating them later logs everyone out — annoying, but useful after a staff machine is compromised.

Table prefix: default is fine, unique is fine

$table_prefix = 'wp_'; is what most tutorials use. Changing it to something like acme2026_ is a mild obscurity measure, not a security product. Do it before the installer runs. Changing prefix after install means renaming every table and fixing options that store table names — a migration chore, not a toggle.

If you migrate an existing site, keep the prefix the dump expects. Do not “harden” a live dump by renaming tables mid-flight unless you know every serialized reference you will break.

Environment variables versus literals in wp-config

Some teams prefer not to commit database passwords into a zip that sits in deploy history. WPHost supports per-site environment variables. A common pattern:

define( 'DB_NAME', getenv( 'DB_NAME' ) ?: 'fallback_local_name' );
define( 'DB_USER', getenv( 'DB_USER' ) ?: 'fallback_local_user' );
define( 'DB_PASSWORD', getenv( 'DB_PASSWORD' ) ?: 'fallback_local_password' );
define( 'DB_HOST', getenv( 'DB_HOST' ) ?: '127.0.0.1' );

Put the real values in the site’s env UI for production. Keep fallbacks only for local docks or never commit real production secrets into the zip at all.

Tradeoffs:

  • Literals in wp-config — simple, matches every WordPress doc, easy to debug. Anyone with file access sees the password. Deploy history may retain older zips that still contain secrets if you embedded them.
  • Env-driven defines — better secret hygiene if your process already uses env. Harder for beginners; a missing env var becomes “Error establishing a database connection” with less obvious cause.

Pick one pattern per site and document it for whoever inherits the project. Do not mix half-env, half-hardcoded credentials and then forget which layer won.

Other defines people sometimes set during setup:

define( 'WP_DEBUG', false );
define( 'DISALLOW_FILE_EDIT', true );
define( 'FS_METHOD', 'direct' );

DISALLOW_FILE_EDIT blocks the theme/plugin file editor in wp-admin — good hygiene on production. WP_DEBUG should stay false on public sites; use staging on Pro+ when you need noisy errors. File writes for updates usually work with direct FS on this kind of host; if update UI complains about FTP credentials, fix permissions rather than inventing an FTP server WPHost does not sell.

HTTPS and URLs during setup

Preview HTTPS is available immediately. After DNS for a custom domain, a certificate issues for that name. WordPress still stores canonical URLs in the database (siteurl and home). If those say http:// while the edge speaks https://, you get redirect loops or mixed assets.

During initial setup on preview, either:

  • Let the installer set URLs to the preview HTTPS host, then change them when the custom domain is ready, or
  • Set them deliberately in Settings → General once you know the final https:// URL.

Do not leave http://example.com in General settings on a host that only serves TLS cleanly on HTTPS. Details and recovery tips live in the custom domain guide.

What “setup” does not include on WPHost

Updates. You update core, themes, and plugins in wp-admin. There is no automatic plugin/core update agent. That is intentional honesty, not a missing checkbox we forgot to market.

Email. Outbound mail from contact forms needs an SMTP plugin and a mail provider. There is no inbox on the plan.

CDN. No built-in CDN product. If you need one, put Cloudflare (or similar) in front yourself and understand cache rules for wp-admin and carts.

Git magic for agencies. GitHub connections are per-person. Do not assume shared agency deploy bots beyond what your seats and tokens actually allow — see WordPress hosting for agencies.

Staging content clone. Staging on Pro+ is a persistent copy for testing. Copy the database yourself if you need production posts on staging — WordPress staging hosting.

Suggested setup order after credentials work

  1. Finish the browser installer; store the admin password.
  2. Permalinks → save.
  3. Install backup plugin; run files + database backup off-host.
  4. Install 2FA for admin users.
  5. Only then install the page builder / SEO / cache stack you actually need.
  6. On Pro+, test cache plugins on staging before production.
  7. Attach domain; fix siteurl/home; verify TLS.

If you are sizing plans while you set this up: Starter $9/mo (1 site, 2 GB), Pro $30 (3 sites, 10 GB, staging), Scale $65 (10 sites, 30 GB), Business $130 (30 sites, 100 GB, teams). Trial is short (~1 day), then paid. No nonprofit coupon.

For a skeptical framing of what “managed” means in this stack, read what is managed WordPress hosting. For the install sequence with domain last, stay with the first-host walkthrough.

FAQ

Do I have to use environment variables?

No. Classic wp-config.php defines work. Env is optional hygiene for teams that already treat secrets as config, not files in a zip.

Can WPHost generate wp-config for me?

Not as a one-click installer. You create wp-config.php from the sample (or your export) and paste dashboard database values. Salts come from WordPress’s generator or your own secrets process.

Will changing salts break the site?

The front end keeps working. Logged-in sessions reset. Do it after a suspected cookie theft or staff offboarding — not casually every Monday.

Where do I put WP_HOME and WP_SITEURL?

You can define them in wp-config.php or set them in Settings → General (options home and siteurl). Prefer HTTPS final URLs. Conflicting defines and DB values cause confusing redirects — keep one source of truth.

Is setup different without cPanel?

Yes, and that is fine. You never needed cPanel to run WordPress — only PHP, MySQL, file deploy, and wp-admin. See WordPress hosting without cPanel.