Ya' row ze: Lets go!

You are here

What you should know before hosting on Pantheon

Choosing and moving to a hosting platform should be easy, but, if your goal is to re-home your platform/application, there are a ton of minute details that stack up to be a real thorn in your side. The goal of this post isn't to trash Pantheon (I'm actually relatively happy with them despite this list), but to account for things that a) I really think a professional hosting company should realistically be doing, and b) point out the details that we sort of assumed wouldn't be a problem that ultimately became sticking points.

For background, We had previously rolled our own build and deploy system, and it had been running relatively smoothly for a couple of years. This invariably means that our development process had probably acquired some artifact principals from the deployment process, and those would not be available at our new home, so I knew to expect a little trouble.

"We are an opinionated platform, that's for sure."
-Pantheon Engineer

1) You have to hack core. Granted these hacks are mostly Pressflow distribution hacks, you still have to do it. This is easier if you use a composer build, then you can just switch your drupal/core entry. But if you aren't, and you want to BYO code base, you'll have to figure out the expected hacks, and overlay those with any you've produced.

2) If your site uses a zero touch deployment, you'll have to reengineer this. While they do support post code deployment hooks (called "quicksilver" hooks) - those hooks only trigger php based scripts. Your bash or shell scripts are no good.

3) If you use multisite, you are out of luck - they specifically don't support it. They will convince you that "custom upstreams" are the way to go. Just deploy your code over and over for each tenant in your system, then let their upstream tracking functionality automatically pull the code in. However, contrary to at least one case study they provided, that functionality explicitly doesn't support "quicksilver" hooks - the ones you probably just rewrote after #2. There are workarounds for this, but it will involve substantial changes to your CI system and workflow. This pretty much diminishes the upstreams functionality to being a way for terminus to track which site uses what code.

4) Multidev is a cool feature, unless you want to use your own development process. Branch names are limited to 11 characters (or is it 10?). must be valid 'domain name' style (which while legal for domain names, does not include uppercase or underscores). If you chose to create your own branch within the multidev system, It potentially can be a much longer. This is problematic if you use a naming convention for your branches - such as Git Flow's bugfix/name or features/name style. If you apply any kind of issue tracking convention to your branch name you in even deeper. "feature/JIRA-123" is invalid, and changing this to be "JIRA-123" is fine, but only leaves 3 more characters for a more meaningful name.

5) Their varnish caching servers explicitly ignores cookies with names other than known drupal/wordpress/php names. Requiring you to retool your code (if you are moving onto their platform). Additionally, if you have a need to share cookies across your sites, you technically can do this. but only for sites that are live an on a 'plan'.

6) All sites are provisioned as [env]-[site].pantheonsite.io. That's fine, except that this makes it impossible to federate your cookies (see #5). If you use an SSO system like Bakery, you won't be able to prevent SSO logins between your dev-site1 and test-site2 environments. Additionally their cookie filtering system specifically blocks assignment of the bare 'pantheonsite.io' domain. This makes perfect sense, and is a good thing. However, because of the subdomain structure, you have no other option for testing. Bakery (and shared cookies in general) cannot work within the pantheon infrastructure. There is a small * to this. If you get the site on a plan, you'll be able to then submit a support request to get a 'vanity domain' added to your environments.

7) Their crontab is not configurable and only offers 1 hit per hour. This is fine if cron is just performing routine maintenance tasks like cache and log cleanup. But if you have any kind of scheduling tools (such as publishing content at a specific time) you'll need to find something else. Fortunately there are free services to establish cron tasks (thanks http://cron-job.org !!) but you'll still have to invest in either ensuring registering your cron heartbeat happens manually, or invest even more in an automation step.

8) If you want to use other opensource services that they offer (such as SOLR) you must use their custom code to access them. SOLR has an established protocol and access method, and there's a large community that managed the contributed module space for this within drupal. You mostly get non of that benefit. Worse, If you already had SOLR integration into your site, you'll have to rebuild *and* reengineer that aspect. This could all be avoided by pantheon simply offering an environment variable with the the URI's of the chosen environment's SOLR server rather than building a custom sensing library with a proprietary access protocol.

9) SSL Certificates. I give Pantheon some pretty solid props for their handling of SSL certificates. They have their own CDN, and roughly speaking, the instant you provision your DNS to point to the Pantheon CDN, they will issue a certificate that includes your domain. Their Domain/SSL feature on the administration UI is also great, and does a good job of providing instructions on a variety of DNS platforms. There's a catch though. 1) you can't bring your own certificate. This means, if you have an EV Certificate, Wildcard Certificate or whatever else, you are out of luck with native Pantheon solutions. 2) You have to manually provision the DNS each time a new site created rather than applying a wildcard CNAME that just points to the Panatheon CDN.

The solution to this according to Pantheon Support and documentation, is to "implement your own CDN - eg. Akamai, or Cloudflare", terminate SSL with them, and point that CDN to the Pantheon CDN. Note that A) this is a CDN using a CDN, and B) Pantheon will not un-expose your site on their Global CDN. this means, if you do some kind of magic (such as akamai's cached authentication strategy), anyone who discovers you use Pantheon can simply bypass your CDN work, and make the requests via that network. (Note that this is not me saying it's okay to have weak application security at origin)

Back to top