One-click apps: WordPress, Ghost, Strapi and a mail server

A one-click app saves you the installation and nothing after it. On RE:NODE there are four of these lines: WordPress, with its files in place and a MySQL database already created and connected; Ghost, installed and built on the server's first start with its data in SQLite; Strapi, created and built the same way, also on SQLite; and a Mail Server running Stalwart, with SMTP, IMAP, JMAP and a web admin. In each case the first thing you do is open an address and claim the admin account, and the things that remain yours are the same four on every line: the domain, outgoing mail, backups you have actually tested, and updates. Pick WordPress for a site that needs plugins and a familiar editor, Ghost for writing and newsletters, Strapi when a separate front end needs a content API, and the Mail Server only if you want to run mail yourself and accept what that involves.

The rest of this post goes line by line: what is preinstalled, what the first login looks like, the settings you still have to touch, and the mistakes that cost people their first day.

What the four one-click lines install#

A one-click line is a finished application rather than a runtime you fill with your own code. The server is created when payment clears, usually inside a minute, and the install itself happens on the first start (or, for WordPress, on the first install). After that it is an ordinary server: the same console, file manager, SFTP, backups and schedules as every other plan, nothing gated by tier.

Two of these lines need no separate database. Ghost and Strapi keep their content in a SQLite file on the server itself, so there is nothing else to buy or connect; if you later want PostgreSQL or MySQL, you add a database line and point the application at it. WordPress is different because WordPress needs MySQL, so the WordPress line creates a MySQL database of its own and writes the connection details into wp-config.php. The Mail Server keeps mailboxes on its own disk.

One thing that is not on the list matters as much as what is. One-click installs exist only for these lines. On the Engines web plans, which are sized for Drupal, Joomla, DLE or a Laravel application, you install the CMS yourself, and there is no installer for modpacks, plugins or themes anywhere. CMS hosting compared covers the self-installed options.

What happens on the first start#

The order of events is the same on all four lines, and knowing it saves a support ticket.

1. The server appears in the panel. It has an address and a port, shown at the top of the server page.
2. Start it and keep the Console tab open. Ghost and Strapi download and build on this first start, which takes noticeably longer than any later start, and the console shows every step. A build is also the hungriest thing these applications do for memory, so the first start is the moment to watch the memory graph.
3. When the console says the application is listening, open the address. Each line has its own first screen, covered below.
4. Claim the admin account straight away. On WordPress, Ghost and Strapi the first person to reach the setup screen becomes the owner. Nobody knows the address of a brand-new server yet, but this is not a step to leave for tomorrow.
5. Only then point a domain at it.

If the first start ends in an error rather than a listening message, read the last thirty lines of the console before restarting. A restart repeats the same step and usually fails the same way. The two causes we see most are a build running out of memory on a plan that was sized for serving, not building, and a file the reader edited before the first start had finished.

WordPress: first login and what is already done#

On the WordPress line, the first install downloads WordPress into the web root, creates a MySQL database for it with a generated user and password, and writes those into wp-config.php. So the part of a WordPress install that usually goes wrong - creating the database, typing its host, user and password into the config - is already finished. Installing WordPress by hand shows what that step looks like when nobody does it for you.

The first visit to the server's address opens the WordPress installer. It asks for five things: site title, admin username, password, email address, and whether search engines should index the site. Choose an admin username that is not admin, use a long generated password, and give an email address you read, because password resets go there. Tick the box that discourages search engines if the site is not ready; it adds a noindex signal you must remember to remove at launch under Settings, Reading.

Things worth checking in wp-config.php in the file manager once you are in:

// Database details are already written by the install - leave them.// Check the eight keys and salts are long random strings, not placeholders.define( 'AUTH_KEY', '...' );// Useful additions for a production site:define( 'DISALLOW_FILE_EDIT', true );   // no theme/plugin editor in wp-admindefine( 'WP_POST_REVISIONS', 10 );      // cap stored revisions per postdefine( 'WP_DEBUG', false );

If any of the keys and salts still read put your unique phrase here, replace them with values from WordPress's own generator at https://api.wordpress.org/secret-key/1.1/salt/. Changing them logs everyone out, which is harmless on a new site.

What you still configure on WordPress:

