DEV Community: Matthew Jacobs

Deploying Your First App with Dokku: A Step-By-Step Guide

Matthew Jacobs — Tue, 30 Apr 2024 12:00:23 +0000

TL;DR Use this gist as a reference for all of the steps found in this article: dokku-setup.sh

Dokku is a command-line application that makes deploying web applications and databases on your server (or VPS) simple. It describes itself as

An open source PAAS alternative to Heroku.

It doesn't have an official UI, which makes it a little less inviting to newcomers, but I believe it has actually helped me become more comfortable with the command line. And once you set up one application, it gets easier and easier.

I recently tried to install and use Coolify, and if you need a UI to understand everything, I get it. I was hopeful that I would like it, but I felt lost when I attempted to use it, and it requires root access to control Docker, which I did not feel comfortable with.

There are some unofficial UIs for Dokku, but I haven't tried them out, and they don't seem current.

I have been a proponent of self-hosting for a long time. I had an OwnCloud instance and Plex setup back in 2018. But after a few failed hard drives (and the realization that I only ever watch movies once), I decided to spin everything down and use commercial software that is cheap (free) and has built-in redundancies that I don't have to worry about.

But in 2021, my friend got me interested in Chia, and now I have a server sitting in my office "farming," which doesn't take a lot of CPU or memory, so I decided to start hosting my custom-built budget app so I wouldn't have to pay for hosting.

Fast forward to today, and I have about six applications running on this server that I use often. Some of them I built for my own use, and some are open-source projects.

Server Setup

This article assumes you already have a server or VPS setup, but I wanted to explain how I set up my server.

Physical

These specs seem to be more than enough to host quite a bit of applications without concern:

256 GB SSD
16 GB RAM
3.6GHz 6-Core CPU

Software

Ubuntu Server
UFW (Firewall)
Dokku Version 0.34.4 (Installation Instructions)

Topology

In this diagram, you can see how I have my server set up behind Cloudflare using their DNS tool to avoid exposing my IP address and help cache assets to limit the need to make direct calls to my server.

NGINX is running as my reverse proxy, directing a domain name to a specific container. Docker runs the applications and databases as isolated containers. These applications are independent of Dokku but are effectively controlled by Dokku, so we don't need to do anything with them directly.

Deploying an Application

For this article, we'll deploy an application that has been pretty useful to me since I recently installed it: Linkwarden. Linkwarden is a web-based bookmarks manager that allows you to collaborate, organize, and archive content from links in one place.

The basics of this installation will be to create an application pointing to a git repository with a Dockerfile that will build the container that runs the application.

While this article assumes you have installed Dokku using the instructions on their website, there are a few configuration steps that we want to run before continuing. You shouldn't need to execute these commands again if you have already run them.

dokku plugin:install postgres
dokku letsencrypt:set --global email <your-email@email.com>
dokku letsencrypt:cron-job --add

The first command will install the Postgres plugin so we can use it to set up a Postgres instance that will be independent of the actual application. The other commands set up LetsEncrypt so we can fetch an SSL certificate once, and it will automatically renew itself.

The first thing we'll do is create the application Docker container and the database container and link them together:

dokku apps:create linkwarden
dokku postgres:create linkwarden-db
dokku postgres:link linkwarden-db linkwarden

The dokku postgres:link line adds an environment variable, DATABASE_URL to the linkwarden application container.

This next step is something specific to Linkwarden, but it is helpful to know for any application that may be storing files is to point the data directory of the Docker container to a directory on the local machine:

sudo mkdir -p /opt/linkwarden/data
dokku storage:mount linkwarden /opt/linkwarden/data:/data/data

If you ever need to rebuild the application from scratch, you won't lose the files that Linkwarden has saved. In this case, it's archived downloads of the link content.

Now, let's point the application container to the git repository, set the necessary environment variable, and then build it:

dokku git:sync linkwarden git@github.com:linkwarden/linkwarden.git main
dokku config:set linkwarden NEXTAUTH_SECRET=`openssl rand -hex 32`
dokku ps:rebuild linkwarden
dokku ports:add linkwarden http:80:5000

The NEXTAUTH_SECRET='openssl rand -hex 32' sets NEXTAUTH_SECRET to a randomly generated string and avoids exposing secrets in the command line.

Once you run dokku ps:rebuild Dokku will pull down the necessary images based on the Dockerfile in the git repository and attempt to build and start up the application.

That last line sets up nginx, which is the reverse proxy that Dokku uses to point port 80 from your machine to port 5000 of the application container.

If you don't know what port the application container is exposing, you can run dokku ports:report to see the detected ports being exposed and copy that config to the dokku ports:add command.

The last thing we need to do is set up a domain to be able to access the application. Dokku does have a global domain based on the machine name by default, and then each app would automatically be set to <app-name>.global-domain.tld but I deactivated that (dokku domains:clear-global) to be able to add specific domains or subdomains manually.

This next part is a little complicated and probably causes me the most headaches because you need to make sure port 80 is accessible from the internet to be able to get an SSL certificate:

Disable enforced SSL in Cloudflare
Open up Port 80 in your NAT/Router
Enable Port 80 via UFW (sudo ufw allow 80)

dokku domains:add linkwarden linkwarden.your-domain.com
dokku letsencrypt:enabled linkwarden

If you run into issues, I would be careful not to attempt to run the letsencrypt command too much because there is a rate limit of 5 times per hour per email and domain combination.

Success will look something like the image below:

If your DNS is not set up correctly, you may see something like this:

2024/04/28 18:17:22 Could not obtain certificates:
    error: one or more domains had a problem:
[linkwarden-test.codingmatty.com] acme: error: 400 :: urn:ietf:params:acme:error:dns :: DNS problem: NXDOMAIN looking up A for linkwarden-test.codingmatty.com - check that a DNS record exists for this domain; DNS problem: NXDOMAIN looking up AAAA for linkwarden-test.codingmatty.com - check that a DNS record exists for this domain

If your port 80 isn't open, you may see an error message like this:

2024/04/28 18:18:48 Could not obtain certificates:
    error: one or more domains had a problem:
[linkwarden-test.codingmatty.com] acme: error: 403 :: urn:ietf:params:acme:error:unauthorized :: 2606:4700:3032::6815:4638: Invalid response from http://linkwarden-test.codingmatty.com/.well-known/acme-challenge/n9q8vjktpRkDGq5bKU2cvRLAGqkJy-3Lc2taCCyaxvw: 522

Once you have successfully received your SSL certificate, Dokku will automatically add port 443 to point to the same port of the Docker container that port 80 was pointing to with HTTPS enabled. You can validate this by running dokku ports:report and seeing https:443:5000.

I strongly recommend removing access to port 80 by reversing all of the previous steps to expose it:

Enforce SSL in Cloudflare
Close Port 80 in your NAT/Router
Disable Port 80 via UFW (sudo ufw deny 80)
dokku ports:remove http:80:5000 to remove the port being directed to the Docker container

That's it! You now have a running instance of Linkwarden 🎉

In this case, you should sign up, and then, if you want to prevent anyone else from signing up, go ahead and add the proper environment variable:

dokku config:set linkwarden NEXT_PUBLIC_DISABLE_REGISTRATION=true

This command will rebuild the application container and prevent any future sign-ups. Similar options are pretty typical with many self-hostable applications with login screens.

I hope this post helps you get up and running with Dokku. I would love to hear about what you've deployed on your server 😄

Let me know if you have any questions.

Find me on Threads or email me at codingmatty@gmail.com

Type Strict Environment Variables

Matthew Jacobs — Sat, 22 Oct 2022 15:11:09 +0000

I love Typescript.

And Environment variables are one of the essential parts of storing run-time configuration securely.

But one of the most significant issues with using environment variables within a Typescript application is the lack of types.

Let's say you are trying to use the PORT environment variable, but you end up getting an error like this:

Because the default type for every environment variable is string | undefined, you end up having to validate them in creative ways. Here is one solution to the above problem:

const port: number = process.env.PORT ? parseInt(process.env.PORT) : 4000;

startServer(port);

But how pretty does that look? 🤮

And this is just an example of one environment variable that needs to be validated. What about multiple variables? What about enumerations (i.e. development, production)? Using environment variables on their own is kind of a bane. So let's look at a better way.

I almost decided to build another library myself to provide a solution to this issue, but I decided to check out what's out there first.

Luckily, there are quite a few projects that have sought to solve this problem 😄

Solution

First, what would be an ideal solution?

Declarative-like. I initially thought a single yaml file to describe the environment would work, but I learned that it's not that easy to convert a yaml file to Typescript types without an extra step.
Useful errors. What environment variable(s) are not set up correctly and why? Is a variable not a number? Not the correct enumeration? Whatever the solution is should describe the problem well.
Ability to derive other configurations from environment variables. This one is more of a nice-to-have feature. I like to have booleans like isEmailEnabled to enable/disable emails from being sent when the API Key isn't provided instead of checking for the existence of the API Key directly.

