KeyHelp: manage the KeyHelp hosting panel and install ProcessWire sites from ProcessWire Admin

[maximus]

Hi everyone,

I have released a new ProcessWire module: KeyHelp.

KeyHelp is a ProcessWire admin module for working with KeyHelp, a German hosting control panel. It brings common KeyHelp hosting tasks into ProcessWire Admin, and it can also install fresh ProcessWire sites directly on KeyHelp domains.

Repository: https://github.com/mxmsmnv/KeyHelp

What it does

The module adds a dedicated KeyHelp section in ProcessWire Admin where you can:

• view a hosting dashboard with server status and resource counts;
• browse and manage domains, clients, databases, email accounts, FTP users, SSL certificates and cron jobs;
• update per-domain SSL, Let's Encrypt, HTTPS redirect, HSTS, PHP version and DNS records;
• open KeyHelp database tools / phpMyAdmin links from ProcessWire;
• view server information, software versions, resources and service status;
• cache KeyHelp API responses and flush the cache manually;
• enable sanitized debug logging;
• use English or German UI text;
• restrict the module to one KeyHelp client in single-tenant mode.

Screenshots

 

 

ProcessWire installer

The installer can create a fresh ProcessWire site on a selected KeyHelp domain.

It can:

• download the stable or dev ProcessWire archive;
• unpack it into the domain document root;
• create a KeyHelp database and database user;
• generate a random admin URL and strong credentials;
• run the ProcessWire CLI installer;
• adapt Apache configuration for KeyHelp;
• store generated credentials encrypted with the ProcessWire site salt;
• show a ProcessWire badge and credentials on the domain detail page.

It supports both local installs and SSH remote installs, so the ProcessWire admin site and the KeyHelp hosting server do not have to be the same machine.

There is also a GitHub module installer for already installed ProcessWire sites. It checks the target installation, downloads a GitHub repository archive, validates PHP syntax and copies the module into /site/modules.

Requirements

• ProcessWire 3.0.200+
• PHP 8.0+
• PHP curl extension
• KeyHelp REST API access
• KeyHelp admin API key

The module targets KeyHelp API 2.14 and /api/v2 endpoints.

Permissions

The module adds granular ProcessWire permissions:

• keyhelp-view
• keyhelp-edit
• keyhelp-delete
• keyhelp-server

Superusers always have access.

Notes

This is the first public release, so feedback is very welcome, especially from anyone using KeyHelp in production or testing ProcessWire deployment workflows.

I built it because I wanted to manage hosting operations from inside ProcessWire instead of switching back and forth between the CMS and the hosting panel. The installer is also meant to make it easier to spin up ProcessWire sites on KeyHelp domains.

German documentation is included in the repository.

Author: Maxim Semenov
Website: smnv.org
Repository: github.com/mxmsmnv/KeyHelp

[maximus]

How KeyHelp for ProcessWire was built: from a phone idea to a tested module

I have been building modules for ProcessWire for a long time, but this one had a slightly different origin story.

KeyHelp started not as a carefully planned “module project”, but as a practical question while I was away from my computer:

What if ProcessWire could manage a hosting panel directly from the admin area?

The initial research happened on my phone. I was looking at how other systems handle hosting integrations, especially WordPress. WordPress has a huge ecosystem around this: hosting panels, one-click installers, backup plugins, deployment tools, billing integrations, and managed hosting workflows. Panels like HestiaCP, FastPanel, CyberPanel and CloudPanel all have their own approaches to WordPress automation.

That made me think about ProcessWire.

ProcessWire is a very strong developer CMS, and I have built modules for it for years, but hosting operations usually still live outside the CMS: domain setup, databases, SSL, PHP versions, DNS records, FTP accounts and cron jobs. For editors and site owners, that means switching between the CMS and the hosting panel. For developers, it means repeating small operational tasks that could probably live closer to the project.

The research then moved toward German hosting panels. I used Google Gemini on my phone to explore that landscape. The conversation started around hosting panel integrations, WordPress automation, CloudPanel, CLI/API wrappers and then German panels specifically. KeyHelp stood out because it is widely used in the German hosting world and has a REST API. I also looked at the broader German ecosystem: LiveConfig, Froxlor, older i-MSCP setups, and custom panels from German hosts like All-Inkl and Mittwald.

That context mattered, because KeyHelp is not just “another control panel”. It belongs to a hosting culture where stability, server control and GDPR-friendly infrastructure matter.

After that research, I moved to Claude on my phone for the first implementation attempt.

The first prompt was essentially:

Need build integration module with KeyHelp web panel for administration Webserver inside PW

Then I defined the first scope:

• Domains: create, delete, list
• Clients / users
• Databases
• Email accounts
• SSL / Let’s Encrypt
• PHP settings
• DNS records
• A ProcessWire admin dashboard with server status, domains and database widgets
• API access through a KeyHelp admin key

Claude produced the first module draft. It created the initial structure with a module file, assets, views, dashboard, domain list, create forms, SSL/PHP/DNS screens, client views, database screens and basic cache/API handling.

But the first version was too monolithic.

So the next correction was immediate:

Do not make it a monolith. Put the settings into the module. Where is the Process module?

That changed the architecture. The module was split into:

• KeyHelp.module.php for configuration, API client, cache, debug logging and module settings
• ProcessKeyHelp.module.php for the ProcessWire admin UI
• later, multiple traits under src/ProcessKeyHelp/
• views under views/
• CSS/JS and Remix Icon SVG assets under assets/

That was the first important turn: not just “make something that works”, but make it feel like a real ProcessWire module.

Claude also helped shape the first permission model. The early version was basically superuser-only, but it became clear that a real module needed ProcessWire permissions. The model became:

• keyhelp-view
• keyhelp-edit
• keyhelp-delete
• keyhelp-server

So even before the heavy testing phase, the direction was already moving from “prototype” to “proper ProcessWire admin module”.

When I got home, I saved the generated module, opened the module folder in Codex, and the real work began.

At that point I also decided to buy a fresh Hetzner test server specifically for this module. That turned into its own small side quest: I had to create a Hetzner account, go through identity verification, take a photo of my government ID / driver license, take a selfie, submit everything, and wait for approval before I could even create the server.

Only after that could I create the VPS, install KeyHelp, connect it to a real domain, create an API key and start testing the ProcessWire module against a real hosting panel.

The server uptime later showed:

17h 12m

That became a nice marker of the whole process. This was not just a fake UI built against assumptions. There was a real KeyHelp panel, a real API key, a real ProcessWire installation, and a real remote server used specifically to test the integration properly.

The first real problem appeared immediately in ProcessWire:

Cannot reach KeyHelp API: cURL: Could not resolve host: key.smnv.org

That led to the first practical improvements in Codex:

• API URL handling;
• API access notes;
• SSL verification settings;
• DNS resolution override;
• better module configuration hints;
• safer debug logging.

The KeyHelp panel showed API version 2.14, so the implementation was aligned with the KeyHelp REST API docs.

From there, the module became a loop of implementation, browser testing, corrections and UI review.

This was the main Codex phase.

I had Chrome open with two real things side by side:

• the KeyHelp panel on the test server;
• the ProcessWire admin module running on my site.

Codex was editing the module files locally, and I was checking the result in the browser. I asked it to click through pages, inspect forms, open tabs, check GET/POST behavior, test UI states, and compare the result with what I saw.

The module was tested in Chrome and in the in-app browser across:

• dashboard
• domains
• domain view
• SSL tab
• PHP tab
• DNS tab
• clients
• databases
• email
• FTP
• SSL certificates
• cron jobs
• installer
• server page
• module settings

A lot of the work was not glamorous. It was small things that make a module feel real:

• tabs did not work correctly at one point;
• buttons had unwanted underlines;
• Font Awesome icons were jumping because more than one icon set was involved;
• icons were replaced with Remix Icon SVGs;
• tables were too custom and started hiding API data;
• badges were too small;
• breadcrumbs were inconsistent;
• some titles and breadcrumbs were not translated;
• German labels were missing in places;
• uk-table-small, uk-margin-remove, kh-mono and other styling leftovers had to be removed;
• dashboard and server screens needed better information layout;
• module settings needed better UI/UX;
• slow API pages initially felt frozen, so lazy background loading was added.

This is where the human + AI workflow was useful.

Codex would implement a change. Then I would look at the browser and say things like:

• “the tabs are broken”
• “what happened to the design?”
• “why is there a big left gap?”
• “the icons jump”
• “this table is wrong”
• “the German version still says Refresh”
• “this should look like Ichiban”
• “remove custom table styles”
• “don’t use Font Awesome”
• “test this in Chrome”
• “go through all tabs yourself”

Then Codex would inspect the code, patch it, test again, and refine the result.

There was also a strong UI direction: the module should not look like a random SaaS dashboard. It should feel like a ProcessWire admin tool. Dense, calm, useful, and close to the Ichiban / AdminThemeUikit style. No decorative landing page, no marketing hero, no unnecessary cards inside cards.

The installer became the biggest feature.

The goal was:

From ProcessWire Admin, choose a KeyHelp domain, choose ProcessWire stable or dev, and let the module install ProcessWire there.

That meant the module needed to:

• resolve the domain document root;
• support the case where KeyHelp and ProcessWire run on different hosts;
• support local and SSH remote deployment;
• download the ProcessWire archive;
• unpack it;
• create a KeyHelp database and database user;
• generate a random admin URL;
• generate secure credentials;
• run the ProcessWire CLI installer;
• adapt Apache configuration for KeyHelp;
• remove installer files;
• store credentials securely.

At first, the installer assumed the document root was visible locally. That was wrong for real deployments. The KeyHelp panel can be on one server and the ProcessWire admin module on another. So the installer had to learn the difference between local filesystem and remote SSH deployment.

That was a very important correction. The module should not only work on my local setup. It should handle the realistic case where the ProcessWire admin site and the KeyHelp hosting server are separate machines.

Then came another important question:

After ProcessWire is installed, where are the generated credentials stored?

The answer became: in a module-managed table, encrypted using the ProcessWire site salt. The domain list now shows a ProcessWire badge when an installation is known, and the domain detail page can show stored admin URL, admin login and database credentials to users with the right permission.

There is also a GitHub module installer for already installed ProcessWire sites. It checks whether ProcessWire exists in the target path, downloads a GitHub repository archive, validates PHP syntax, and copies it into /site/modules.

The server page also evolved during testing.

At first it was too raw. Then it became a proper admin view with:

• server information;
• software versions;
• resource usage;
• services;
• server reboot action;
• links back to KeyHelp where the API does not expose something.

A specific note was added because the KeyHelp REST API does not expose start/stop/restart endpoints for individual services. Server-level reboot is available through POST /server/reboot for KeyHelp 26.0+.

Debugging support was added too. The module can log sanitized API requests, payloads, responses, cache hits and timings to keyhelp-debug, while redacting sensitive values like API keys, passwords, tokens and secrets.

One of the important late-stage changes was performance. Some KeyHelp API calls could take many seconds. At one point Tracy showed pages taking a long time because data was being fetched directly before the admin page rendered. That is bad UX: it makes the admin feel frozen.

So the module was changed so slow API-backed pages render an admin shell first, then load data in the background. The user sees that the page is alive, and the data fills in when ready.

The module also gained English and German UI support. Since KeyHelp is a German hosting panel, German translation was not just a nice extra. It made sense for the module’s audience.

The documentation evolved during the same process:

• README was rewritten in a release-ready style;
• German documentation was added;
• CHANGELOG was made first-release friendly with only an Added section;
• sponsorship metadata was added;
• version was set to 100;
• AGENTS.md was added so future AI agents understand how to work with the module, what not to touch, how the installer works, what API calls exist, and how to test safely.

Near the end, the repository was cleaned up:

• the monolith was split into src/, views/ and assets/;
• tests were kept local and ignored;
• unused generated image assets were removed;
• README was kept version-free;
• the GitHub branch was recreated using an orphan commit so the public repository starts cleanly with one init commit.

The final result is not only a KeyHelp API wrapper.

It is a ProcessWire admin integration for a German hosting panel, with a real installer workflow for creating ProcessWire sites on KeyHelp domains.

The full path looked roughly like this:

1. I researched hosting integrations and German panels with Google Gemini on my phone.
2. I used Claude on my phone to create the first KeyHelp module prototype.
3. I corrected the architecture so it became a real ProcessWire module pair instead of a monolith.
4. I created a Hetzner account and went through ID/selfie verification.
5. I bought a fresh test server specifically for this module.
6. I installed KeyHelp on the server.
7. I saved the generated module locally.
8. I opened the module folder in Codex.
9. I connected the module to the real KeyHelp API.
10. I tested the UI and API workflows in Chrome.
11. I repeatedly corrected UX, tables, icons, tabs, translations and layouts.
12. I added the ProcessWire installer.
13. I added SSH remote deployment.
14. I added encrypted credential storage.
15. I added GitHub module installation for existing ProcessWire sites.
16. I added lazy loading for slow API pages.
17. I cleaned up README, German docs, CHANGELOG and release metadata.
18. I published the repository as a clean orphan init commit.

This is what I found interesting about the process: the AI did not replace testing or product judgment.

Gemini helped with research and context. Claude helped create the first prototype. Codex helped turn it into a tested module by repeatedly editing code, running checks, using Chrome, and reacting to very specific feedback from the real UI.

The quality came from the loop: build, open in browser, click, notice what feels wrong, fix, test again.

The test server uptime, 17h 12m, is a funny detail, but it captures the mood of the whole thing: a fresh server bought just to make sure this module was not theoretical.

Repository: https://github.com/mxmsmnv/KeyHelp