<p>Typically, the desire for a private plugin is for a one-off client project, where the client owns the custom plugin. If that's the case here, I'd consider just changing the plugin over to be a module, and making it part of the project itself (checked into git, and all that).</p>

<p>e.g.: <a href="https://nystudio107.com/blog/enhancing-a-craft-cms-3-website-with-a-custom-module" rel="nofollow noreferrer">Enhancing a Craft CMS 3 Website with a Custom Module</a></p>

<p>It's actually pretty easy to convert a plugin over to being a module. FWIW!</p>

CC BY-SA 4.0
2019-04-15T11:21:37.987Z
You just nailed my use case. Thank you!
medoingthings
CC BY-SA 4.0
2018-07-23T21:18:13.733Z
2018-07-23T21:18:13.733Z
andrew.welch
<p>In addition to the <a href="https://craftcms.stackexchange.com/a/20131/57">git</a> repository type, "private" plugins can also use Composer's path repository feature to achieve this:</p>

<p><a href="https://docs.craftcms.com/v3/extend/plugin-guide.html#loading-your-plugin-into-a-craft-project" rel="nofollow noreferrer">https://docs.craftcms.com/v3/extend/plugin-guide.html#loading-your-plugin-into-a-craft-project</a></p>

<p><a href="https://getcomposer.org/doc/05-repositories.md#path" rel="nofollow noreferrer">https://getcomposer.org/doc/05-repositories.md#path</a></p>

CC BY-SA 3.0
2017-04-21T18:11:20.477Z
well, actually I want to use composer. I am not sure, how to incorporate the plugin into current codebase. Adding a repo into a composer.json should be enough, right?
PeterBocan
CC BY-SA 4.0
2018-07-23T16:53:33.057Z
@bradbell did this ever actually happen?
James Smith
CC BY-SA 4.0
2018-07-23T19:43:32.437Z
Updated my answer... had misunderstood the original question, I suppose.
Brad Bell
CC BY-SA 4.0
2017-04-21T17:34:42.980Z
2018-07-23T19:41:45.670Z
2018-07-23T19:41:45.670Z
Brad Bell
<p>I haven't done this with Craft, but with another Laravel project I was able to add a package from a private repo as follows:</p>

<p>1) In composer.json, after the <code>require</code> array, add a new <code>repositories</code> array:</p>

<pre><code>"require": [
  ...
],
"repositories": [
  {
   "type": "git",
    "url": "https://github.com/YOURGITHUBNAME/your-repo.git"
  }
]
</code></pre>

<p>2) In the "require" array, add your package:</p>

<pre><code>"require": [
  "YOURGITHUBNAME/your-repo": "*",
  ...
]
</code></pre>

<p>3) Here's the under-documented trick you need to do to get it all working: you must create a "release" in github, and the release name must be the letter "v" followed by the version number (e.g. <code>v1.0.0</code>). So go to your repo, click the "Releases" link, then click the "Draft a new release" button. It asks for a tag version and a Release title... I can't remember which of these is the critical one, so just put <code>v1.0.0</code> into both of these fields.</p>

<p>4) Now if you run <code>composer install</code> it should (hopefully) bring in your private repo package. Might need to provide some kind of authorization / API key to access it if it's a private repo (I'm not sure how exactly this works, but should be fairly easy to find documentation on).</p>

CC BY-SA 3.0
2017-04-21T22:18:12.067Z
Technically, your third point is incorrect. In Git, a tag is just an annotated pointer to a commit; in other words, it's a convenient name that you can use to refer to a specific commit hash. As such, you can refer to the hash directly: `"require": {"vendor/package": "dev-master#ed7fa4b0"}`. That said, it's preferable to use version numbers, where possible. More details here: https://getcomposer.org/doc/04-schema.md#package-links
Stephen Lewis
CC BY-SA 3.0
2017-04-21T23:01:48.373Z
"Preferable" to use version numbers is an understatement! From the docs: *Note: This feature has severe technical limitations, as the composer.json metadata will still be read from the branch name you specify before the hash. You should therefore only use this as a temporary solution during development to remediate transient issues, until you can switch to tagged releases. The Composer team does not actively support this feature and will not accept bug reports related to it.*
Jordan Lev
CC BY-SA 3.0
2017-04-21T23:33:44.950Z
Like I said, your third point is _technically_ incorrect.
Stephen Lewis
CC BY-SA 3.0
2017-04-21T20:05:25.117Z
2017-04-21T20:05:25.117Z
Jordan Lev
<p>what is the best way to install private plugin in Craft CMS 3? The private plugin is installed in private GitHub repo, but we don't have a custom packagist that we would use, therefore I wonder if there is any option to enable private plugins via composer/plugin-installer?</p>