• The address. WordPress stores its own URL in the database (Settings, General: WordPress Address and Site Address). Once your domain and certificate work, change both to https:// plus the domain. Do it after HTTPS answers, not before, or you lock yourself out of wp-admin behind a redirect to an address that does not exist yet.
• Permalinks. Settings, Permalinks, then pick "Post name". The WordPress line runs on the web-hosting stack, which is nginx and PHP, so .htaccess rules that plugins write have no effect. Plugins that promise to fix things through .htaccess are the wrong tool here.
• Outgoing mail. WordPress sends through PHP's mail() by default, which is the least reliable way to send mail from any server. Install an SMTP plugin and point it at a real mail service. Transactional email from your app explains the options.
• Caching. A fresh WordPress renders every page with PHP on every request. A page cache is the single biggest speed change you can make; WordPress caching covers what actually moves time to first byte and what does not.
• Hardening. Plugin updates, a login rate limit, removing plugins you do not use. WordPress security hardening is the full list.

The database is reachable from the panel's database page, with "Open in phpMyAdmin" signing you in with a one-use token. That is where you go to fix a wrong siteurl if you do lock yourself out: the wp_options table, rows siteurl and home.

Ghost: first login and what you still set#

Ghost is installed and built on the server's first start, with its data in SQLite on the server. On a machine you own outright, Ghost is normally installed with Ghost-CLI, which also sets up MySQL, nginx, a certificate and a service manager; none of that applies here, because the panel already provides the process supervision and the proxy slot provides HTTPS.

The first login is at the server's address with /ghost on the end. The first visit is the setup screen: site title, your name, email and password. That account becomes the Owner, and there is only ever one. Staff accounts come later, by invitation, with Contributor, Author, Editor and Administrator roles.

Two settings decide whether a Ghost site works in public, and both live in config.production.json in the file manager:

{  "url": "https://blog.example.com",  "mail": {    "transport": "SMTP",    "options": {      "host": "smtp.example.com",      "port": 465,      "secure": true,      "auth": { "user": "postmaster@example.com", "pass": "app-password" }    }  }}

url is the exact public address, scheme included. Ghost builds every link, canonical tag, RSS entry, sitemap entry and email link from it, and redirects visitors to it, so set it only after your domain answers over HTTPS, then restart. Leave server.host and server.port as the install wrote them: they are arranged to match the port allocated to your server.

The mail block is for transactional mail: staff invitations, password resets and member sign-in links. Without it, nobody you invite can accept. Bulk newsletters are a separate setting in Ghost's admin; self-hosted Ghost sends them through Mailgun, so a site that wants to email its members needs a Mailgun account as well as the SMTP settings above. Check the current Ghost documentation before you plan around that, because it is the kind of detail that changes between major versions.

Themes are uploaded as zip files from the admin (Settings, Design), and custom ones can also go into content/themes over SFTP. Everything that is yours - images, themes, the SQLite database - lives under content. The Ghost hosting guide goes much deeper on newsletters, themes, SQLite backups and updates that do not break the site.

Strapi: first login and the development-mode question#

The Strapi line creates a Strapi project and builds its admin panel on the first start, with content in SQLite. Plans start at 2 GB of memory, which is what Strapi's own documentation asks for to build the admin comfortably; the running process afterwards uses much less.

The first login is at /admin on the server's address. The first visit asks you to register the super admin: name, email and password. As with Ghost, whoever gets there first owns the install, so do it immediately after the first start.

The project folder holds a .env file with the secrets Strapi needs. A project created with Strapi's own generator gets random values for each:

APP_KEYS=...API_TOKEN_SALT=...ADMIN_JWT_SECRET=...TRANSFER_TOKEN_SALT=...JWT_SECRET=...

Copy those values into a password manager now. They must never change after launch: regenerate API_TOKEN_SALT and every API token your front end holds stops working; regenerate ADMIN_JWT_SECRET and every editor is logged out. If you ever rebuild the server, restore the same set.

The question to settle on day one is where you design content types. Strapi's Content-Type Builder - where you create collection types, fields and components - only allows changes when Strapi runs in development mode. In production mode (strapi start) it is read-only, by design, because a content type is code: it writes files into src/api and those belong in version control. Look at the startup command on the Startup tab to see which mode your server runs. The two sensible workflows are:

