This post is part of a series sharing hands-on feedback on French PaaS providers, with one problem in mind: hosting a fleet of 120+ WordPress sites.
In this series:
- Part 1. Background to the French PaaS comparison
- Part 2. PaaS comparison: OVH falls overboard
- Part 3. PaaS comparison: Clever Cloud,
the boat is taking on waterthe captain rights the ship - Part 4. PaaS comparison: Scalingo stays afloat
- Part 5. PaaS comparison: Platform.sh lies at anchor
- Part 6. PaaS comparison: Hidora, the Swiss cloud
- Part 7. PaaS comparison: performance, Clever Cloud VS Scalingo VS Hidora
Platform.sh
Skip to the summary if you’re in a hurry
Our custom Symfony projects are hosted at Platform.sh (~7 projects).
I quickly ruled it out for hosting 120+ WordPress projects, because the pricing doesn’t fit our situation at all.
€40 for 0.8GB of memory, and that memory is shared between the application containers. So 800MB of memory split between the web container and the database container: not exactly the stuff of dreams…
The next plan up is €100/month. At that point, we’re multiplying our spending by 10, even though, in our case, we had no use for the feature that lets you run different environments.
Managing environment variables is, how shall I put it… complicated. You’d think the variables tab on the branch in question would be enough? Actually, no: those variables are only available at runtime, not at build time.
To add build-time variables, you have to click on a 20 by 20 pixel area that isn’t highlighted at all, then add the variables there. So you often end up adding the variables in the project configuration, then duplicating them in the master environment’s configuration so that the other branches inherit them.
Note that there’s no “Bulk Edit/Add” mode for environment variables.
The UI and UX/DX need work, because the interface is a regular source of frustration (on top of being slow).
Incidents are frequent (or else I’m just unlucky, and on the rare occasions I need Platform.sh, there’s an incident…), along the lines of “huh, my builds are stuck” or “the application isn’t auto-deployed anymore, so the fixes I thought went to prod 7 days ago never made it”. Fortunately, production never went down on our projects, but these recurring problems when using the PaaS wear you down.
To illustrate: from December to January, there were 10 incidents listed on their status page, some of them major (not counting maintenance). As I write this post, my team tells me they’re still blocked from deploying some environments.
Platform.sh summary (TL;DR)
👎 Cons
- Expensive
- No automatic scaling
- No way of knowing how many resources you’re using
- Very slow, unsexy interface
- Environment variable management
- Recurring incidents
- A deployment hook that you regularly have to delete and re-add to keep the project deploying automatically
- No monitoring tool in the interface for creating alert rules (e.g. post a message in Slack if RAM >90%). There’s only a disk space check
- Backups aren’t automated, or even offered as an automatic option. You have to set up a snapshot cron yourself
👍 Pros
- You can easily deploy branches as environments for demos or staging
- Environment variable inheritance, which makes it easier to create other environments
- The production database is copied when a new environment is created
⛔️ VERDICT: ELIMINATED ⛔️
I didn’t run any WordPress benchmarks, since the projected cost of migrating to them was already a dealbreaker.