PD Google Cloud MySQL for Blesta

PD Google Cloud MySQL lets a hosting company sell managed MySQL databases as its own product. Your customer orders on your Blesta order form, a dedicated Cloud SQL for MySQL instance is created in your Google Cloud project, and your customer runs it from your client area: connection details, an allow-list of trusted addresses, their own databases and users. Google bills you at cost, you set the price, and the difference is your margin.

It is built for hosts whose customers run WordPress, WooCommerce, Magento, Laravel and other MySQL applications and want a database that is not on the same server as their website. You get the product without building a control panel, and your customers never need a Google Cloud account.

Why hosts choose PD Google Cloud MySQL

A real database per order, not a shared one. Every order gets its own Cloud SQL instance and its own credentials. Nothing is shared between customers, and the instance is created in the region the customer picked at checkout, from more than 40 Google Cloud regions.

Sell the MySQL versions customers ask for. MySQL 8.4 is the default and MySQL 8.0 is available. Offer the version as a choice at checkout, or fix it per package. A blank setting uses 8.4, and the setting says so.

Orders set themselves up. A paid order creates the instance with no step from you. It is built in the background, and the connection details appear on the service page on their own once Google reports it running. A failed create shows Google's reason in the service's activity and is never left spinning as "creating".

Customers help themselves. Trusted sources, databases, users and password changes are all on the customer's own service page. That is most of the tickets a managed database normally generates.

Nothing left billing. Terminating a service deletes the instance and the module confirms it is gone. Termination completes even if your licence has lapsed, so a cancelled customer never stays on your Google bill.

Your Google account stays yours. The service-account key lives on your Blesta server, stored encrypted, and never appears on a customer page or message. Customers see your brand and your prices.

How it works

1. Connect your Google Cloud project. Create a service account with the Cloud SQL Admin role, add a Google Cloud account under Settings, Company, Modules with its JSON key pasted in, and press Test Connection. It makes one read-only call and changes nothing. If your Google organisation blocks key creation, Test Connection names the policy and gives the Console path and the gcloud command that lift it.
2. Create your package. Pick default region, plan, MySQL version and storage, then generate the package options in one click: Region, Plan, Engine version and Storage. Generated choices start at zero, so you set each price.
3. Your customer orders. They choose their options at checkout and pay. Blesta provisions the service once its invoice is paid, and the setup guide shows where to keep that task switched on. The instance is created and named with your prefix, and the customer sees a "being set up" message, never an error, until it is ready.
4. You get paid, they manage it. Blesta keeps billing as usual. Plan and storage upgrades go through Blesta's own upgrade flow.

What you get in Blesta

Selling and pricing

• Package options generated for you: Region, Plan, Engine version and Storage, linked to the package on Blesta
• Show or hide each option per package; anything hidden is fixed to your package setting
• Prices you set survive a sync; Rebuild from Google Cloud re-reads the catalogue and warns that prices return to their starting value
• Plans from the shared-core db-f1-micro and db-g1-small to db-custom vCPU and RAM sizes, chosen from a catalogue curated against Google's published lists
• Storage from 10 GB, sold as an option if you wish
• A name prefix for instances, so they read as yours; a blank prefix means "db"

Provisioning you can trust

• Running Create again never builds a second instance: the one already recorded is reused
• Plan upgrades and downgrades resize the instance in place and keep the data; storage grows in place, and a smaller size is refused
• A plan and storage change made together applies both
• Changes to one instance run one at a time; a change asked for while another applies is told to try again in a minute
• Suspend stops the instance and keeps the data, and a suspension that arrives while Google is busy is queued, not dropped. Google still bills storage while an instance is stopped; terminate to stop all billing
• An instance deleted outside Blesta is detected and flagged to you, and your billing is never changed by it

Running it day to day

• Clients and Databases: every provisioned instance against its service, with its state
• An activity log of provisioning, upgrades and password resets, each with its outcome
• Read-only assistant tools that report a service's instance, engine, version, size, region and state, list your databases newest first and show recent provisioning. They cannot create, resize, delete or restore anything

What your customers get

On the service page in Blesta's client area, a menu gives them Information, Trusted Sources, Users, Databases and Activity.

• Connection details ready to copy: host, port 3306, the root login, a password they can show or copy, and a mysql command. Connections can use SSL/TLS
• Trusted sources: a new instance accepts no connections until the customer adds an address. They manage the list themselves, an invalid entry is refused with a message, and changes apply within a minute
• Their own databases created and dropped from the client area, with system databases protected
• Their own MySQL users with a password they choose, with the admin login and system accounts protected
• A new root password in one click, shown in the connection details
• Recent activity in plain words, each action with its outcome
• Confirmation first: destructive actions ask in an in-page dialog

Every customer section is a switch on the package: Firewall, Connection details, Users and Databases. Turn one off and it is hidden and refused by the server. The pages render natively on the Blesta client theme and are fully translatable, with wording overrides that survive updates. An optional section of your own HTML can sit on the overview page.

Every instance is created with automated daily backups and point-in-time recovery switched on. Restores are done by you in the Google Cloud console; customers ask you.

Security built in

• Your Google key is stored encrypted on the module account and is never shown to a customer.
• Each database password is stored encrypted and shown only to the signed-in owner of the service.
• Customer actions need a signed-in owner and a valid security token.
• When something fails on your side, such as a missing role or an organisation policy, the customer gets a neutral message and the detail goes to your activity log.
• Customers' data, credentials and connection details are never sent to us. The module only calls Google's Cloud SQL Admin API and the licence check.

One product, every feature

PD Google Cloud MySQL is one paid module with everything included: provisioning, trusted sources, databases, users, upgrades and teardown. There are no add-on tiers to compare and no per-instance fees to us. You pay Google at cost and keep the margin. It adds its own tables and templates, does not modify Blesta files, and uninstalls without leaving orphans.

If your subscription ever lapses, your customers' databases keep running: it never stops, deletes or alters an instance. New provisioning and your management screens are withdrawn while read-only visibility stays, and everything returns when you are in good standing again.

Requirements

• Blesta 6 or later on PHP 8.2 or later, with the ionCube Loader
• A Google Cloud project with billing and the Cloud SQL Admin API enabled, and a service-account key with the Cloud SQL Admin role
• PD Modules, the free control panel every PD module installs into