Deployer App Pushes Plugins from GitHub to


Arūnas Liuiza, like many other WordPress developers, prefers to develop his plugins on GitHub, thanks to the collaborative tools for issue tracking, merging, and pull requests. Hosting and developing open source projects on GitHub is much easier than trying to get any participation from the community via a plugin’s Subversion repo on

For these reasons Liuiza decided to create Deployer, a service that allows plugin developers to publish plugins to the Plugin Directory directly from GitHub, without using Subversion at all. He first presented the app at WordCamp Lithuania in September 2015, but hasn’t yet given it much promotion.

“I wanted to streamline the process of publishing plugins from GitHub to,” Liuiza said. “I have more than 10 plugins in the repository, so I want to do things fast and easily.”

Last July we covered a similar service called Ship, which offered a hassle free approach to shipping plugins directly from GitHub to Liuiza, with 10 plugins to maintain, was initially excited about Ship but found there were several drawbacks.

“First, Ship required pretty wide access to my GitHub account,” he said. “GitHub does not provide granular API access, so I’d have to grant Ship access to all my GitHub repos, not only the one I wanted to publish from. That includes my private repos.

“Second, Ship needed my credentials. And because it will need to use them regularly, they could not really hash them and had to store them in plaintext. Again, that would give Ship access to everything in my account. All plugins, all themes, all comments, all translations, etc. Everything.”

This inspired Liuiza to create Deployer with a new approach that doesn’t require giving away access and credentials.

“In comparison to Ship, Deployer takes a quite opposite stance when it comes to requiring access,” he said. “Where Ship requests a lot of privileges, Deployer asks for almost none.

“Deployer asks no privileges on GitHub. Public GitHub repositories can be cloned without any limitations by anyone, so Deployer does that. Deployer would need access to set up a WebHook for itself, but instead of requesting access Deployer provides step by step instructions for user how to set up the Webhook manually,” Liuiza said.

The Deployer service doesn’t handle any sensitive authentication data for GitHub or Instead, it requires a more manual setup.

“Instead of requiring user’s credentials, Deployer has a dedicated user, deployer,” Liuiza said. “The plugin author has to manually add the deployer user to his plugin’s committer list, thus allowing that user to commit code to plugin’s SVN repository. This also enhances security, because can identify all the commits, made by the deployer user and roll them back in case there is a breach from Deployer’s side.”

Pushing a new version of a plugin from GitHub to is as easy as tagging the new version on GitHub. Deployer even handles updates to the readme.txt file and the assets directory.

“In terms of technology, Deployer is basically a single PHP file, that parses calls from GitHub Webhooks and then executes a bunch of shell commands (mostly git and svn) on a small Linux VPS box,” Liuiza said.

Since launching last year, 34 plugins have been registered with Deployer, although Liuiza said he doesn’t keep logs on how many developers are using it regularly. He doesn’t currently have plans to monetize it but is happy to accept donations.

“Unless it becomes a drain on my resources (and it does not seem likely at this point) it will always be a free tool,” Liuiza said.


18 responses to “Deployer App Pushes Plugins from GitHub to”

    • The short answer is because WordPress predates Git by about a year. We’ve been using SVN for longer than Git has actually existed. Switching to git would take a fair amount of work, for not a whole lot gain.

      That said, work is being done on things like git syncing and other means of making WordPress and associated bits available for those who prefer to use Git or SVN. That work continues.

  1. Deployer has a dedicated user, deployer

    Does this mean that if someone malicious obtains the password for that user (it’s still, unfortunately, the case that has no two-factor authentication system), then they could push their own updates to every plugin from any author that’s in the Deployer system?

    • Unfortunately, that is true. But with a single compromised user, maintainers could very easily revert those bad commits. I am following the proposal of Otto here, that he expressed when critiquing Ship. It is not a perfect solution, but in my opinion – a much better than storing a lot of plain text passwords for all the user’s.
      I wish had a better (or any, for that matter) API to handle those things, but I have no better solution for now. And I am open to suggestions :-)

      • I wish had a better (or any, for that matter) API to handle those things

        I have no argument with that!

        It’s very concerning to know that, for every plugin on your site, only a single password needs to be cracked in order for someone malicious to slip an evil new version onto, which people would start updating to instantly.

        Sure, it would hopefully get caught, within a few hours probably (a clever attacker would time his release for the sleeping hours of the plugin developer) – but with big plugins, that’s long enough for the malicious actor to slip his evil code onto thousands of sites. So, there’s a big prize, and a low barrier…

  2. I actually signed up a while ago then never actually tried it and deciding to remove the ‘deployer’ god from my plugin. I really not feel comportable with this. I wish something like this would be open source. I wound understand it if people build a payed service but what the point of Ship and Deployer of they are gratis and not doing any data grabbing? Or do they?

    I want a think I can install on ‘my’ VPS I control and at least somehow trust and then put some Webhook key, my user and pass and a config file, fire that thing up and forget about it. I do not want to sign my valuable data to some other person/service I do not know. I saw this thing that may be what I am looking for but it seems based on something that sits in some Automattic repo that may be better maintained. I not quote got the difference, the documentation is not really there and nobody seems to use it … thats why I never got to try it.

    • Hi Nico! I appreciate the feeling. That is how Deployer came about in the first place – I wanted a tool for my own workflow. Then I helped a client who did not want to tackle SVN. And then I thought it might be useful to others out there, so I added a public registration form and talked about it a bit.

      As for providing the service for free – I see it as part of me giving back to the WordPress community. I might not be a big-shot name in WordPress circles, but I still believe the things I have released (Gust, Content Cards, etc.) give me a bit of trust capital within the community. And they have donated more than 100 cups of coffee to support various of my WordPress related projects to date.

      As for your “valuable data” – if you are using Deployer, your project is open source and I do not believe I have access to any data you are not giving away anyway. Deployer only works with public GitHub repositories, and repository is also public. I do not believe I could have made this service in a way that requires less access and still works.

      As for making it open source, I only try to release stuff that I am prepared to support and document. Deployer is not something you can run on any shared hosting nor do I intend to make it such. It will require some technical knowledge to set up and run. I believe people who have that level of knowledge already have their own scripts in place, or can find better solutions for this – bash scripts, grunt tasks, etc. But hey, if you really need it – here is the class that does the actual work:

  3. Not really feeling the concept of open source runs deep in the WP community any more…like everyone’s following the services model of Automattic who realised that knowledge differentials are actually important to making money.

    This is exactly what needs to be released as open source so people can securely run their own services as well as review the security of the code. Otherwise there’s still a massive security target here.

    The problem, of course, is that the chance to ever make money from his work will then disappear for Liuiza…unless he can turn it into some sort of multi-tier service *and* get lucky…


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: