Documentation

Before you start, make sure your environment meets the Server Requirements.

Two ways to set up a new site

You can build a new WebProCMS site in whichever of these workflows fits the job — both use the same installer described below, and the only difference is where you run it first:

• Install on your live server. The direct path: put the CMS on the host that will serve the finished website, install, and build the site in place. When it's ready, point your domain at it and you're live. Best when the site is mostly content and settings.
• Build locally first, then go live. Install on Laravel Herd on your own Mac, build and preview the entire site locally — where changes are instant and cost nothing — then move it to your live server when it's ready. Best when you want to experiment freely, work offline, or finish the site before it's public.

Moving a locally-built site to production is a restore, not a rebuild: take a backup of the local site from Manage → Backups, install a fresh copy on the live server, and restore the backup onto it. Your content, media, and settings come across, while the application code is delivered fresh by the installer. See Backups & Revisions.

However you set the site up, it keeps itself current the same way afterwards — see Updating WebProCMS.

Opening the installer

Once the WebProCMS files are on your server (or in your Herd sites folder), simply visit your site's address in a browser. When the CMS isn't configured yet, the installer loads automatically — there is no separate setup command. If the site is already installed, the same address redirects you to the dashboard instead.

Step 1 — Choose your platform

The first screen asks where you're installing:

• Local / Herd — Laravel Herd on your Mac. Selected by default. Nothing to set up: Herd handles PHP, Node, and your database, so you can go straight to the form.
• RunCloud — managed server hosting. Selecting this reveals a three-step prerequisite checklist (below).
• Laravel Forge and Ploi are shown as "Coming soon" and can't be selected yet.

Your choice also tunes the install: a Local install is configured for development, while a RunCloud install is configured for production (debugging off, background queue enabled).

Step 2 — RunCloud prerequisites (production only)

If you chose RunCloud, complete these three steps in the RunCloud panel before clicking Install:

1. Issue your SSL certificate

Go to your web app → SSL/TLS and issue a Let's Encrypt certificate. The installer sets your site address to https:// — without SSL, the redirect to the dashboard after installation will fail.

2. Update PHP settings

Open your web app's Settings page and make two changes to its PHP settings:

• Disabled Functions — the installer shows two ready-made lists on a Recommended / Minimal tab. Copy one and paste it over the whole box, replacing what's there. There's nothing to search for or delete by hand.

Recommended frees symlink plus the proc_* group. symlink creates the /storage link that serves your uploaded media — without it every image 404s until php artisan storage:link is run over SSH — and the proc_* group lets WebProCMS use its faster native updates and backups instead of the pure-PHP fallbacks:

getmyuid,passthru,leak,listen,diskfreespace,tmpfile,link,shell_exec,dl,exec,system,highlight_file,source,show_source,fpassthru,virtual,posix_ctermid,posix_getcwd,posix_getegid,posix_geteuid,posix_getgid,posix_getgrgid,posix_getgrnam,posix_getgroups,posix_getlogin,posix_getpgid,posix_getpgrp,posix_getpid,posix_getppid,posix_getpwuid,posix_getrlimit,posix_getsid,posix_getuid,posix_isatty,posix_kill,posix_mkfifo,posix_setegid,posix_seteuid,posix_setgid,posix_setpgid,posix_setsid,posix_setuid,posix_times,posix_ttyname,posix_uname,proc_nice,escapeshellcmd,ini_alter,popen,pcntl_exec,socket_accept,socket_bind,socket_clear_error,socket_close,socket_connect,socket_listen,socket_create_listen,socket_read,socket_create_pair,stream_socket_server

Minimal frees only symlink and leaves the proc_* group blocked. Updates and backups then use the pure-PHP fallbacks, which work fine — just slower:

getmyuid,passthru,leak,listen,diskfreespace,tmpfile,link,shell_exec,dl,exec,system,highlight_file,source,show_source,fpassthru,virtual,posix_ctermid,posix_getcwd,posix_getegid,posix_geteuid,posix_getgid,posix_getgrgid,posix_getgrnam,posix_getgroups,posix_getlogin,posix_getpgid,posix_getpgrp,posix_getpid,posix_getppid,posix_getpwuid,posix_getrlimit,posix_getsid,posix_getuid,posix_isatty,posix_kill,posix_mkfifo,posix_setegid,posix_seteuid,posix_setgid,posix_setpgid,posix_setsid,posix_setuid,posix_times,posix_ttyname,posix_uname,proc_open,proc_close,proc_nice,proc_terminate,escapeshellcmd,ini_alter,popen,pcntl_exec,socket_accept,socket_bind,socket_clear_error,socket_close,socket_connect,socket_listen,socket_create_listen,socket_read,socket_create_pair,stream_socket_server

Both are RunCloud's stock list with entries removed, never added — everything else it blocks stays blocked, and WebProCMS works around those (a disabled tmpfile, for instance, is replaced at runtime so uploads keep working).

Don't hand-edit the proc_* functions individually. They have to move as a group: freeing proc_open while proc_close or proc_terminate stay blocked is worse than blocking all of them, because libraries test for proc_open, take the subprocess path, then call the others without testing — and the install fails partway through. Both lists above keep the group consistent, and the installer warns you if it finds the half-open state.

The installer checks your PHP settings live and shows a warning on its own screen only if something WebProCMS genuinely needs is still blocked, so you'll know before you click Install.

Also raise Max Execution Time from 30 to 60 on the same screen. Resized image variants are generated once, on the first request that needs one, and a full-size AVIF of a large photo can take longer than 30 seconds on a modest host — a request cut off part-way caches nothing, so the next visitor starts the same work again.

3. Tune your web app's server config

If your RunCloud app uses OpenLiteSpeed (the default on most RunCloud apps), open your app's OpenLiteSpeed Web Application Config and make both changes below, then click Save and let OLS reload.

(a) Raise the per-worker memory limit. Find the extprocessor block and change both memSoftLimit and memHardLimit from 2047M to 4096M. Generating a modern AVIF version of a large photo is memory-hungry: a 2400 px wide image peaks around 1.7 GB inside the PHP worker serving the request, and when the encode is refused the image simply doesn't appear — there's no error page, because the request itself succeeds. The stock 2047M leaves under 60 MB of headroom on a warm worker, so large images fail intermittently. The setting is per web app, so raising it doesn't affect other sites on the server.

This is separate from the PHP Memory Limit in step 2, which does not govern image encoding — the image library allocates outside PHP's own allocator. Leave that at the RunCloud default.

(b) Cache static assets for a year. Find the expires block in the same config and paste this over it, replacing what's there:

expires {
  enableExpires           1
  expiresByType           image/*=A31536000,text/css=A31536000,application/x-javascript=A31536000,text/javascript=A31536000,font/*=A31536000,application/x-font-ttf=A31536000
}

The stock block expires images, CSS, JavaScript and fonts after about a week, which is what PageSpeed Insights reports as "Serve static assets with an efficient cache policy". A year is safe because every asset address WebProCMS produces changes when its file does — stylesheets and scripts are fingerprinted at build time, and replacing an image in the media library gives it a new address — so returning visitors always get the new version immediately. The one thing to avoid is overwriting a file on the server by hand at the same path; use the media library's Replace instead.

If your RunCloud app uses Nginx + PHP-FPM instead, there's no per-worker memory cap to raise — Nginx + PHP-FPM imposes none by default, so make sure the server has at least 4 GB of RAM. For the caching half, set the equivalent expires 1y; on static assets in the app's Nginx config.

Step 3 — Fill in your site details

The form collects:

Site Setup

• Site Name — your website's name.
• Site URL — the full address, with no trailing slash. Pre-filled from the address you're visiting.
• Admin Email — this becomes your login email for the dashboard.
• Mail From Address — the address outgoing email is sent from. Defaults to your admin email if left blank; the installer suggests [email protected].

Database

WebProCMS uses MySQL / MariaDB — enter the host, port, database name, username, and password. The connection is tested before installation continues.

Demo content (optional)

Tick any sample content you'd like to start with: blog posts and categories, locations, events, demo forms, navigation menu items, sample content types (Services, Minutes), and the Knowledge Base — the CMS documentation you are reading now, published on your own site. Ticking Events or Knowledge Base also turns on the matching feature for you. Everything here can be added or removed later from Dashboard → Tools — see Seeding Demo Data.

Step 4 — Watch the install run

Click Install WebProCMS and the installer streams its progress live, step by step: writing your configuration, installing dependencies if needed, generating the application security key, creating or connecting to the database, running database migrations, setting up your site's default pages and design library, seeding any demo content you chose, linking file storage, and caching the configuration.

Each step shows a ✓ when done. If a step fails, the error is shown inline, the partial configuration is removed automatically, and you can fix the issue and reload the page to retry cleanly.

Step 5 — The success screen and first login

When installation finishes you'll see your login credentials:

• Email: the admin email you entered.
• Password: a random password generated for this install, shown once — copy it now. You'll be prompted to change it the first time you log in.

The success screen also shows environment-specific tips:

• Local installs: run composer run dev in your terminal to start the development asset server.
• RunCloud installs: in RunCloud, set your web app's Application Stack to Laravel for one-click access to maintenance commands from the panel. There's also an optional deployment script you can copy if you want RunCloud's Deploy button to update the app — though most installs only ever need the built-in updater described in Updating WebProCMS.

Click Go to Dashboard, log in, set your new password, and you're in. Next stop: First Steps After Installing.