The Web Server (CoreHttpd)

CorePanel does not ship Apache, nginx or LiteSpeed. Every site on the server — and the panel itself — is served by CoreHttpd, the web server CorePanel is built around.

Most of the time that is invisible: sites are configured from the panel and the server follows. This page is for the moments when it is not invisible — when you go looking for a vhost file that is not there, when a log is not where you expected it, or when you need to know exactly what the process serving your customers can and cannot read.

Three spellings, one thing

CoreHttpd is the product name. corehttpd is the systemd unit, the system user and the path prefix. corepanel-httpd is the RPM — the name to use with rpm -q or dnf.

What it replaces

If you have run a hosting server before, this table is the fastest way in. Nothing in the left column exists on a CorePanel server.

On Apache / nginx	On CorePanel
A vhost or server {} block per site	A site record in the panel; CorePanel writes the server’s config itself
httpd -t / nginx -t before a reload	Nothing to validate — there is no configuration language to get wrong
mod_rewrite, mod_deflate, mod_headers…	Built into the server; nothing to load
A third-party cache, WebP or minify module	Web optimizations, per site, in the panel
certbot, a renewal cron, a deploy hook	Automatic certificates, issued and renewed by the server
/var/log/httpd/*	/var/log/corehttpd/*, plus one access log per domain
The apache / nginx user, started as root	The corehttpd user, which is never root
.htaccess	.htaccess — still read, with a report of what was applied

There are no vhost files to edit

CorePanel does not render a configuration file for CoreHttpd to parse. It writes one JSON site record per site into /var/lib/corehttpd/sites/<domain>.json and signals the server to re-read them. Each file is written to a temporary name and renamed into place, so a half-written file is never read as live configuration, and the reload is a SIGHUP: no downtime, no dropped connections.

The practical consequence: those files are not yours to edit. They are regenerated from the panel’s database whenever anything about the site changes — a new alias, a PHP version, a certificate, a serving mode — and a hand edit is silently overwritten the next time that happens. Everything they contain has a control in the panel or in the CLI.

For anything that a single document root cannot express, the site record carries an ordered route table — that is what reverse proxy routes are — and that too is written by the panel.

It does not run as root

Apache runs as root. So do nginx and LiteSpeed: they start privileged, bind the low ports, and drop to an unprivileged user for the workers. CoreHttpd never has privileges to drop. It runs as the unprivileged corehttpd user from the first instruction, with exactly two capabilities granted by its unit:

Capability	What it is for
CAP_NET_BIND_SERVICE	Bind ports 80 and 443 as a non-root user
CAP_DAC_READ_SEARCH	Read any document root regardless of owner and mode

That second one is what lets account homes stay 0700 and account files 0600 with no POSIX ACLs anywhere. The traditional approach — granting the web server access with setfacl — is fragile, because tar, rsync, backups, restores and ordinary uploads all strip ACLs, so the panel has to keep reapplying them forever. CoreHttpd needs none.

The capability is read-only: it bypasses permission checks for reading and traversing, never for writing. And because it is broad, the real boundary is mandatory access control — CoreHttpd runs in its own SELinux domain, corehttpd_t, shipped as a policy module with the RPM. Not httpd_t: a domain scoped to what this server actually does.

# The web server should show corehttpd_t, not init_t or unconfined_t
ps -eZ | grep corehttpd

Do not disable SELinux, and do not add NoNewPrivileges

CorePanel expects enforcing mode; the confinement above is the read boundary. The unit deliberately does not set NoNewPrivileges — under it the kernel refuses the domain transition and the server keeps running unconfined, which is strictly worse than the hardening the option looks like it is adding. The same applies to any drop-in that implies it (ProtectKernelTunables, SystemCallFilter, RestrictSUIDSGID…).

Beyond that, the unit runs with ProtectSystem=strict and ProtectHome=read-only: the only paths the server can write are /var/lib/corehttpd and /var/log/corehttpd.

It also never executes PHP in its own process. PHP runs in a per-account PHP-FPM pool that CoreHttpd reaches over a Unix socket — see How PHP runs. A compromised web server is an HTTP front and nothing more; it cannot read a customer’s wp-config.php, because only that account’s pool ever opens it.

Protocols, ports and certificates

80/tcp	HTTP/1.1 — redirects to HTTPS where Force HTTPS is on
443/tcp	HTTP/1.1 and HTTP/2 over TLS
443/udp	HTTP/3 over QUIC, advertised to browsers with Alt-Svc: h3=":443"

HTTP/2 and HTTP/3 are on by default and need no per-site setting. Responses carry Server: CoreHttpd, which is the quickest way to confirm from outside which server answered:

curl -sI https://example.com | grep -i '^server\|^alt-svc'

Certificates are the server’s own job: it obtains them from Let’s Encrypt on demand, renews them before expiry, and prefers an uploaded commercial certificate over its own wherever one has been installed. SSL/TLS certificates covers both paths.

What it does that a stock server would need modules for

Each of these is part of the same request, in the same process, and each has its own page:

• Web serving modes — what happens to a path that is not a file
• Force HTTPS — per domain, applied only when a certificate exists
• Web optimizations — WebP conversion, Early Hints, minification, the dynamic page cache
• .htaccess support — the rules a site brings with it from cPanel
• Web application firewall — in the server, on every edition
• Reverse proxy routes — publish a local service under a domain
• Web traffic graphs — requests per minute and latency percentiles, from the server’s own counters

Where everything is

Path	What it holds
/etc/corehttpd.ini	The server’s own settings — see below
/var/lib/corehttpd/sites/	One JSON site record per site, written by CorePanel
/var/lib/corehttpd/	Writable state: certificate cache, WebP and minify cache, the host certificate, the GeoIP database, the WAF event store
/var/log/corehttpd/access.log	Server-wide access log
/var/log/corehttpd/error.log	Server errors — the first place to look
/var/log/corehttpd/users/<account>/<domain>.access.log	One access log per domain

Per-domain access logs live outside the account’s home and are symlinked into ~/logs, so the account can read its own traffic without being able to touch the file. All of them are also readable from the panel — see Reading logs.

Managing the service

systemctl status corehttpd            # is it up
systemctl reload corehttpd            # re-read site records, no downtime
systemctl restart corehttpd           # drops connections; needed after an .ini change
journalctl -u corehttpd -n 50 --no-pager
rpm -q corepanel-httpd                # the installed version

Reload is the normal operation and CorePanel performs it for you on every change; a restart is only for a change to /etc/corehttpd.ini.

There is no corehttpd --version

Running /usr/bin/corehttpd by hand starts a second server, which fails on the ports the running one already holds. Ask the package manager instead: rpm -q corepanel-httpd.

/etc/corehttpd.ini

This file is server-wide, and CorePanel manages what matters through the panel — a per-site setting is never in here. It ships with sensible defaults, it is commented, and most servers never need it touched. The keys worth knowing about:

Key	Default	What it does
EnableIPAccess	true	Keeps https://<server-ip> serving the panel with a self-signed certificate. This is the way back in when DNS breaks or the hostname’s certificate expires; set it to false to serve the panel by hostname only
MaxPostSizeMB	64	Ceiling on request body size, above any PHP limit
ProxyTimeout	60	Seconds a proxied route may take to respond
WafEventsRetentionDays	30	How long WAF events are kept for the security screens; 0 stops recording them
EnableDynamicCache	true	Box-wide gate for the page cache; false disables it whatever the sites say

A change here needs systemctl restart corehttpd. The configuration is read at start-up only — a reload re-reads the site records, not this file, so an edit followed by a reload leaves the server running with the old value and no error anywhere.

When something does not work

Work from the outside in:

1. Is the server up and were the ports left open? systemctl status corehttpd and ss -lntup | grep corehttpd. The installer opens 80 and 443; an empty result means something closed them afterwards — or that a cloud provider’s own firewall is in front, which CorePanel cannot see.
2. What did the server answer? The domain’s access log gives the status code, the path and the client. /var/log/corehttpd/error.log gives the reason.
3. A 404 on a path the application owns is almost always the serving mode, not the server.
4. A rule that used to work on Apache — check the per-site .htaccess report, which lists every directive that was not applied.
5. Certificate problems have their own path: see SSL/TLS certificates.