CC BY-SA 3.0
2017-04-21T16:24:11.257Z
You can use private repositories with Composer. The documentation provides an example: https://getcomposer.org/doc/05-repositories.md#using-private-repositories
Stephen Lewis
CC BY-SA 3.0
2017-04-21T16:28:17.570Z
will it work with plugin-installer? What is the difference between installing via composer and plugin-installer?
PeterBocan
<craft3>
Private plugin distribution in Craft CMS 3
# Private plugin distribution in Craft CMS 3

(Asked by: username_0 on 2017-04-21)

what is the best way to install private plugin in Craft CMS 3? The private plugin is installed in private GitHub repo, but we don't have a custom packagist that we would use, therefore I wonder if there is any option to enable private plugins via composer/plugin-installer?

**Tags:** craft3
> **Comments:**
> **username_1**: You can use private repositories with Composer. The documentation provides an example: https://getcomposer.org/doc/05-repositories.md#using-private-repositories  
> **username_0**: will it work with plugin-installer? What is the difference between installing via composer and plugin-installer?  

---

## 3 answers

### Answer by username_6 on 2017-04-21. Score: 6 | Accepted answer

I haven't done this with Craft, but with another Laravel project I was able to add a package from a private repo as follows:
1) In composer.json, after the require array, add a new repositories array:
"require": [
  ...
],
"repositories": [
  {
   "type": "git",
    "url": "https://github.com/YOURGITHUBNAME/your-repo.git"
  }
]

2) In the "require" array, add your package:
"require": [
  "YOURGITHUBNAME/your-repo": "*",
  ...
]

3) Here's the under-documented trick you need to do to get it all working: you must create a "release" in github, and the release name must be the letter "v" followed by the version number (e.g. v1.0.0). So go to your repo, click the "Releases" link, then click the "Draft a new release" button. It asks for a tag version and a Release title... I can't remember which of these is the critical one, so just put v1.0.0 into both of these fields.
4) Now if you run composer install it should (hopefully) bring in your private repo package. Might need to provide some kind of authorization / API key to access it if it's a private repo (I'm not sure how exactly this works, but should be fairly easy to find documentation on).

> **Comments:**
> **username_1**: Technically, your third point is incorrect. In Git, a tag is just an annotated pointer to a commit; in other words, it's a convenient name that you can use to refer to a specific commit hash. As such, you can refer to the hash directly: `"require": {"vendor/package": "dev-master#ed7fa4b0"}`. That said, it's preferable to use version numbers, where possible. More details here: https://getcomposer.org/doc/04-schema.md#package-links  
> **username_6**: "Preferable" to use version numbers is an understatement! From the docs: *Note: This feature has severe technical limitations, as the composer.json metadata will still be read from the branch name you specify before the hash. You should therefore only use this as a temporary solution during development to remediate transient issues, until you can switch to tagged releases. The Composer team does not actively support this feature and will not accept bug reports related to it.*  
> **username_1**: Like I said, your third point is _technically_ incorrect.  

---

### Answer by username_2 on 2018-07-23. Score: 3

Typically, the desire for a private plugin is for a one-off client project, where the client owns the custom plugin. If that's the case here, I'd consider just changing the plugin over to be a module, and making it part of the project itself (checked into git, and all that).

e.g.: [Enhancing a Craft CMS 3 Website with a Custom Module](https://nystudio107.com/blog/enhancing-a-craft-cms-3-website-with-a-custom-module)

It's actually pretty easy to convert a plugin over to being a module. FWIW!

> **Comments:**
> **username_3**: You just nailed my use case. Thank you!  

---

### Answer by username_4 on 2017-04-21. Score: 1

In addition to the [git](https://craftcms.stackexchange.com/a/20131/57) repository type, "private" plugins can also use Composer's path repository feature to achieve this:

<https://docs.craftcms.com/v3/extend/plugin-guide.html#loading-your-plugin-into-a-craft-project>

<https://getcomposer.org/doc/05-repositories.md#path>

> **Comments:**
> **username_0**: well, actually I want to use composer. I am not sure, how to incorporate the plugin into current codebase. Adding a repo into a composer.json should be enough, right?  
> **username_5**: @bradbell did this ever actually happen?  
> **username_4**: Updated my answer... had misunderstood the original question, I suppose.  

---

