To help us understand your query, can you please explain your needs/scenario.
Option to clear varnish cache is already available in Platform, go to servers listing, select server in question, then Manage Service, and if you have varnish enabled you should see a button title as PURGE.
Also, could you provide ticket reference number so that we can look into the details, and know more about what you are referring to.
Finally we have this in private beta in the form or a managed private Kubernetes cluster. We are running a number of customers on top of it (up to millions of visits per day) and gathering feedback.
Currently the cluster product is running only on top of Google Cloud but we plan to expand availability.
This will be a high touch service for people overflowing the current platform and that need much higher levels of scalability and availability.
We don't have an ETA for public availability yet.
Hannah, if you mean Kyup, yes it is live already: https://www.cloudways.com/blog/deploy-web-apps-on-kyup-cloud/
The agent that spoke with Stefan, was referring to Kyup (and probably was not clear enough about it).
As it stands and with the features it brings, Kyup is an alternative to a full blown web farm with load balancers, auto-scaling groups, shared storage, database layers ... This is based, as explained, on following features:
* Instant auto-scalability with no downtime (currently just up, down coming soon).
* High availability (when using distributed storage that will be available this month) with nearly no downtime (2-5s). Server can restart in new physical server automatically in case of issues with the physical server where it is hosted.
For customers who need all cluster features, we have started to work on a cluster option based on containers that could be deployed on top of any infrastructure with a minimum number of three servers. We will be performing R&D throughout Q4.
We are working to integrate a new provider with a new technology (containers on bare metal) that will solve most of what a load balanced / multi-tier infrastructure would provide with much less complexity (and of course cost).
What we aim at being able to offer with the new provider:
* Nearly instant provisioning (<2s).
* Instant scaling (<2s with no downtime).
* Option to schedule scaling (date/time) or set auto-scaling based on CPU/Memory usage (again nearly instant scaling <2 with no downtime).
* High availability via live migration between physical hosts (to be available soon).
We think this is the way the market will go to solve the customer problems that were solved (up to now) via load balanced environments.
We will keep you posted.
We are considering how to better solve the multi-tier / auto-scaling / high-availability problem. As you know, our main focus is simplicity, so we need to consider it in this context too.
We have some ideas about it but need to develop them.
At the moment, support for additional vhost for the sub-domains or pointing to separate webroots is not available.
However a solution for your scenario would be to add 'Additonal domains' through Cloudways panel and instead using separate webroots, specifiy the static/media paths in URL with additonal domains in Magento Admin
For e.g if you have additional domains static.yourdomain.com and media.yourdomain.com for static and media paths respectively.
First you can add them as additional domains through Cloudways Panel, this would map the additional domains/sub-domain to your application
Then in Magento panel: stores -> configuration -> web -> Base URL or Base URL Secure (in case your setup is on HTTPs) for magento 2.X, set path in following manner
static.yourdomain.com/pub/static/ (for static)
media.yourdomain.com/pub/media/ (for media)
Setting this way enables you to gain the performance, as having the additional domains/sub-domains will increase the number of parallel downloads that the browser can perform.
Hope that answer your question
To read how you can add additional domains/sub-domains please follow this KB: https://support.cloudways.com/what-is-the-difference-between-primary-domain-and-additional-domains/
Two things to consider about Vultr (and in general all providers) pricing:
1) Server sizes
Vultr's $5 (1GB), $10 (2GB), $20 (4GB) and $40 (8GB) plans are marked up to $11, $23, $44, $84 per month
DO's $5 (512MB) , $10 (1GB), $20 (2GB) and $40 (4GB) plans are marked up to $7, $17, $34, $70 per month
We compute the server size, when calculating our pricing. Why?. As (unlike other competitors) support is a big part of our service, bigger servers generally mean bigger/more sites and so, potentially more support.
In this sense, and as per Brendyn last comment, you need to compare 1GB Vultr server with the 1GB DO server (so $11 to $17, +$6 and +$7 on top of infrastructure price, which is quite consistent).
We do not get the same deals from all providers, so Cloudways final price may differ slightly between them.
In short, Cloudways server prices are a function of the server size (each size has a specific and consistent % mark up over infrastructure price) and infrastructure costs for Cloudways (that depends on the deal we get from each provider).
Hope that makes sense.
A nice customer wrote this handy blog post:
You can use it while we don't have it in our application list.
Thank you for your post.
As you rightly point out, this functionality is available and possible through the PHP Settings feature provided on the Platform. Have you faced any issues with getting it to work with environment variables?
By providing a new section, I see users having the following advantage:
a) A consolidated view of custom defined PHP env variables and their values.
b) Instead of users typing "env[VAR_NAME] = VAR_VALUE", they will be typing "VAR_NAME = VAR_VALUE" in the new section.
I agree that it will bring some ease to users and provide a slightly cleaner alternative that what is available right now. However, I am trying to determine if, as a user, you will find that it will really provide value to users, since what this new section will achieve can already be achieved through the PHP Settings section?
Thanks for the suggestion. We have been discussing how to better address this (as limiting bandwidth can be dangerous for users with legitimate traffic increases).
One option would be to create a Cloudways Bot alert in case of significant traffic spikes and leave it to the customer to decide what to do.
Once we have a more defined approach we will update here.
1 vote1 comment · Service Improvement » Server Configuration Improvements · Flag idea as inappropriate… · Admin →
Can you please help me understand the use-case for this in your particular scenario?
By changing the webroot for your application (under Applicaiton > Application Settings > Webroot), you can have your code deployed under public_html/ but served to the public from a directory within it.
Can you please elaborate in the advantages over current infrastructure providers that you see if we add Packet?. Which will be the use case?
I am sorry you had to go through that much trouble.
Could you please help me understand how you were trying to use Gulp here that didn’t work?
It is true that at this point in time we don’t support global installation of Gulp. But you should be able to use Gulp easily.
If you have the Gulp dependency defined in the package.json file, then you may run `npm install` to install it. Once installed, if you have a gulpfile.js with Elixir assets defined, you can run gulp by referencing it via `./node_modules/gulp/bin/gulp.js`. It is a somewhat inconvenient, yes, but it should do the job right.
Could you please tell me if you faced issues this way?
I logged in with your master user and looked inside your Laravel application (pthsuyabeq). I noticed that the gulp.js binary was not available inside the `./node_modules/gulp/bin/` directory inside your application's public_html folder. So I went ahead and ran `npm install gulp` from inside the public_html folder. After that, I was able to run `./node_modules/gulp/bin/gulp.js` which resulted in a successful run. Can you please check again if this works for you?
Yes, recently we have introduced new feature through which customers can exclude URLs from Varnish, since it's possible to use Varnish with Wordpress Multisite + WooCommerce and in this context you can follow this blog to achieve this :
We have added backup retention feature (up to four weeks).
We are checking options to offer snapshot backups (available from all providers but DO) and in talks with DO about it.
We already have the option to restore a deleted server (we keep backups for 15 days). By now this is an internal feature (due to privileges required) only available to support. But anyone can open a chat and get a deleted server recovered.
We will consider other suggestions, as we do with all in our feedback page, to build our roadmap.
2 votesAdminCloudways (Admin, Cloudways) responded
Oregon has been added. Japan will be next.
Oregon has been added. Japan will be next.
1 voteAdminCloudways (Admin, Cloudways) responded
Can you please expand?
Can you please expand?
All servers launched since last Feb are using Debian 8 and Debian 8 has git 2.1.4, so it should work.
If you are using older servers (still with Debian 7), then you need to migrate your application to a new server with Debian 8:
Arne, we are working on replacing Debian Wheezy with Jessie as base OS and Jessie already has git 2.1. It will take a while though.
Varnish should work with woocommerce[ multisite ], unless you are using custom store routes and other plugin/code that are using non-standard cookies to store session information.
Is it possible for you to raise this with our support team, along with the information what exactly you found is not working.
It should be available as default on the server.
If for some reason it is not working then please raise a ticket with our support.
12 votes3 comments · Service Improvement » Server Configuration Improvements · Flag idea as inappropriate… · Admin →
You can already replace MySQL with MariaDB on any server: