The servers under your client sites, looked after.
Linux, cPanel, Apache and Nginx. Security patches, PHP upgrades and certificates, planned and approved first. Every change is proved from what the server actually serves, before and after.
The server jobs agencies hand us.
The site is only as safe as the server under it. These are the requests we see most.
| The job | What it covers |
|---|---|
| Apply a security patch | Update a server when a security fix is released, and check that it reached every site. |
| Move to a newer PHP | Change the version of PHP, the language most sites run on, for one site or a whole server. |
| Check against a new flaw | Find out whether a published flaw affects a server, and whether the update really fixes it. |
| Keep certificates renewing | Find out why a site's free certificate stopped renewing and put it right. |
| Look after a cPanel server | cPanel is the control panel many hosts use. Check its licence, its PHP versions and its logs. |
| Answer a security questionnaire | Describe how a server is set up from what it really answers, not from old notes. |
The Orchestrator on a server.
A project agent works on one client's servers. It plans, you approve, and it finishes with proof from the pages the server really serves.
A dry run first, then a plan you approve.
Before a patch, the agent lists every service that runs PHP and simulates the update to see what it would install. You read the plan, with its risk, and approve it before anything on the server changes.
- Every service that runs PHP listed, not only the obvious one
- The update simulated before it is run
- Nothing changes until you approve
Northgate client · Server patch
Project agent · Servers
PLAN
- List every service that runs PHP.
- Simulate the update and read what it installs.
- Record status and page size for every site, twice.
- Apply the update and restart each service.
RISK: medium · restarts PHP for every site
Proof from what the server serves.
A command that says "done" is not proof. After the change the agent reads each site's page and compares it with the baseline it took before. The baseline is taken twice, so a value that changes on every visit is not mistaken for a fault.
- Status and page size for every site, before and after
- The PHP version read from each site's own response
- On one real server, 13 of 41 sites carried a security token that changes on every visit. One baseline would have shown 13 false failures.
Example based on a real job, details changed.
After the update
Complete- Acme client · shopMatches baseline
- Hale client · classesMatches baseline
- Larch client · home pageMatches baseline
PHP version read from each response: new build
Lessons from real server jobs, built in.
The agent starts from our playbooks for cPanel, PHP and Linux security fixes. Each one is corrected from jobs we have done, so known traps are written down before you meet them.
- Playbooks for cPanel, PHP and Linux security fixes
- Every mistake written up with what to avoid next time
- Corrected every night
cPanel playbook · notes
- A lapsed licence fails quietly in many places
- Few open ports does not mean the control panel is hidden
- The panel's own log shows who really got in
Webgentic for sites does not do server work.
It changes the pages of one site and nothing under it. Server work is Orchestrator work, because it needs a plan you approve first.
| Webgentic Orchestratorfor teams | Webgentic for sitesfor single sites | |
|---|---|---|
| Server work | Yes. Patches, PHP versions, certificates and cPanel. | No. It changes the pages of one site. |
| Where it works | Linux servers, including cPanel servers, running Apache or Nginx. | One site, through a request bar. |
| Before a change | A numbered plan that you approve. | A plan first, then the change appears as it is made. There is no approval step. |
An Orchestrator job, start to finish.
A PHP security fix is out, and one server holds many customer sites. Here is how the Orchestrator handles it.
Brief
The Northgate client hosts 25 customer sites on one server. A PHP security fix is out, and the agency wants it applied with no surprises.
Plan
The agent lists every service that runs PHP and simulates the update. It records status and page size for every site, twice.
Approve
You read the plan, its risk and its way back, and approve it. Nothing on the server has changed yet.
Deliver
The agent applies the update and restarts each service that runs PHP.
Prove
It reads the PHP version from each site's own response. One hand-made service, serving 25 customer sites, still ran the old version (8.2.33) while the server reported the new one (8.2.35). That service was then restarted and checked again.
What our server playbooks cover.
Each topic was learned on a real job and written down, so the next agent starts from it.
- Applying a security fix on the day it is released
- Which software source has the fix yet
- Making sure every service that runs PHP was restarted
- Reading each site's PHP version from its own response
- Changing the PHP version for one site on cPanel
- What a lapsed cPanel licence breaks quietly, from certificate renewal to log rotation
- Whether the control panel is really hidden from the internet
- Checking a server against a new Linux flaw, and when a kernel update does not fix it
- Why automatic updates can skip a PHP fix
Questions agencies ask about servers
Does Webgentic for sites do server work?
No. It changes the pages of one site. Server work is done by the Orchestrator, with a plan you approve first.
Will a site go down while the server is updated?
A restart can interrupt visitors for a short time. The plan names every service that restarts, so you can choose the moment.
How does it know a change worked?
It reads what the server really serves: the status and size of each page, and the PHP version in the site's own response, before and after. A command that says it worked is not treated as proof.
Which servers does it work on?
Linux servers, including cPanel servers, running Apache or Nginx. It has playbooks for cPanel, PHP and Linux security fixes.
Can it patch a server nobody has looked at in years?
It starts by reading what the server is really running, not the old notes. A badly out-of-date server gets its own plan, rather than being folded into a security fix.
Do we have to hand over access to every server?
Only the servers you want us to work on. We map your clients, platforms and access on the scoping call. Each project agent uses only the access for its own project, inside its own sandbox, and you approve every plan, including when a restart happens.
Something else on your mind?
Ask us directly and a developer will reply.
Ask a question
Bring us the servers nobody wants to patch.
Join the waiting list. When your place comes up, we will show you the Orchestrator running on one of your real jobs in the first call.