Skip to content

WordPress, applications and WAF

These three sections cover what runs on a customer’s sites and what protects them. WordPress is handed over in full, Applications is split between you and the customer, and the WAF is something they can watch but not configure.

What the customer gets. The whole WordPress Manager for their own sites, with nothing removed: install or adopt a site, open wp-admin with a one-time link, update, harden, check integrity, toggle maintenance and debug, and manage restore points.

The limits are the same as yours: installs per account and stored restore points per account.

Two notes for support:

  • Install asks for a domain by name. Anything that is not theirs is refused, so a typo is an error, not an install in the wrong place.
  • Detaching is not deleting. The site leaves the managed list but its files stay; a rescan adopts it again.

The one section split between you and the customer.

Yours: creating, changing and deleting an application — the program it runs, its memory and CPU, where it is published and its CI deploy token. The customer never sees those buttons.

Theirs: everything afterwards.

  • Deploy a .tar.gz (upload or from their home). A release that does not answer is rolled back automatically.
  • Roll back to an earlier release, start, stop, restart, and read the journal.
  • The environment — add, change, remove and reveal variables. Reveals are audited.

One application open in the client panel: the header "api", tagged RUNNING and published at corepanel.io/api, with Deploy, Stop and Restart at the right — and no Edit or Delete. Below it the specification read-only (start command ./server --addr unix, limits 512 MB · 100% CPU · 128 tasks, outbound network "Internet and DNS", health path /healthz), a "System status" card giving the unit, active state, main pid and restarts as systemd reports them plus a Health check reading "Answering", and a "Releases" table of three releases, the newest tagged ACTIVE and the two older ones each offering "Roll back".

Size it with your disk in mind. Releases unpack under /opt/userapps/, outside the account’s quota. Each application keeps up to four releases of up to 8 GiB each, so the worst case per account is that times its Applications allowance. An allowance of 0 means none, and the section says so.

What the customer sees. The WAF activity on their own sites: blocked and detected counts, a per-day chart, top attacking addresses and countries, the protections that fired, and the latest events with the full request. In icon view it is under Security, and a banner on the home page shows the month’s blocked attacks.

The WAF screen of the client panel, with WAF highlighted in the sidebar: the heading "WAF" over the line "Attacks the firewall stopped before they reached your sites", a site selector reading "All my sites" and a 7D/30D/90D range switch, then three cards — 322 blocked, 43 detected (logged, not blocked) and a last activity of 19 minutes ago over 365 threats seen. Below them the Attack radar, a stacked bar per day of blocked (amber) and detected (grey) threats across a month. At the bottom three cards begin: Top attackers listing client IPs with a country flag and when each was last seen, "Where they came from" ranking countries, and "What they tried" naming the protections that fired — SQL injection attempt in POST, XSS injection attempt in headers, wp-login POST without Referer.

Cloudflare is the one setting they control. At the bottom of the page, a customer whose site is behind Cloudflare sets it to On, so the firewall, the logs and PHP see their visitors instead of Cloudflare’s addresses. Hosting default follows what you set server-wide in WAF › Proxies, which you can also override per site.

The bottom of the client panel's WAF screen: the last rows of Recent activity, then a "Cloudflare" card explaining "Turn this on if the site is behind Cloudflare, so the firewall and your logs see your visitors instead of Cloudflare. Leave it off otherwise", a site selector reading corepanel.io, and a three-way switch — Hosting default (off), On, Off — set to On.

What stays with you. Everything else that configures the WAF: protection packages, rule toggles, exceptions, trusted IPs and proxies. A customer cannot switch a rule off for themselves.

The event reference is how they report a false positive. Every event carries one, such as WAF-1284391, copyable with one click. Paste it into the Reference field of your event log to land on that exact request, then write the exception.

The event detail dialog open over the customer's Recent activity table. Its header reads "Event detail" beside the reference WAF-4205 with a copy icon, and a BLOCKED badge. The body gives the target api.startup.dev with a timestamp, a Network block (remote IP 192.140.58.88, country BR, rule LFI-002 "Local file inclusion"), the request line GET /index.php?page=/etc/shadow, a Query parameters table decoding it to one row (page = /etc/shadow), the four captured headers including a masscan User-Agent, and an empty body. The footer offers only Close — no "Add exception".