Create a PD Google Cloud PostgreSQL package in Blesta
Create a managed PostgreSQL offering after saving its Google Cloud connection. Saving the offering describes a future service; the intended activation process is what requests a real, chargeable instance.
Configure the offering
- Open Packages → Packages → Add Package.
- Choose PD Google Cloud PostgreSQL as the module and select the intended saved Google Cloud account.
- Set Region, Plan, Engine version and Storage (GB) in the module fields. This module’s engine scope is PostgreSQL.
- Review Resource name prefix and the client feature controls below. Set the package’s terms and your own pricing, then save it in the intended package group.
- When ready for sale, add that package group to the appropriate order form under Packages → Order Forms.
Start with the package’s fixed settings
The reviewed release uses a different Products workflow from the newer native option generator. Start with a package for the intended fixed combination of region, plan, version and storage. Obtain guidance for your installed build before adding manual customer-selectable dimensions; do not infer option keys from another platform.
A No customer options label describes the package’s option attachment. It does not prove that the fixed package cannot provision.
Review the intended service activation process. Eligible paid pending services depend on Provision Paid Pending Services automation; a manually activated service needs the intended staff action. Keep the normal cron and automation running. Saving a package or receiving payment alone does not prove that Google Cloud has created an instance.
Choose the database specification
Select the intended region, machine plan, engine version and starting storage. The module uses a maintained catalogue of choices; a listed choice is not confirmation of capacity, quota or every plan/version combination in your project. Confirm the intended configuration before opening the offering for orders.
Storage (GB) starts at a minimum of 10 GB in the module’s configuration. The module’s storage changes support increases, not reductions. Provisioning enables automatic storage growth, but this is not an unlimited-capacity or uninterrupted-service promise. Monitor capacity and growth costs; provider limits and workload spikes can still matter. Google explains the relevant instance storage settings.
The module’s provisioning model uses Enterprise, a single-zone instance and a public IP initially created with an empty authorised-network list. It does not offer regional high availability as a generated checkout dimension. Plan the application’s authorised source before expecting a direct public-IP connection.
Decide what clients can manage
Review Client: Firewall, Client: Connection details, Client: Users and Client: Databases. These govern the corresponding service controls. Enable the actions your offering supports. The database user’s password is separate from the Google service-account credential; customers should never receive the provider key.
Review any Client Area Section text before showing it to customers. Keep provider credentials and private operational details out of that text.
Verify the intended activation
PostgreSQL’s administrator password is prepared during background finalisation after the instance is available. An endpoint or running status alone does not establish that the displayed password is current or that application sign-in works. Confirm both the connection and credential through your normal authorised verification process before offering the service as ready.
If you use Blesta, have PD Modules support verify that your installed build saves the final administrator credential correctly before making the package available for customer activation. If the displayed credential fails, have the administrator responsible for your database instance reconcile it with the actual instance; do not repeatedly regenerate passwords or create another instance to diagnose it.
Preview the order form, effective resource choices and your own pricing. When ready, use your normal authorised provisioning test, recognising that it creates chargeable Google Cloud resources. Inspect Clients & Databases, Activity, the service state and the actual provider result. Keep the normal cron running for asynchronous progress.
A saved offering, a Ready options label or a passed connection test is not proof that the instance exists or accepts application connections. If the outcome is uncertain, reconcile it before repeating activation.
Do not send provider keys, database passwords or a full customer record.
See the PD Google Cloud PostgreSQL Blesta guide for related setup, or explore PD Google Cloud PostgreSQL.