PD Azure PostgreSQL for Blesta

PD Azure PostgreSQL lets a hosting company sell Azure Database for PostgreSQL, Microsoft's managed PostgreSQL service, as its own database package. Your customer orders and pays, a dedicated PostgreSQL server is built in your Azure subscription, and your customer manages it from the Blesta client portal: connection details, an allowed-address list and their own databases, with no Azure portal and no mention of Microsoft. You set the price, Azure bills you the cost, and the difference is your margin.

It is built for hosts whose customers run applications that need a serious relational database: Django, Rails and Node.js back ends, SaaS products, reporting and analytics workloads, and software that lists PostgreSQL as its preferred engine. Those customers choose PostgreSQL deliberately, and want a managed one from a provider they already pay.

Why hosts choose PD Azure PostgreSQL

The versions customers ask for. Sell PostgreSQL major versions 14 through 18, with 17 as the default, chosen at checkout or fixed per package. A customer starting a new project and one holding to an older release can both be served from the same product. Plans span the Burstable, General Purpose and Memory Optimized tiers.

Customers choose where it lives. Offer 30 or more Azure regions worldwide, so data can sit near the application or inside the customer's own country. A region your subscription cannot create PostgreSQL servers in is refused in plain words before anything is created.

Every paid order sets itself up. Blesta adds a new order as pending and provisions it once the invoice is paid, through its Provision Paid Pending Services task. The module builds a dedicated Flexible Server inside its own resource group, with the plan, storage, version and region the customer picked. Provisioning runs in the background with a progress state, and the connection details appear on their own once Azure reports the server ready.

Isolated by design. Each service has its own server and its own resource group. Nothing, not the server, the credentials nor the access rules, is shared between customers.

Disks that do not fill up. Storage starts at 32 GB and auto-grows before the disk fills, so a full disk never takes a customer's database down. Storage upgrades grow online without touching data.

Nothing left billing. Terminating a service deletes its whole resource group, the server, its rules and its databases, and the module confirms the group is gone. A termination completes even if your own subscription has lapsed, so a cancelled server never keeps billing.

How it works

1. Connect your Azure subscription. Register an app in Microsoft Entra with the Contributor role. Under Settings, Company, Modules, open the module, add an account and paste the credential once; it is stored encrypted. Test Connection checks the sign-in, that the app can read the subscription and that the PostgreSQL resource provider is registered, and shows the exact fix if it is not. Nothing is created.
2. Create your package. Choose the module and the account, then set a default region, plan, PostgreSQL version and storage. One click generates the Plan, Region, Storage and Engine version package options, each at price zero.
3. Set your prices. You price every option under Package Options. Prices you set survive a sync, and Rebuild from Azure warns you before it returns them to the starting price.
4. Your customer orders. They choose their options and pay. Their server is built and their page shows progress until it is ready.

What you get in Blesta

Selling and pricing

• Plan, Region, Storage and Engine version generated as package options from a catalogue checked against Microsoft's published lists
• You choose which options customers see at checkout. A hidden one uses the package default, and its prices are kept
• Rebuilding a package's options keeps the choices existing customers already made
• Plan and storage upgrades go through Blesta's own upgrade flow and resize the server in place, with a brief restart and the data kept. An upgrade that changes both applies both
• Azure never shrinks storage, so a smaller disk is refused with a clear message
• A resource name prefix of your choice, so servers read as <prefix>-<service id> in Azure

Provisioning you can trust

• If Azure refuses an order, you see Azure's own reason in the service's activity and the customer is never left on "creating"
• Running Create again never builds a second server or leaves the first one billing
• Suspending stops the server so compute billing pauses, while storage and backups keep billing and the data is untouched. Azure restarts a stopped PostgreSQL server after about 7 days, and a scheduled check stops it again and records why
• Unsuspending starts it again, and queues the start if Azure is still busy
• A server deleted outside Blesta is flagged to you in the activity log, and your billing is never changed by it
• When a failure is on your side, such as an expired Azure secret, the customer sees a neutral message and you get the detail

Running it day to day

• Clients and Databases: every server with its service, region, plan, endpoint and state
• Activity: provisioning and lifecycle actions with their outcome
• A Report with your licence, the configured Azure subscription, the database count and a secret-expiry countdown
• Warnings 60, 30 and 7 days before your Azure client secret expires, and a guided message naming the fix if it already has
• Read-only AI tools for service status, the database list and recent activity; nothing can create, resize or delete through them

What your customers get

• Connection details with Show and Copy: host, port 5432, the admin user dbadmin, the password and a ready-to-paste psql command. Connections use TLS and need no certificate file
• Trusted sources, an allow-list of IPv4 addresses or ranges they manage themselves. A new server accepts nothing until they add one, changes apply within a minute, and an invalid entry is refused with a message
• Separate databases for each application or environment: create and drop them from the client area. System databases are protected and a drop asks first
• One-click password regeneration and a server restart, each behind a confirmation dialog in the page
• Activity, the last 40 actions in plain words with each outcome

Customers connect with the admin login, so the pages do not offer separate database roles. A server's region is fixed when it is created, and moving region means a new order. Every feature is a switch on the package: turn one off and the page disappears and the action is refused, not only hidden. The pages follow the client portal's own theme and are fully translatable, with overrides that survive updates.

Security built in

• Your Azure credential is stored encrypted on the module account, and never reaches a customer page or message.
• The database password is stored encrypted on the service and shown only to its owner.
• TLS is enforced on every server's public endpoint.
• Customer actions need a signed-in owner of the service and a valid security token.
• Only licence data reaches us. No customer data or connection details do.

One product, every feature

PD Azure PostgreSQL is one paid module with everything included: provisioning, trusted sources, self-service databases, resizing, suspension and teardown. There are no 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, nothing the module built is stopped, deleted or altered. New provisioning and admin configuration lock while existing services stay visible read-only and customers keep being served. Renewing restores everything.

Requirements

• Blesta 6 or later on PHP 8.2 or later, with the ionCube Loader
• A Microsoft Azure subscription, with an Entra app registration that has the Contributor role and the PostgreSQL resource provider registered
• Blesta's cron running, so paid orders are provisioned and servers finish building
• PD Modules, the free control panel every PD module installs into