PD Google Compute Engine for Blesta

PD Google Compute Engine lets a hosting company sell Google Cloud virtual machines as its own cloud server package. Your customer orders in your Blesta order form, a dedicated server is built in your Google Cloud project when Blesta activates the service, and your customer manages it from your client portal: a control panel in your brand that never names Google in its own words. You set the price, Google bills you the cost, and the difference is your margin.

It is built for hosts who want to offer cloud servers on Google Cloud without building a control panel, without giving customers access to the Google Cloud console, and without a support ticket every time a customer needs a reboot or a firewall rule.

Why hosts choose PD Google Compute Engine

Sell cloud servers under your own brand. Your customers see your company, your prices and your client portal. They never see your Google Cloud account, key or console, and there are no per-server fees to us: you pay a flat module subscription and Google bills your own project.

Every order sets itself up. The server is built when Blesta activates the service, with the zone, machine type and operating system the customer picked on the order form. It is running with its control panel within a minute or two, with a reserved static IP and its own firewall rules already in place.

Customers help themselves. Power controls, connection details, snapshots, extra disks, a firewall, SSH keys, a boot and console log, usage graphs and an optional in-browser terminal are all on the customer's own service page. That is most of the tickets a server product normally generates.

Problems caught before they cost you. A machine type that a zone cannot build is refused before anything billable is created. An order whose region lacks the vCPU quota is refused with a guided "request an increase" message, and a missing role or blocked policy is named with its fix.

Nothing untracked, nothing left billing. Every server is recorded before Google is asked to create it, so a server can never exist without an owner. Cancelling a service deletes the VM and its boot disk, removes its firewall rules, snapshots and extra disks, releases its static IP, and confirms at Google that everything is gone.

A stopped server is not a destroyed one. If a client's invoice lapses their server is stopped, not destroyed, and it returns once they pay.

How it works

1. Connect your Google Cloud project. Create a service account with the Compute Admin and Service Account User roles and paste its key into a module account under Settings, Company, Modules. Test Connection makes read-only calls only, names which role is missing, tells you if the Compute Engine API is not enabled and how to turn it on, and shows your vCPU quota in the default region.
2. Create your packages. One click generates the order options (region and zone, machine type, operating system, boot disk size and snapshots you can keep) from the live Google Cloud catalogue. You set the price of each and choose which ones customers see.
3. Your customer orders. They choose their options on the order form and pay. The server is built with a reserved static IP, a firewall and a ready-to-use SSH key.
4. You get paid, they manage it. Blesta keeps billing as usual. A plan change through the normal upgrade flow resizes the server in place and keeps its data.

What you get in Blesta

Selling and pricing

• Order options generated from Google Cloud: region and zone, machine type, operating system, boot disk size and the number of snapshots a customer can keep
• Machine types read live from Google Cloud, in regions on every continent
• Debian 12 and 13, Ubuntu 22.04 and 24.04 LTS, Rocky Linux 9, AlmaLinux 9 and CentOS Stream 9, each the latest image of its family
• Choose which options customers see; anything you hide is fixed to your package's setting, and rebuilding keeps what is hidden and what customers already chose
• A boot disk size setting per package (10 GB minimum), or let customers buy a size as a priced option
• A customer can give their own SSH public key on the order form, and your team's master key can go on every new server

Provisioning you can trust

• Every plan a customer can pick can be built in the zone they pick
• When Google refuses a server, the order is reported as failed with the reason
• A suspended server is powered off with its data and configuration intact, and powered back on with the same IP when unsuspended. The customer's status banner says plainly that a stopped server still bills its disk and reserved IP
• Plan changes are applied in place: stop, change machine type, start, with the data preserved. A refused type leaves the server as it was and says so
• A boot disk upgrade grows the disk online without touching data; the disk never shrinks

Running it day to day

• Clients and Servers: every server against the client paying for it, with its state
• A full, readable activity history: creation, power actions, reinstalls, plan and disk changes, snapshots, firewall and SSH key changes

What your customers get

• Power on, shut down and reboot, with the page telling them a reboot is a hard reset before they confirm
• Connection details: the static IP and a ready-to-copy ssh command, with a one-click download of the server's generated key
• A firewall they manage themselves: add or remove rules by protocol, port or range and IPv4 source, applied within a minute. Anything not allowed is blocked
• Snapshots they title, take, restore and delete, up to the allowance they bought. Restoring keeps the static IP and their keys
• Extra disks (SSD, balanced or standard) they create, attach, detach and delete; detaching keeps the data
• Their own SSH keys, added and removed at any time and reaching the running server within a minute. Password login is disabled
• Reinstall from a fresh copy of the original operating system, behind a typed confirmation, keeping the static IP and keys
• A boot and console log they can read, read-only, to diagnose a server that will not start
• Usage graphs for CPU, network and disk over the last six hours
• An in-browser terminal, off until you switch it on, with no SSH client to install
• Activity: a timeline of everything that happened to the server

Every one of these is a switch on the package. Turn one off and it disappears from the customer's page, and the server refuses it too. The pages appear as tabs of the service in Blesta's client portal, follow its theme and are fully translatable, with wording overrides that survive updates.

Security built in

• Your service-account key is stored encrypted on your own server, used only server-side, and never appears on a customer page. Servers accept SSH keys only, and a server's keys are removed with it.
• The in-browser terminal is off until you switch it on, at the module and on each package. Only the signed-in owner of a service can open it. Each session is single-use and expires within a minute, and nothing inbound ever reaches your Blesta server.

One product, every feature

PD Google Compute Engine is one paid module with everything included: provisioning, power, snapshots, disks, firewall, console log, metrics, upgrades and the browser console. There are no add-ons or tiers to compare. It installs into PD Modules in one click, updates itself, and uninstalls cleanly without modifying any Blesta files.

If your subscription ever lapses, your customers are not cut off. A lapse never stops, deletes or alters a customer's server: it keeps running in your Google Cloud project throughout. Customers keep managing their servers until the subscription is suspended. New provisioning and admin configuration stop when it expires, and the browser console goes dark, though customers can still use their own SSH client.

Requirements

• Blesta 6 or later on PHP 8.2 or later, with the ionCube Loader
• A Google Cloud project with the Compute Engine API enabled, and a service account with the Compute Admin and Service Account User roles
• PD Modules, the free control panel every PD module installs into