I ended up deciding to use env-var.

env-var usage stats on NPM as of 10/22/22

It uses a fully type-safe builder pattern API which allows you to set the conditions by chaining functions together, making it relatively readable.

As a small example, this is how we can define the port variable in the example above:

const port: number = env.get('PORT').default(4000).asPortNumber();

startServer(port);

This looks much nicer, albeit more verbose, but way more readable. The asPortNumber() is the function that triggers validation, but it also has the bonus of making sure the port number is valid, i.e. is it between 0 and 65535?

To encapsulate all environment variables into a single place and avoid piecemealed validations throughout the codebase, I created a config.ts file at the root of my source directory.

Below is a code snippet of my config file with most of my environment variables.

// config.ts
import env from 'env-var';

export const port = env.get('PORT').default(4000).asPortNumber();
export const environment = env
  .get('NODE_ENV')
  .default('development')
  .asEnum(['production', 'staging', 'test', 'development']);
export const isDeployed =
  environment === 'staging' || environment === 'production';

export const secret = env.get('SECRET').required().asString();
export const sentryDsn = env.get('SENTRY_DSN').asUrlString();

export const sendgridApiKey = env.get('SENDGRID_API_KEY').asString();
export const sendgridFromEmail = env
  .get('SENDGRID_FROM_EMAIL')
  .required(!!sendgridApiKey)
  .asString();
export const isEmailEnabled = sendgridApiKey && sendgridFromEmail;

export const redisHost = env.get('REDIS_HOST').asString();
export const redisPort = env.get('REDIS_PORT').asPortNumber();
export const redisConfig =
  redisHost && redisPort
    ? {
        host: redisHost,
        port: redisPort,
      }
    : undefined;

Usage would look like this:

import * as config from './config'
const port: number = config.port;

// OR

import { environment } from './config'

Now, I have limited the need to check for any environment variable to be undefined, and my types are strict. I am even able to derive some extra variables to make my code more readable, like how isDeployed is being derived from the value of environment.

Here is a quick explanation of some of the variables:

port: number - defaulted to 4000.
environment: EnvrionmentEnum - defaulted to development .
isDeployed: boolean - derives from the environment variable.
secret: string - will throw an error if not defined.
sentryDsn: string - will throw an error if it's not in URL format.
sendgridApiKey: string | undefined - optional API key for Sendgrid.
sendgridFromEmail: string | undefined - will throw an error if it's not defined but the SendGrid API Key is defined.
isEmailEnabled: boolean - derives from whether other Sendgrid variables are defined.
redisConfig - an IORedis configuration object based on environment variables REDIS_HOST and REDIS_PORT.

