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.

There are 18 comments

Comments are closed.