• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

A special topic for chatter about Plesk in the Clouds.

Oh Great! I suggest you use Plesk image on Ubuntu from AWS Marketplace with recommended security-group. Thanks!
 
We are using Plesk with a AWS RDS external database.

The possibility to use a single RDS database for muliple plesk server should take definitively into account.
 
I have no issues using Plesk in the Amazon Cloud. Maybe I just got used to all the drawbacks or simply don't pay too much attention to them. It is hard for me to try something new so I'll probably just continue using Amazon.
 
Anyone using AWS EFS with Plesk for customer emails/web content? I'm wondering if it's possible to mount AWS EFS on multiple Plesk ec2 instances and put a load-balancer infront.

Like others mentioned previously, AWS was very expensive and diffucult to troubleshoot when you run out of resources for ec2, rds, etc. We've been testing DigitalOcean on a small scale and it's been working well. We're hoping to move more of our Plesk servers over to DO but there is some limitation in comparison to AWS (ie no shared filesystem, floating ip limitation, etc).
 
@stevewest15

To be honest, I am not using AWS and I have even stopped testing AWS to host Plesk in the cloud - that is quite uncommon for me.

The truth is that AWS is expensive, rather annoying in terms of VMs and rather prohibitive in terms of costs.

I have tested an advanced setup on AWS, Azure, GCP, DigitalOcean and some other platforms.

AWS was limited in possibilities and twice as expensive as Azure, even though I did a test run on AWS for 70% of the duration of the test run on Azure.

GCP is comparable to AWS, but costs can be managed (when knowing how to reduce costs) to costs equivalent to that of Azure.

DigitalOcean cannot be compared with AWS, GCP or Azure.

Azure itself seems to be the obvious best candidate, but it actually is not.

Azure has a very specific infrastructure and one is tempted to ignore a "common sense design infrastructure" - in essence, one is tempted to use the full setup as propagated by Microsoft that presents specific services as solutions.

Azure is the most cost-effective and infrastructure-efficient solution, if and only if one really deviates from a standard setup.

Azure (and all other platforms to some high degree) require an advanced setup, but that is really contradicting the whole purpose of "Plesk in the Cloud".

It will only give you headaches and repetitive tasks for many (often small) "units of server infrastructure" - this is cumbersome, inconvenient and inefficient.

More important is the simple fact that one can always create a hybrid structure : parts in the cloud and parts on dedicated server.

Please note that I am a fan of keeping things simple - two or three dedicated servers (of considerable size) are sufficient.

I am a fan of a "design infrastructure" with two or three dedicated servers, because it is cheaper and more easy to manage than any cloud setup.

Nevertheless, I must admit that I have been able to create an experimental setup on Azure that was really satisfying, fast, safe and easy to manage.

However, why should I opt for an experimental setup that allows me to scale infinitely (advantage) at a prohibitive price (disadvantage)?

I am pretty sure that we all love the idea of a decent cloud setup ....... and that we all encounter the limits of any cloud based Plesk setup.

I have been able to work-around the limits of the cloud based Plesk setup ..... and that still is not a solution : it is too expensive.

In short, one can safely assume (and not conclude - that is something different) that the "old method" of dedicated servers will suffice.

If you are really interested in a cloud based setup, please experiment ....... but be aware that Plesk actually is not really ready for a cloud based setup.

The latter statement is a humble opinion, obviously.

Kind regards..........
 
We are using Plesk with a AWS RDS external database.

The possibility to use a single RDS database for muliple plesk server should take definitively into account.
@carini

That is already possible - one can use a single (remote) database, irregardless of the question where the database is hosted.

Nevertheless, it is not recommend, for three reasons :

1 - most important reason : security ....... Plesk database connections are not secure, so even in a cloud environment these connections are not secure!

2 - a cloud related reason : any cloud based database is sooner or later hitting restrictions (read: cloud inherent limits - they are always present, unless you want to pay literally thousands of euros per month for a database on a dedicated database server in the cloud, but even then you have limitations)

3 - a "design infrastructure" related reason : any infrastructure that is dependent on one single database will fail sooner or later (read: it can breakdown, but in most cases there will be throttling or service disruptions) .............. and, in that case, all plesk servers (attached to the single database) will have severe issues.

By the way, I did not even mention that the latency of most cloud based databases is quite high.

Personally, I would recommend to use

a - in case of small workloads and/or when security is important : a databaseserver on the server that hosts the Plesk instance (read : local connections)

b - in case of higher workloads and/or multiple plesk instances : a central database server on a dedicated server (just use a stand-alone MySQL or PostgreSQL based server) with (highly) secured connections to the servers hosting the Plesk instances

c - in case of high workloads that require speed and low latency : use a setup with Redis (dedicated) instance between the Plesk instances and the database server(s)

