Server profiles

A profile is the shape of a machine, written down once instead of typed out per server: which roles it serves, which tools it carries, how its database and its cache are tuned, and what a new WordPress site on it starts with.

You set a machine up from one:

root@new:~# corectl setup --profile wordpress

and you can move an existing machine onto one, which is where the interesting rules are.

What a profile decides

The lists are exact, not minimums. That matters most for what a profile leaves out: the WordPress profile has no mail role, and that absence is a decision, not an oversight.

The two profiles

root@web1:~# corectl profile list
Profiles:
     shared       Shared hosting — websites, databases, mail, DNS and FTP on one machine
  on wordpress    WordPress hosting — LiteSpeed with LSCache, Redis object cache, MariaDB tuned for InnoDB

This node carries wordpress. `corectl profile status` shows how far it has drifted.
Own presets go in /etc/corecp/profiles/<name>.yaml and win over the built-in one.

shared is the all-in-one machine: websites, their databases, their mail, their DNS and FTP, on one server. It tunes nothing, on purpose — a shared node hosts whatever your customers upload, and a setting that helps one of them at the expense of the rest is not a default.

wordpress is a machine that runs one kind of application, so it can be tuned for it:

• LiteSpeed with LSCache, so the cache sits in the web server in front of PHP;
• Redis with a memory ceiling and an eviction policy, so a plugin that caches every query cannot take the machine down;
• an InnoDB buffer pool sized to this machine instead of MariaDB's 128 MB default — this is the single biggest difference between a slow WordPress and a fast one;
• no mail role. A WordPress host is not a mail host. Sites send through a relay and port 25 stays shut.

A new WordPress site on such a machine gets the LiteSpeed Cache and Redis Object Cache plugins and has its object cache switched on for it. Page caching is turned on at the site rather than at the server on purpose: the server does not know which cookie means "logged in" and the cache plugin does, and a server-wide one-second cache is one plugin update away from showing a logged-in visitor's page to somebody else.

To read a profile in full, including why it makes the choices it does:

root@web1:~# corectl profile show wordpress
wordpress — WordPress hosting — LiteSpeed with LSCache, Redis object cache, MariaDB tuned for InnoDB
  source     built into corectl
  roles      web, db
  webserver  litespeed (lscache on)
  tools      composer, git, redis, wp-cli
  drop-in    mariadb (406 bytes, as rendered for this machine)
  drop-in    redis (39 bytes, as rendered for this machine)
  php policy max_input_vars max 30000
  wordpress  object cache redis, new sites get litespeed-cache, redis-cache
  note       Page caching is turned on at the *site*, not at the node. …

corectl profile show wordpress --yaml prints the preset exactly as it is written, which is what you copy to make your own.

Sizes come from the machine

The database and cache settings are not fixed numbers — they are a percentage of the RAM the server actually has, rounded to something a person would have typed:

root@web1:~# corectl profile status
profile   wordpress — WordPress hosting — LiteSpeed with LSCache, Redis object cache, MariaDB tuned for InnoDB
memory    3398 MB (what the profile's drop-ins are sized from)
drift     none — this node matches its profile

3398 MB gives a 960 MB buffer pool and a 320 MB Redis ceiling. Give the machine more memory and it does not resize itself — run corectl profile apply wordpress again and the settings are rewritten with the new numbers.

Changing a machine's profile

Always look before you leap. --dry-run changes nothing and tells you everything:

root@web1:~# corectl profile apply shared --dry-run

Adding is free. A switch that only adds a role or a tool goes through without asking anything.

Taking something away is not. Removing a role means breaking whatever needs it — mailboxes, DNS zones, databases, FTP logins — and a profile switch is not a migration. So CoreCP refuses, and the refusal tells you exactly what stands in the way and how to free each one:

root@web1:~# corectl profile apply wordpress
corectl: switching to profile wordpress would take the mail role(s) off this node, and 33 binding(s) still need it:
  mail      domain   example.nl (account acme)              corectl mail disable example.nl
  mail      mailbox  info@example.nl (account acme)         corectl mailbox delete info@example.nl
  mail      … and 27 more (19 domain, 14 mailbox in total)

Move them to another node first — that is what the panel's service bindings are for, and it keeps the data — or free them with the commands above, or pick a profile that keeps the role. Nothing on this node was changed.

There is no way to force it, and that is deliberate. The way past a binding is to move it — that is what the panel's server placement is for, and it keeps the customer's data. Nothing on the machine is touched by a refused switch: the server is exactly as it was.

If nothing is bound, taking a role off is fine. The rule is about bindings, not about direction.

A profile is a starting point, not a cage

You are free to change a machine after you have given it a profile. Nothing undoes what you did. What CoreCP does is tell you the machine and its profile have moved apart:

root@web1:~# corectl tool add node@24
root@web1:~# corectl profile status
profile   wordpress — WordPress hosting — LiteSpeed with LSCache, Redis object cache, MariaDB tuned for InnoDB
memory    3398 MB (what the profile's drop-ins are sized from)
drift     1 difference(s). A profile is a starting point: these are
          reported, never undone.

  tool        node@24                added    installed here, not part of the profile

Put the node back on its profile with: corectl profile apply wordpress

The same thing shows up in the health check as a warning, never a failure — a machine you deliberately gave an extra tool is not unhealthy:

root@web1:~# corectl doctor | grep profile
[warn] profile            wordpress — 1 difference(s): tool node@24 added — installed here, not part of the profile

And in the panel, on the server's page: the profile name with a badge saying either no drift or how many differences there are, with the list underneath.

Putting a machine back on its profile is something you ask for, and only then: corectl profile apply wordpress.

Writing your own profile

Your own presets live in /etc/corecp/profiles/ and win over the built-in one of the same name, so you can change what "shared" means on your fleet without waiting for us. Start from one that exists:

root@web1:~# mkdir -p /etc/corecp/profiles
root@web1:~# corectl profile show shared --yaml > /etc/corecp/profiles/shared-nl.yaml
root@web1:~# nano /etc/corecp/profiles/shared-nl.yaml

Change the name: field to match the file name — those two have to agree. Everything else is a list you can edit:

name: shared-nl
summary: Our shared platform, with Node for the deploy pipelines
roles: [web, db, mail, dns, ftp]
webserver: nginx_apache
tools: [composer, git, imapsync, node@24, redis, wp-cli]

Everything a profile names is checked before a single package is installed, and you are told about all of it at once rather than one mistake per attempt:

root@web1:~# corectl profile apply shared-nl --dry-run
corectl: profile shared-nl cannot be applied:
  role "mailserver" does not exist (backup, db, dns, ftp, mail, web)
  tool "kubernetes": unknown tool "kubernetes" — `corectl tool list` names the catalogue

Where to look next

• Tools on a server — what a tool is and how the list works.
• Config drop-ins — the settings a profile brings, and how to change one by hand afterwards.