Install Plugins in Discourse


(Joe Buhlig) #143

I know I mentioned that I’ve been using the token method for installing private plugins, but when building plugins for clients I’ve learned that I don’t want to use a token from my own GitHub account. The client would then have access to all the repos I have access to.

An alternative has been to set up a machine user and grant that user a token that can be used once the machine user is made a collaborator on the private repo. But I don’t really feel like paying for an extra collaborator seat for each machine user.

I still use tokens on demo servers, but for production scenarios, I went back to the original way of installing private plugins. I did run into issues with the original instructions. What eventually worked for me was the following:

## Remember, this is YAML syntax - you can only have one block with a name
  - exec: echo "Beginning of custom commands"

  - exec: cd /var/www/discourse && sudo -u discourse bundle install --deployment --without test --without development
  - exec: mkdir /root/.ssh
  - exec: chmod 700 /root/.ssh
  - exec: echo "Host\n\tStrictHostKeyChecking no\n" >> /root/.ssh/config
  - file:
      path: /root/.ssh/id_rsa
      chmod: 600
      contents: |
        -----BEGIN RSA PRIVATE KEY-----
        -----your private key string-----
        -----END RSA PRIVATE KEY-----
  - file:
      path: /root/.ssh/
      chmod: 600
      contents: ssh-rsa ---your long string--- user@discourse
  - exec: cd $home/plugins && git clone
  - exec: cd $home && sudo -E -u discourse bundle exec rake db:migrate
  - exec: cd $home && rm -fr tmp/cache
  - exec: cd $home &&  sudo -E -u discourse bundle exec rake assets:precompile
  - exec: rm /root/.ssh/id_rsa
  - exec: rm /root/.ssh/
  - exec: chmod 600 /root/.ssh

  - exec: echo "End of custom commands"

(Jay Pfaffman) #144

But aren’t you now giving them your ssh key, which still gives them access?

(Joe Buhlig) #145

I’m generating a key specific to that scenario and adding the public key as a deploy key on the repo. So it’s not the SSH key of my machine.


I have installed a couple plugins and now want to add another. Do I remove the already installed ones from the app.yml of just add the new ones at the bottom?

(Matt Palmer) #147

Unless you want to uninstall the other plugins, you want to keep them in your app.yml.


Good to know, thank you!

(Angus McLeod) #149

The downside of using deploy keys to install a private plugin via custom commands is that you can’t upgrade the plugin via /admin/upgrade.

@mpalmer How hard would it be to allow for plugins installed via custom commands to be “upgradeable” via /admin/upgrade?

(Matt Palmer) #150

Very difficult. Give it a shot if you like, but it’s a tricky problem. The best option is to switch to using oauth tokens (with all the security/cost tradeoffs that GitHub’s scopes inflicts).

(Jordan) #151

@molly_cushing, Your post was exactly what I needed! Thanks for putting this together.

I personally learn the best by watching someone do something so I created a video tutorial following the steps you outlined, for anyone who’d like to see the process in action:

(Sivert) #152

I’m beginer in Discourse, and after cloned Disourse repository, can’t find container/app.yml fie.
Do I have to create new one?
And also the command “./launcher rebuild app” isn’t working cause there isn’t such file or directory named “launcher” in the project


Sounds like you didn’t fully installed Discourse, you need to follow all these commands : discourse/ at master · discourse/discourse · GitHub

After that, and only after, you can run these commands to install a plugin. You need to be in the discourse folder :
cd /var/discourse

After that, you can open the app file using nano
nano containers/app.yml

And still in the /var/discourse folder, you can run the command to complete the install (this command will take a few minutes)
./launcher rebuild app

(Stephen) #155

There’s actually no need to sudo -s when updating your app.yml, a simple sudo nano containers/app.yml from within /var/discourse will suffice.

The ‘git pull’ is redundant here too.

@sivert If you ran discourse-setup as outlined in the official install guide an app.yml would be created for you at /var/discourse/containers/ with all the necessary settings to get Discourse running. Have you already done this? If so you need to move to /var/discourse before issuing the commands you mentioned above, a simple cd /var/discourse will suffice.

as … means ‘up a level’ it’s very rarely going to be the right way to get there.

(Sivert) #159

@Stephen Thanks for your answer. It seems I was confused between dev and pub versions.
Just now I was working on developing version in my MacOS system.
Can I continue follow this guid to test my plugins on developing version or is this thread for only production version and I have to find another way?

(Sivert) #160

I just have followed this tutorial and can’t find any “container” directory or “./launcher” for rebuild command.
Please help me what am I wrong and how can I add plugin this development version.

(Jay Pfaffman) #161

Did you do this? discourse/ at master · discourse/discourse · GitHub

(Sivert) #162

Why cloud? Is it impossible to work with plugin on local development server?

(Rafael dos Santos Silva) #163

For local you just need to clone the plugin you want under the /plugins directory and restart the web server.

(Angus McLeod) #164

Just circling back on the best way to handle the deployment of multiple private plugins (particularly if you do work for multiple clients), the way I handle this now is:

  1. Create a github “Machine User” for the client.
  1. Add the machine user as a collaborator to the private repo hosted in my Github account. This is a free (unpaid) Github account. Free accounts can be collaborators on private repos.

  2. Create a personal access token for the machine user.

  3. Use the machine user’s personal access token to install the plugin on the client’s server.

This approach:

  • Allows the plugin to be updated via /admin/upgrade
  • Does not cost anything extra
  • Does not expose all private repositories in your account to each client.

Note that Github seems supportive of this kind of use of their account system, see here:

Tip: Our terms of service state:

Accounts registered by “bots” or other automated methods are not permitted.

This means that you cannot automate the creation of accounts. But if you want to create a single machine user for automating tasks such as deploy scripts in your project or organization, that is totally cool.

(Michael Brown) #167

You can create deploy keys on repositories - that would be much less work.

(Angus McLeod) #168

Indeed, however using deploy keys does not allow the private plugin to be updated via /admin/upgrade, as you have to use custom commands in the app.yml.