1. Model content on your own machine with npm run develop, commit the project to GitHub, and pull it onto the server, either by uploading the changed src folder or with the panel's GitHub deploy. Then rebuild the admin and restart.
2. For a small, single-person project, model directly on the server while it runs in development mode, then switch it to production before the site goes public. Simpler, but there is no history of what you changed.

What you still configure on Strapi: the public url in config/server.js so links and the admin work behind your domain; API permissions under Settings, Users and Permissions, because by default the public role can read nothing and the most common "Strapi returns 403" question is that; API tokens for your front end; and the upload provider if you want media somewhere other than public/uploads. The Strapi production guide covers every one of those with the exact files.

The Mail Server line: Stalwart and the parts that stay yours#

The Mail Server line is a whole Stalwart server that you run, not mailboxes sold one at a time. It does SMTP for sending and receiving, IMAP and JMAP for mail clients, and has a web admin where you create domains and accounts, fetch the DKIM keys and set up spam filtering. Plans carry five ports, which covers submission, IMAPS, the web admin and a couple more.

A fresh Stalwart install starts in what the project calls bootstrap mode: it prints a temporary administrator password to its console once, and the web admin's setup asks for the host name, the default domain and where to keep data. So the first login starts on the Console tab - read the password from the first start's output, sign in, and change it to one that lives in a password manager. That admin account can read every mailbox and redirect every domain's mail, so do not use it as a mailbox. Stalwart mail server setup walks through the first hour in detail.

Three things remain yours, and none of them is optional:

example.com.                 MX   10 mail.example.com.mail.example.com.            A    <server address>example.com.                 TXT  "v=spf1 mx -all"<selector>._domainkey        TXT  "v=DKIM1; k=rsa; p=..."_dmarc.example.com.          TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

The selector and the DKIM key itself are whatever the web admin shows for your domain; copy them exactly.

• DNS records. You publish MX, SPF, DKIM and DMARC at whoever runs your DNS. There is no zone editor on our side. The DKIM record comes from the web admin. SPF, DKIM and DMARC explained covers what each one does.
• Port 25 inbound. Other mail servers deliver only to port 25, and a container cannot open that port on the public address by itself. Open a ticket and support forwards it to your server. It is one mail server per address, because only one server can own port 25 on an IP.
• Outbound delivery. If the network a recipient's server sits on refuses mail from you, or outgoing port 25 is blocked, send through a relay configured in the web admin. SMTP relay for outgoing mail explains how.

The honest summary is in self-hosted mail server: what it really takes: mail is light on CPU and heavy on attention. If you only need a contact form to send notifications, you do not need a mail server; a transactional mail service is less work.

Domains and HTTPS on every line#

The domain step is the same on the web and app lines. Each plan includes a reverse-proxy slot. Add your domain in the proxy slot, point an A record for it at the address the panel shows, and the certificate is issued and then renewed automatically, inside a 21-day window before it expires. The visitor's real IP address arrives at the application in the X-Forwarded-For header, which matters for comment spam filters, rate limiting and analytics.

The order that avoids a lockout is the same everywhere:

1. Finish the setup screen on the plain server address.
2. Add the domain in the proxy slot and create the A record. Your domain and its certificate explains the waiting part.
3. Open https:// plus the domain and confirm the certificate is valid.
4. Only then change the application's own address: WordPress Address and Site Address, Ghost's url, Strapi's url.
5. Restart the application and check the admin still loads.

An application behind a proxy that terminates HTTPS sees plain HTTP from the proxy. Ghost and Strapi handle this through their url setting. WordPress sometimes does not, which shows up as a redirect loop or mixed-content warnings after step 4. The usual fix, if the proxy sends the X-Forwarded-Proto header, is to tell WordPress about it near the top of wp-config.php:

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

The Mail Server is the exception: mail clients do not go through the proxy slot, and the host name in your MX record is what other mail servers look for.

Backups and updates#

Every one-click plan has backup slots. A backup is taken on demand or on a schedule, stored off the machine it protects, downloadable, and restored with a button; lock the ones you want kept out of rotation. Separately, we take a nightly system backup of every server outside your slots, but you cannot restore from it yourself - that goes through support - so treat your own backups as the ones that count.

What a backup needs to contain differs per line:

The WordPress row is the one people get wrong. The posts, pages, users and settings are in MySQL, not in the files, so a server backup of the web root is half a backup. Dump the database as well; mysqldump backup and restore has the commands, and phpMyAdmin's export does the same job for a small site.

For Ghost and Strapi, the SQLite file is the database. Copying it while the application is writing can produce a file that will not open. The safe pattern is stop, back up, start, and the Schedules tab can do exactly that in one ordered task at a quiet hour: a power action to stop, a backup, a power action to start. Backups that actually restore is about the part after: a backup nobody has restored is a hypothesis.

Updates are yours to run. Every file the installer writes is in the file manager and over SFTP, and what you change is not overwritten by our side. WordPress updates itself from wp-admin, plugins included; back up first. Ghost and Strapi updates are version upgrades with database migrations that run on the next start, so read the release notes, back up, upgrade, and watch the first start's log. Stalwart publishes upgrade notes per release; read them before a major version.

Which one to pick#

The choice is mostly made by what you are building, not by the price difference.

A few rules of thumb from running all four:

• WordPress is the safe answer for a business site that will grow sideways: a shop, a booking form, a members area, a page builder somebody's marketing team insists on. The cost is maintenance - plugins are the attack surface and the slow part. How much RAM WordPress needs helps size the plan; the Starter tier is for a blog or a small business site, not WooCommerce with a catalogue.
• Ghost is the better tool when the site is mostly writing. It is fast without a caching plugin, has members and newsletters built in, and has far fewer moving parts. It is the wrong tool if you need a shop, a forum or arbitrary page layouts.
• Strapi only makes sense if someone is building the front end: a Next.js site, a mobile app, a static site generator. On its own it serves JSON, not pages. If nobody on the project writes front-end code, pick Ghost or WordPress.
• The Mail Server is for people who want their domain's mail on a server they control and are willing to look after DNS records, reputation and spam. For a contact form's notifications, a relay or transactional service is enough.

If none of them fits, that is the case for an app hosting runtime with your own code, or the Engines web plans for a CMS you install yourself.

Common first-day problems#

• "502" or nothing at the address on the first start. The install is still running. Ghost and Strapi build on the first start; wait for the console to say the app is listening.
• The first start was killed and restarted. At the memory limit the kernel stops the container and it restarts clean rather than swapping. A build that needs more memory than the plan has will loop. Check the memory graph; a larger tier is the fix, and changing plan does not rebuild the server.
• Locked out of wp-admin after changing the address. Fix siteurl and home in wp_options through phpMyAdmin, or add define( 'WP_HOME', '...' ); and define( 'WP_SITEURL', '...' ); to wp-config.php to override them.
• Ghost invites never arrive. The mail block is missing or wrong. Fix it, restart, resend the invite.
• Strapi returns 403 for every API call. The Public role has no permissions until you grant find and findOne on the content types you want public, or you send an API token.
• Strapi content types cannot be edited. It is running in production mode, which is by design. Model in development mode, as above.
• Mail arrives in nobody's inbox. Port 25 has not been forwarded yet, or the MX record points somewhere else. Check the MX with dig MX example.com and open a ticket for the port.

FAQ#

Do Ghost and Strapi need a database plan?

No. Both keep their data in SQLite on the server, so there is nothing else to buy. If a Strapi project grows several editors and heavy traffic, or you want point-in-time database backups, add a PostgreSQL line and move the content with Strapi's own export and import.

Can I install plugins and themes on the one-click lines?

Yes. On WordPress you install any plugin or theme from wp-admin or upload it over SFTP. Ghost themes upload as zip files; Strapi plugins are npm packages added to the project and followed by an admin rebuild. Nothing is whitelisted.

Is the admin account created for me?

No, and that is deliberate. WordPress, Ghost and Strapi each show a setup screen on the first visit, and you create the owner account there. The Mail Server prints a temporary administrator password to its console on the first start, which you replace.

Can I move an existing site onto a one-click server?

Yes, with the application's own tools. WordPress moves as files plus a database dump, and migrating WordPress to a new host walks through it. Ghost has an export and import in its admin, and Strapi has strapi export and strapi import. Moving mail is its own job.

Will an update from your side overwrite my changes?

No. Every file the installer writes is yours, in the file manager and over SFTP, and an update never overwrites what you changed. Application upgrades are run by you, so take a backup before each one.

Can I run WordPress and a mail server on one plan?

No. Each line is its own server with its own address and ports. Run WordPress on the WordPress line and mail on the Mail Server line, and use the mail server as the SMTP host for WordPress's outgoing mail.