and it should become clear by now that options a to c do not necessarily require any cloud based service.

I hope the above helps a bit.

Kind regards.......
 
Not used the cloud setup yet... other than that is good... now thinking about using it... soon will come back to this post... hoping with satisfaction...
 
I moved our Plesk hosting from an 'On-Prem' Solution to the Azure Plesk Marketplace image. Our DB and Plesk images are separate and we use a single private subnet for the DB connection, allowing it to be contacted only via the Plesk VM. I have not seen 'any' latency issues.

I have found an issue and this may be present on non-'cloud' versions, well I didn't 'find' it, it appears it has been present for a while and I stumbled across it as I don't log in as root when running my backup scripts.

Issue:
- amend the vhosts directory permissions using FACL permissions.
- test working, yes confirmed.
- reboot the server
- All permissions are not completely wrong.

Using FACL permissions on other servers works fine, and I have never run into the issue. However when using FACL permissions on the CentOS 7 marketplace VM, it broke the VM and i had to restore it from the nightly backups.

Otherwise, ease of setup=perfect, costs=reasonable, maintenance costs=minimal, ease of use as I no longer need to order a separate Licence for Plesk=spot on.
 
I moved our Plesk hosting from an 'On-Prem' Solution to the Azure Plesk Marketplace image. Our DB and Plesk images are separate and we use a single private subnet for the DB connection, allowing it to be contacted only via the Plesk VM. I have not seen 'any' latency issues.

I have found an issue and this may be present on non-'cloud' versions, well I didn't 'find' it, it appears it has been present for a while and I stumbled across it as I don't log in as root when running my backup scripts.

Issue:
- amend the vhosts directory permissions using FACL permissions.
- test working, yes confirmed.
- reboot the server
- All permissions are not completely wrong.

Using FACL permissions on other servers works fine, and I have never run into the issue. However when using FACL permissions on the CentOS 7 marketplace VM, it broke the VM and i had to restore it from the nightly backups.

Otherwise, ease of setup=perfect, costs=reasonable, maintenance costs=minimal, ease of use as I no longer need to order a separate Licence for Plesk=spot on.

@azzaka

I am happy to see that you moved some or more Plesk instances to Azure - that is or might be a good solution, even though the cost is relatively high and major drawbacks are present in terms of performance and throughput (and potentially egress and ingress costs).

Many years ago, I have tested Azure with

- a custom image, made from scratch and compared it to the default Marketplace images, (and)

- an experimental Plesk cluster setup, which cluster was very capable of running - simulated - high loads ........ but at a very high price (!),

and the above is one of the many tests that we executed in cloud environments.


I do want to point out that it is in your best interest to

a) create a custom image, hence also reverting to the Plesk one-license-per-server model : this custom image gives you more flexibility and efficiency in the long run, especially when customizing (reboot persistent!) configuration and configuring for enhanced security, (OR)

b) create a simple bash script allowing you to customize the configuration (in a non-reboot-persistent way) of the server : just run the script after allocating and launching the Azure VM, (OR)

c) advanced - create an Azure script that will run after allocation but before the VM is launched : not a topic for now ....


I also want to point out that any Azure VM based Plesk install is a bit different than a regular server based Plesk install - you should really adjust locations of the directories used to store configuration and temporary files, otherwise you can or will loose relevant/convenient data across reboots or VM reallocations.

In essence, put most data on a the shared drive associated with the Azure VM and make sure that the drive is a separate file share that can be assigned to other Azure VMs : no need to restore backups, just launch another VM and attach the file share.

Also note that this is the trick to load-balancing or clustering : two VMs using the same file share, it is possible (but not recommendable) and it will increase the availability of your cloud setup (with file shares already being replicated, so no need to setup RAID alike structures in Azure - just make snapshots!).


As you can imagine by now, many of the standard features of Plesk - like backup extensions or solutions - are completely obsolete when running in Azure.

You can use multiple file shares, snapshots and backups of the fileshares (with cold storage for backups), multiple VMs as proxies (with Nginx load-balancing), hence also removing the common limitations of both Plesk and Azure!


Nevertheless, there are some common issues that you have to be aware of and that you need to configure within Azure.

For instance, your private subnet is not so private and not secure ........ neither is the Plesk DB connection : there is no secure SQL support.

Please add some security measures to the (private) network, start with a NSG and add some paid-for Azure functions - otherwise, you will have a significant attack surface, even though one might expect that everything is safe.


I hope the above helps a bit ....... and please do keep posting about the experience with running Plesk in Azure!

Kind regards....
 
We have two Plesk serever in AWS (now in eol path) and five more server in Azure, we use Database as-a-service to ease the workload on server.

Sharing the same database server between two hosts is not straightforward, but it works.
 
Back
Top