Lots of NPMO customers have a set of tools they use to install and publish npm packages internally. Configuring one is usually trivial, but when there are multiple to chain together, things get hairy.

• GitHub Enterprise
• Travis Enterprise
• Cloud platforms (e.g. Bluemix, AWS, Azure, etc.)
• Greenkeeper
• Coveralls

from https://github.com/npm/docs/issues/743 by @kzahel

How can I update an existing NPM enterprise install's SSL certificate. Say for example I have an already running NPME enterprise running with a self signed certificate, and now I have a real certificate. I don't see anywhere in the dashboard where I can update the certificate. Is there a filepath where I can manually update it on the filesystem, or a secret URL I can go to?

we should document:

npme update-license

We should start by documenting the /_monitor/status endpoint, which folks can use to check the status of the main npme container.

CC: @nexdrew

In terms of npmo, there is quite a bit of confusion in terms of what is "private" and when scope is needed.

Questions I get

• Does scoping make modules private automatically?
• Does publishing to an npmo registry require scoping?
• Does publishing to an npmo registry make modules private to both the public registry and the npmo registry?

I have an HA set right now. I want to replace those instances with a new set.
I understand how to make more replicas of the existing primary from the documentation.
I would like to make one new replica, let it sync, then disconnect it and make it the new primary.
Then I would want to make one more replica.

How do I go about doing this?
Specific steps helpful.
Adding it to your documentation also helpful.

Thanks,

We should rebrand this to npm Enterprise before we officially launch, a hassle I know.

Should at least mention the requirements to keep the CouchDB and Package data directories (crucial package data) and admin console settings at /var/lib/replicated and /etc/{default,sysconfig}/replicated*.

More in-depth instructions about adding a bigger disk would be a good idea.

Customers on closed networks sometimes run into issues where a dependency references a git url rather than a package name, which they are unable to access.

One option would be that folks re-publish this dependency to their private registry -- it would be worth both:

1. explaining why this happens (git dependencies are valid in npm).
2. explaining how to work around this by republishing a package.

We have customers who would like to use npm Enterprise in conjunction with Nexus for Java; if this is possible, it would be nice to document.

We need to update our up-and-running doc to state 16 GB so we don't confuse users anymore.

TODO

• Add a "these docs are deprecated" notice to public-facing Enterprise docs index page
• Link to (as-yet nonexistent) new Enterprise admin docs on public-facing docs index page
• Make this repo private
• Archive this repo

Blocked on

• Publicly shipping new Enterprise docs