Self hosted hex repo

Maybe reading through GitHub - hexpm/hexpm: API server and website for Hex · GitHub or GitHub - hexpm/hex: Package manager for the Erlang ecosystem. · GitHub might help.

There is good documentation at https://hex.pm itself. You can host your own internal installation of hexpm (it’s a Phoenix app, yay! ) and then you can use the :repo option in the relevant depencies in the mix.exs file as noted in the docs here.

Another option: use git (if you use git )

You can specify git url and ref/tag (see git options), or use submodule with path option.

There is also Private packages in Hex (currently in beta), which has different pros & cons.

From my experience on using private repo for ruby gem… git way is much simpler since you can use git+ssh authentication like the main repo. There are some benefits of having private package repo for backup and audit purpose, but that usually applies only when you fetch all packages from the repo.

There is already a request to support hex on Artifactory - RTFACT-14011: Support for Erlang “hex” repos.

Git works if you have one or two packages but at the moment you have multiple packages and they depend each other, Hex private is probably the best option since we can’t perform dependency resolution on top of Git.

As far as I remember, just for comparison, Ruby bundler uses git to fetch packages and then checks gemspec for version and its dependency - so I can keep two private packages in git, depending each other with version constraints.

How does mix handle this? It seems to do the same thing.

The obvious disadvantages of using git is that you now need to resolve version constraints since you do not use hex.

I don’t know if this existed at the time this thread was originally posted, but looks like setting up an organization on http://hex.pm is going to be the cleanest way to do this. You could deploy your own self-hosted version of the hex.pm app but it seems that this is ultimately going to be the easiest way to get going out of the box that still permits full resolution dependency, and without having to personally maintain an external/private hex.pm service.

Remember that with git you can access individual private repositories from a github account, but as @josevalim mentioned mix will not perform dependency resolution on those apps and you may end up with conflicts, and possibly having to maintain the dependencies for your private elixir libraries in the top-level app in which they’re being used. This might work for a very simple application but breaks and is clumsy to maintain at scale.

If you don’t want to use hex.pm organizations for whatever reason I’m sure you could also configure this on your own server, though the setup overhead will be more involved. I get the sense too that hex.pm organizations will become an increasingly common workflow in Elixir projects, and will be easier to onboard other developers already familiar with that relatively straightforward process.

Apparently I’m still locked on this topic - @wojtekmach introduced MiniRepo roughly three months ago which looks like a good way to get a quick, private hex server up and running if cloning and deploying all of hex.pm proves to be overkill.

That said, I’ve found @ericmj and the hex.pm team to be extremely helpful and supportive. Seems like any of the above options will work well. Really just depends on personal preferences.

One more note here - I recently spent a couple of hours digging through the hex.pm application source code and deploying the application locally. While it’s pretty easy to get it going in development, the prod environment has a few runtime dependencies for services like a Fastly-backed CDN, Rollbar error handling, AWS credentials for S3 access, and mailer credentials, which may be overkill for a small internal deployment.

Here is the full scope of the environment variables required by a production release:

import Config

config :hexpm,
  secret: System.fetch_env!("HEXPM_SECRET"),
  private_key: System.fetch_env!("HEXPM_SIGNING_KEY"),
  s3_bucket: System.fetch_env!("HEXPM_S3_BUCKET"),
  docs_bucket: System.fetch_env!("HEXPM_DOCS_BUCKET"),
  logs_buckets: System.fetch_env!("HEXPM_LOGS_BUCKETS"),
  docs_url: System.fetch_env!("HEXPM_DOCS_URL"),
  cdn_url: System.fetch_env!("HEXPM_CDN_URL"),
  email_host: System.fetch_env!("HEXPM_EMAIL_HOST"),
  ses_rate: System.fetch_env!("HEXPM_SES_RATE"),
  fastly_key: System.fetch_env!("HEXPM_FASTLY_KEY"),
  fastly_hexrepo: System.fetch_env!("HEXPM_FASTLY_HEXREPO"),
  billing_key: System.fetch_env!("HEXPM_BILLING_KEY"),
  billing_url: System.fetch_env!("HEXPM_BILLING_URL"),
  levenshtein_threshold: System.fetch_env!("HEXPM_LEVENSHTEIN_THRESHOLD")

config :ex_aws,
  access_key_id: System.fetch_env!("HEXPM_AWS_ACCESS_KEY_ID"),
  secret_access_key: System.fetch_env!("HEXPM_AWS_ACCESS_KEY_SECRET")

config :rollbax,
  access_token: System.fetch_env!("HEXPM_ROLLBAR_ACCESS_TOKEN")

config :kernel,
  inet_dist_listen_min: String.to_integer(System.fetch_env!("BEAM_PORT")),
  inet_dist_listen_max: String.to_integer(System.fetch_env!("BEAM_PORT"))

Hex.pm releases are also configured for Docker by default, backed by Kubernetes, which may additionally prove overkill for a smaller setup with a handful of users. That said, bootstrapping an edeliver config is not difficult for this setup and was easy to get going.

Hello! For reasons that are not good, but beyond my control, I find myself trying to roll a self-hosted hexpm server. I’m currently working on adding azure blobs as a storage client. In my tests I am able to push a package to my local instance and pull it back down, but I have to set the environment variable HEX_NO_VERIFY_REPO_ORIGIN=1 . When I do not set this I get the error

13:44:54.008 [error] GenServer Hex.Registry.Server terminating
** (Mix.Error) Fetched deprecated registry record version from repo local. For security reasons this registry version is no longer supported. The repository you are using should update to fix the security reason. Set HEX_NO_VERIFY_REPO_ORIGIN=1 to disable this check.

Does anyone know how to “update to fix the security reason”? I wasn’t able to find any documentation about it except for this entry in the hex documentation, but that didn’t give me a direction on how to fix it… The only thing I’ve really changed is the storage layer. Otherwise I’m running the dev server, so maybe it’s because some of this config from runtime.exs is going unset?

    secret_key_base: System.fetch_env!("HEXPM_SECRET_KEY_BASE"),
    live_view_signing_salt: System.fetch_env!("HEXPM_LIVE_VIEW_SIGNING_SALT"),
    secret: System.fetch_env!("HEXPM_SECRET"),
    private_key: System.fetch_env!("HEXPM_SIGNING_KEY"),

Apologies for the possible naive question (and reviving a dormant thread). I’m not very security-literate so it’s been difficult to try and puzzle my way through this.