During my first week using Pantheon.io, I noticed another dev had committed some ” – – r ” files that were not readable in my environment, yet they still executed on Pantheon. (PHP doesn’t need executable permission, but the server user needs “read” permission.) I questioned Pantheon.io about this and to my surprise they admitted this is an “undocumented feature.”

Pantheon changes your file permissions without telling you it’s happening. Why is this bad? Maybe you intentionally did a “chmod” on some files expecting them to be private. But in reality, maybe a hacker is able to download or execute the file you wanted non-readable, or vice-versa. Who really knows, right? Because it’s undocumented.

To some degree, the whole of Pantheon is undocumented. That’s the nature of closed-source proprietary technology. I can just imagine Matt Mullenweg groaning, “I wish Pantheon fell under our open source license :-(”

At first glance, changing the permissions for us seems “user friendly.” Why should non-devs (the target market for Pantheon.io) worry about file permissions? After all, 80% of web server issues are due to permission problems.

But as we contemplate this a little more…hmm, this is potentially dangerous. It’s a completely undocumented vulnerability. Why undocumented? I’m guessing because:

1. It presents a security risk. Embarrassing. You would be telling hackers and thieves what the permissions are automatically changed to, and then Pantheon couldn’t just do a blanket chmod -R +755 or +644 or whatever to ‘fix’ the permissions of its technically-challenged users.

Pantheon presents a big target for hackers, because a vulnerability there could be exploited across every client, which includes Google.

2. Pantheon’s goal is to make life easier for an average agency to deliver advanced technology to clients they could not otherwise serve themselves because they lack the technical skill.

Exposing this permission issue (here we go now) will complicate life for a lot of junior people that have no idea how a production server works. Who is “www-data” and why should you care? Overlooking the complexity has repercussions beyond the scope of this post.

Simply put, if you’re in the business of publishing content for clients that trust you to know what you’re doing, you should have someone that knows what they’re doing.

Choosing a proprietary tool like Pantheon.io that obfuscates your responsibilities is bad for business. I’m no open source evangelist, but we must admit that mature open source software is usually very reliable and secure with few surprises. That’s why most of the Internet still uses a LAMP/LEMP stack, it’s predictable and documented.

Is Pantheon actually easier than using LEMP/LAMP directly?

No. In reality, Pantheon is more convoluted than using a LEMP or LAMP stack directly because you’re introducing another layer of complexity which results in technical limitations, and unpredictable behavior like “undocumented features” aka backdoors are exposed, and common techniques and tools are unavailable, and outgoing ports are randomized, and non-standard systems (such as “Terminus”) lock-in a business to the Pantheon.io system, which presents an unnecessary challenge if Pantheon prices rise, if the company goes out of business, is hacked, hit by a storm, has a disgruntled employee, is acquired, etc.

Another problem here, copying “dev” to “live” should only take a few seconds at the most. With Pantheon the workflow is unnecessarily time-consuming.

Because Pantheon aims to please the most demanding agencies, all Pantheon users end up doing things the most convoluted way possible, such as moving code through four stages from local > dev > test > live. And with Pantheon, each stage has its own weird quirks, like on the dev server you only have file “write” permissions in the uploads directory, and outgoing IPs are randomized so there’s no way to know if your blog has a blacklisted IP address that’s affecting your API integration, for example.

A skilled developer can safely move from “dev” to “live” with more agility, without spending days researching Pantheon’s limitations. So whatever time you think you gained by not setting up a proper server stack, you just lost it by reading Pantheon’s documentation and looking for workarounds to Pantheon-specific problems.

And because your developer can’t just ssh into anything (not the database, not the web server, not WordPress…) you have vastly limited your capabilities. And don’t forget, Pantheon is missing several essential server environment variables!

Pantheon is advertised as “we save you time setting-up, managing tech.” In reality, Pantheon’s non-standard platform results in a lot more confusion. “Why is this not working? Oh, that’s different in Pantheon. Oh, that’s blocked in Pantheon. Oh, check this URL for the way we do that in Pantheon.”

Instead of learning the correct way to develop in WordPress, your agency is getting into a long-term relationship with a proprietary system. When you’re finally ready to flip your DNS to another company, will your Pantheon-specific code still work? Probably not.

If you would like real WordPress hosting from a real WordPress developer, let’s talk.