You can even do a quick check of a dotenv file (or check your system's configuration) via a command like:

# .env
PORT="xyz"

---

$ npx dotenv - .env -- ts-node config.ts

.../node_modules/env-var/lib/variable.js:47
    throw new EnvVarError(errMsg)
          ^
EnvVarError: env-var: "PORT" should be a valid integer

$ NODE_ENV="test" npx ts-node src/config.ts

.../node_modules/env-var/lib/variable.js:47
    throw new EnvVarError(errMsg)
          ^
EnvVarError: env-var: "NODE_ENV" should be one of [production, staging, test, development]

This will help you confirm whether your .env file is set up correctly or tell you exactly what errors you have.

Alternatives

Disclaimer: I haven't tested any of these out, but I figured I wanted to mention them for completion.

tconf This library seemed like what I wanted to use, but it requires a lot of different components, including a type file, a yaml configuration file, and a file to glue all of those together. It might be good for larger projects with many variables, but it seemed overkill for my use case.
unified-env This library seems robust, allowing you to tie in variables from the environment as CLI arguments and from a .env file. It provides one file to parse all of the variables with validation options.
@velsa/ts-env`This library is similar toenv-var`, it just uses one function to parse an environment variable with options for validating the value. But it hasn't been updated in a while and doesn't look very widely used.
ts-app-env This library looks exactly like @velsa/ts-env, but maybe a little more up-to-date. The documentation is a little lacking, though.
ts-dotenv This library wraps the dotenv library with the ability to type information with a singular schema object. It seems excellent, but if you don't use .env files in production, it may add an unnecessary step.

I hope this post helps you find sanity in using environment variables in your Typescript application.

Let me know if you have any questions.

You can find me on Twitter or email me at codingmatty@gmail.com.

Imperfect Code

Matthew Jacobs — Mon, 11 Mar 2019 19:47:04 +0000

I have a confession to make - I have a hard time providing code reviews. I tend to nit pick. A lot.

I notice that everyone seems to have a different way of writing code. And sometimes it can be really interesting to see new techniques. But often it can just add a mess to a codebase. Over time, when different developers come in, mark the codebase with their particular style, and leave that codebase for whatever reason, you start to feel like a geologist digging through the layers of the earths' crust.

I mostly review code for Javascript codebases. It’s a great language, and I love it. But it can allow for some fascinating syntax and still work as expected. And when you add JSX all hell breaks loose.

I have a tendency to want perfection. But code isn’t meant to be perfect. Code is a medium by which to describe what a computer should do. You can have the best code in the world, and no one will use it because maybe it doesn’t do anything useful.

Code seems to have an ever decreasing half-life. By which I mean that as soon as you write some code, it starts to decay. It’s usefulness as code becomes less and less, even though it’s functionality may keep living on. Because code is meant to be read by humans , not machines. Machines could care less what your variable names are, or whether you are using a typed language or not. They will do exactly what you tell them to. Nothing more, and nothing less.

If you have worked on any system that you may consider as “legacy” you may know exactly what I mean. The larger a codebase gets, the less likely that someone will go in and clean it up. When someone has to add or fix a feature, they will likely go in and surgically update as little code as possible.

I have a colleague who recently told me that he is less and less inclined to write new code lately. This is because he has started to realize that the more code you write, the more bugs you produce. He is starting to see code, effectively, as a liability instead of a an asset.

I remember when I first started to transition into web development. I started learning Angular on my own. I learned all of the right ways to write Angular, and internalized the best practices. I even started a pretty ambitious side project to get used to working with the technologies that I wanted to and get my foot into the door at the right company. When I got hired at a company using Angular, I was so excited!

I came in with no real experience in web development. I came in with high expectations of my Angular knowledge. That was until I looked at the codebase. I was so lost 🙈. Part of it was my inexperience, but the other part was how they architected their codebase. It was not using the best practices that I had come to appreciate. When I learned Angular I thought that nothing should go on $rootScope — you might as well place things on the global scope 😱. This was apparently not a shared sentiment. And that was just a small piece of the gigantic puzzle.

This is when I truly learned that code is not written in a vacuum. Everyone brings different experiences and motivations to the way they write and architect codebases. In fact, this is something I am still learning today.

Let's get back to my code review struggle. How have I learned to deal with my own issues and provide valuable feedback without nit-picking everything?

I realize that the code isn’t as important as the function or feature that we are trying to provide.

When I start to review code I first ask does it do what we expect it to do, and are there tests to verify this? Are there any possible side effects? If the code does what it’s supposed to do, and there are no foreseeable side effects, then I will let go of any stylistic details or logical order. Most of the time it doesn’t matter if we “bail out early” unless we would be doing a lot of computation work otherwise. I may add some comments about readability sometimes, but I will give it a checkmark and move on.
Try to preempt the problem.

I was once told that the person who cares most will write the rules. In my case, I created a coding style guide with some initial guidelines based on code reviews I had done previously. I then elicited some feedback and asked other developers to add their own stylistic preferences if they had any. The key is to have everyone agree on the guidelines to get buy-in. This is a living documentation that can evolve as we decide better practices. But the best purpose of it is to have something to point to to say what we decided as a team how to write code for a particular codebase. It’s also a great resource to onboard new developers to the team.
Sometimes I still just nit pick things.

I don’t see nit-picking things as a blocker any more. I see it as a way to bestow my opinion where it may be served well — think constructive criticism. Sometimes it can be a learning experience for other developers, but I’ll admit sometimes it may be a hinderance. I have learned not to do it to developers who have expressed that they only want actionable feedback. And If I really cared that much, I would come in behind the developer and clean it up. But I don’t have time to do that, and nobody should — it undermines that developer and breaks down trust.

So what about you? Do you have a problem with perfectionism? As a nit-picker or nit-pickee? Let me know how you deal with it? I’m also open to pointers on how I can do better.

Gemfury for Javascript Packages

Matthew Jacobs — Mon, 25 Feb 2019 00:00:00 +0000

Notice: NPM is the name for 2 disparate tools: a registry that holds javascript packages (npmjs.com), and the CLI to manage javascript packages locally. I talk about both and to distinguish them I use all caps "NPM" for the registry, and all lowercase "npm" for the CLI.

I started a project at work a while back. Specifically, a javascript package for our frontend. It's something that would need to be shared by various projects (I plan to explain the project in a future post). While I could have started the project without worrying about how it would be consumed, I wanted to start thinking about it up front. One of the main known requirements was that it was going to be a private package, at least for now.

The first option was to depend on Github. It’s something that an npm package allows, and wouldn’t be terribly difficult to work with. In fact, it’s something that has authentication built in when a developer has to have access to clone a repo anyways. But we wanted to find a more robust solution. Something specific to holding packages, separate from the tool used to maintain the code.

The obvious answer was NPM. It’s something every javascript developer is familiar with. And it’s easy to use. But, the cost to value ratio is pretty steep. This may not be the case for every team, especially for open source projects. But we decided against it for us for now.

To be honest, I didn’t even know there were alternatives to NPM. When I brought up the question to my team of possible hosting solutions, I learned of at least a handful of options. Some of which were self-hostable, but others which were just general alternatives to NPM.

Then our Infrastructure manager mentioned that we had a Gemfury account. It had a single unused gem in it. We were a ruby shop, so that made sense, but how would that help me for a javascript package? I wasn’t about to wrap my javascript package into a gem just to distribute it. But I took this under advisement.

After some research, I found that Gemfury actually supports a plethora of languages and registry options. While they sound like they would only be useful for ruby gems, they actually work with python's PIP, php's Composer, and even Debian repositories. It’s like a buffet where you can eat some fried rice, gyros, and Texas barbecue all under one roof.

Okay, so they have learned how to scale horizontally in the code registry business, but I care about hosting a private javascript package. How do they compare to NPM?

Gemfury Features

Here are the top features that sold us on Gemfury:

Tokens - Gemfury has this concept of “deploy” (i.e. pull) and ”push” tokens. These are one-way, revokable tokens that you can use to allow people or systems to do a single direction action. For instance, if you only want to allow people to install a package, you can provide them with a “deploy” token. Inversely, if you want to setup continuous deployment to publish changes to Gemfury, you can use a “push” token. These are incredibly powerful for intentionality and security.

There are different ways to use these tokens, but the docs suggest the tokens go into the url. I will show you below how we avoided that in the case of using npm that seems to be acceptable.

Granular User Permissions - With an organization set up, you can add collaborators (we will see how to do that below). These collaborators can have 3 tiers of access to an organization:

Download Only
Upload & Download
Owner (full access) - this one allows someone to add collaborators and manage tokens for an organization.

By adding collaborators you can provide people with access via their own credentials. This prevents you from having to provide a single access token, or manage multiple tokens for multiple users. By doing this, you can add and remove collaborators without affecting any other person or system.

NPM Proxy - This is NPM specific, and I can’t speak for other registry options. You can set up npm to only hit your Gemfury registry to install packages, which may be fine for a very narrow use case. But most projects will need to be able to install from Gemfury first and then move on to NPM if the package can’t be found. Gemfury provides a way to do this (Installing private npm modules).

This actually allows you to name uploaded packages with the same name as one in NPM, but will effectively shadow that package. This can be useful if you want to avoid updating dependencies in many projects, but you have a fork of a public package on NPM that you would prefer to use.

You can also namespace your javascript packages and set up only that namespace to search Gemfury. This is what we have done and what I will demonstrate below. But either way, Gemfury can accommodate.

Mutability - For anyone who has been in web development for a while, you may have been affected by, or at least heard of, the Left-Pad Fiasco. The result of that caused NPM to declare all packages to be immutable. No matter who you are or what you want to do, if you publish something to NPM, it will remain there forever. You cannot delete it, and you cannot overwrite it. (You actually have 72 hours to delete it, and can contact support after that)

This means when you make a mistake, even if no one is being affected by it yet, you have to release a new version. The remnants of that code will remain forever. But, what if you could just rebuild and override the existing version? Or maybe you want to yank it altogether. This may not be the correct course of action, but for better or for worse Gemfury allows it. And I appreciate that. Yield this power wisely.

I will offer some drawbacks here as well, but there aren’t many that seem to affect us:

Token Descriptions - While you can create all the tokens you want, currently Gemfury does not allow you to add descriptions to them. This makes it very difficult to figure out which one is being used where. I’d suggest keeping a secure file to provide descriptions for keys, but hopefully they will add this ability soon. Token Descriptions have been added as of Feb 22, 2019.

Version Tagging - NPM allows you to tag versions as latest, or beta, whereas Gemfury currently does not. They do however support full semver, which allows for suffixes like -beta.0, which provides a well enough work around.

There are some other odd intricacies around authentication methods between using npm and installing gems, but I want to focus on just javascript packages in this post.

Setup

Now we can get into the nitty gritty.

Here are some of the conditions that guided our setup process:

We have projects that use both npm and yarn CLI tools
We want it to be easy to revoke access to one user - if they leave or lose their laptop, we don't want to have to inconvenience everyone.
We want to be able to securely install on CI machines, and similar to users, be able to easily revoke those credentials.

Now here are the steps:

These steps assume you want to create an organization account. Read more about organization accounts here: Gemfury Organization Accounts Documentation. You may not need one for a small group. In that case you should be able to just skip step 1, and the remaining steps will be the same with a single user account, including adding collaborators.

Create an organization (Create Organization Link)
Have users create their own Gemfury account (Signup Link).
- They can login via Github, but Gemfury will prompt them to create a new password, which they will need for logging in locally.
Add users to the created organization.

These next steps are for local setup:

We use namespacing to make it esaier to configure, but it's not required. It's as easy as appending @organization/ to the package name in the package.json file

Add reference to the Gemfury registry in each consuming project's .npmrc file.
- yarn will automatically pick up the project's .npmrc configuration, but there is a way to only allow yarn to use the configuration via a .yarnrc file.

# ${PROJECT_ROOT}/.npmrc
# Make sure to provide the trailing slash '/'
@namespace:registry=https://npm-proxy.fury.io/organization/

npm login --registry https://npm-proxy.fury.io/organzation/

This will add or edit the users global .npmrc file located in their home directory with this line:

# ~/.npmrc
//npm-proxy.fury.io/organization/:_authToken=${SECRET_TOKEN}

Install the dependency via the command line.

npm install --save @namespace/package
# OR
yarn add @namespace/package

With the proper setup, this install step should look in the Gemfury registry first, and then check in NPM if the dependency isn't found.

Now, once a developer is added as a collaborator (step 3) and logs in to Gemfury via the npm CLI (step 5) they will be able to install the dependency with no problem.

Note: We did have some issues wtih yarn versions 1.6 and 1.7, I strongly recommend using the latest versions to avoid any issues.

Continuous Integration (CI) Setup:

As mentioned above, tokens are a great way to offer secure one-way actions. The best use case for these tokens are on your CI system, kept in environment variables. This makes them easy to swap out without affecting any one else, or any other system.

We have 2 different systems that provide different functionality, and thus different setups. Here is how we configured each of them.

For our CI system that handles the package deployment we needed something to build our package and publish it to Gemfury.

Create a push token.

Add the generated token to CI environment variables. This step wholly depends on your CI. (For reference, I have named mine FURY_PUSH_TOKEN)
Upload package to Gemfury. There are a few ways to upload packages to Gemfury. Check out Gemfury Upload docs for more information.

We chose to generate the assets with npm pack and then use curl to push them up to Gemfury.

npm pack
curl -F package=@"$(echo namespace-package-*.tgz)" https://${FURY_PUSH_TOKEN}@push.fury.io/organization/

Note: $(echo namespace-package-*.tgz) just allows us to avoid needing to know the version of the filename, but it does assume there is only 1 tgz file.

For our CI system that handles the consuming application(s) we just need to authenticate before trying to install.

Create a deploy token

Add the generated token to CI environment variables. This step wholly depends on your CI. (For reference, I have named mine FURY_PULL_TOKEN)
In your CI scripts authenticate with npm manually before installing dependencies.

echo "//npm-proxy.fury.io/organization/:_authToken=${FURY_PULL_TOKEN}" > ~/.npmrc
npm install

And that should do it! Feel free to contact me with any questions about our setup. I'd love to help any way I can 🙂

I hope this helped you to get setup with Gemfury. It really is a great service, with an intuitive interface, at a reasonable rate for everyone to get started with.

And while it may not seem intuitive to place javascript packages on a platform originally designed for ruby gems, it really is helpful. It becomes incredibly more powerful when you are with a company that operates in many different languages. Gemfury offers an incredible platform to hold packages of all kinds.

Let me know your experience.