PD Azure VM for Blesta

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

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

Why hosts choose PD Azure VM

Sell cloud servers under your own brand. Your customers see your company, your prices and your client portal. They never need an Azure login, and there are no per-server fees to us: you pay a flat module subscription and Microsoft bills your own subscription.

Every order sets itself up. The server is created when Blesta activates the service, with the region, server plan and operating system the customer picked on the order form. Provisioning resumes from the step it reached if anything needs retrying, and an order Azure cannot fulfil fails with the reason instead of sitting half-built.

Each customer is isolated. Every service gets its own Azure resource group holding its server, disks, private network, firewall, public IP and snapshots. The module leaves the rest of your subscription alone.

Customers help themselves. Power controls, connection details, snapshots, extra disks, a firewall, SSH keys, boot diagnostics, 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. An order whose size does not fit the region's vCPU quota is refused with the exact steps to raise it, before anything is created. The order form only lets a customer combine a region and a size that Azure actually offers there, so a refusal never becomes a paid order that then fails.

Nothing left billing. Cancelling a service deletes its whole resource group in one ordered operation, then verifies at Azure that nothing is left. No forgotten disks or addresses on your Azure bill.

How it works

1. Connect your Azure subscription. Create an app registration with the Contributor role on your subscription and add its credentials as a module account under Settings, Company, Modules. Test Connection checks every account you have added: it verifies the sign-in, checks that the compute and network services are registered, shows your vCPU quota in the default region and names the exact piece that is wrong if it fails.
2. Create your packages. One click generates the order options (region, server plan, operating system, disk size and snapshots you can keep) from your live Azure catalogue. You choose which ones customers see.
3. Your customer orders. They choose their options on the order form and pay. When Blesta activates the service the server is built in its own resource group with a reserved public IP, a firewall and a ready-to-use SSH key.
4. You get paid, they manage it. Blesta keeps billing as usual. Plan upgrades apply in place and keep the customer's disk and data.

What you get in Blesta

Selling and pricing

• Order options generated from Azure: region, server plan, operating system, disk size and the number of snapshots a customer can keep
• Server sizes read live from Azure for each region, and curated official Linux images: Ubuntu 24.04 and 22.04 LTS, Debian 13 and 12, Rocky Linux 9 and AlmaLinux 9
• Choose which options customers see; anything you hide is fixed to your package's setting, and rebuilding keeps the choices existing customers made
• A customer can paste their own SSH public key on the order form

Provisioning you can trust

• A server size the region does not offer is refused before anything is built
• A failed create removes everything it had started, so a failed order never leaves resources billing
• Suspend deallocates the server so compute billing stops, with its data untouched. Unsuspend starts it again on the same public IP. The page says plainly that the disk and reserved IP keep billing
• The public IP stays the same across stop and start, reinstall and restore, so DNS keeps working
• Plan upgrades apply in place, with a brief power-off only where Azure needs one, and a bigger disk grows without touching data

Running it day to day

• Clients and Servers: every server with its client, plan, operating system, region, IP and live state
• A Products screen that shows what each package still needs to go live
• A full activity log of every provisioning step, snapshot, disk and firewall change

What your customers get

• Start, shut down and reboot, with a confirmation and a progress indicator. Shutting down releases the compute so it stops billing, and the page says so
• Connection details ready to copy: the public IP, SSH user, a private-key download and the exact ssh command
• A firewall they manage themselves: add rules by protocol, port or range and source, remove any rule, and lock a port to their own IP range. The default allows SSH only
• Snapshots they name, take, restore and delete, up to the allowance they bought
• Extra disks they create, attach, detach and delete
• Their own SSH keys, saved by title and applied on the next reinstall. Password login is disabled
• Boot diagnostics: a live console screenshot and a serial log, so they can diagnose a server that will not start before they reboot, reinstall or restore it
• Reinstall to a clean copy of the original operating system, behind a typed confirmation
• 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, each with a time

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 Azure credential is stored encrypted, never appears on a customer page, and is sent only to Microsoft's own sign-in.
• Every server uses SSH-key login only. With the default setting each server gets its own key pair, and only the signed-in owner of the service can download the private key.
• The in-browser terminal is off until you switch it on, at the module and on each package. Sessions are short-lived, single-use and bound to the customer and server, the key never reaches the browser, and the contents of a session are not recorded.
• Nothing about your customers is sent to us. The module talks to Azure, the PD Modules licence service and, only while a customer uses the console, our relay.

One product, every feature

PD Azure VM is one paid module with everything included: provisioning, power, snapshots, disks, firewall, boot diagnostics, 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. Their servers keep running in your Azure subscription throughout, and customers can keep managing them until the subscription is suspended. New provisioning and admin configuration lock when it expires, and the browser console stops at that point. Cancellations still complete, so nothing is left billing you.

Requirements

• Blesta 6 or later on PHP 8.2 or later, with the ionCube Loader
• A Microsoft Azure subscription, and an app registration with the Contributor role on it
• PD Modules, the free control panel every PD module installs into