Frequently Asked Questions

Frequently Asked Questions and Known Issues

Frequently Asked Questions

Do you support private Docker Hub images?

Yes, we support pulling images from a private repository in Docker Hub. We have an Integration so that you can link your Release account with your private registry and pull images during the build process.

Do you support running workloads in my own AWS account or EKS cluster?

Yes, we have a fully-managed privately-hosted product. Customers who upgrade to this level will be able to run an AWS integration in the account of their choice. We will build and manage an EKS cluster in the account and region that you grant permissions for us to do so. Deploying your workloads will then run in your own account on your own servers in a separate VPC. You do not have to (and we ask you not to) do anything to maintain or troubleshoot or manage this EKS cluster.

Do you support running in multiple AWS accounts?

Yes, some customers who wish to separate out their Release workloads from other private or test workloads can create clusters across boundaries like pre-production and production accounts for complete isolation. Please let us know before you do this or if you plan to do this as we want to make sure the processes and workflows you use with Release makes sense and work seamlessly.

Do you support running in multiple AWS regions?

Yes, customers who upgrade to the fully-managed, privately-hosted can elect to build multiple clusters in the same or in different regions, in the same or in different accounts. Please let us know before you do this or if you plan to do this as we want to make sure the processes and workflows you use with Release makes sense and work seamlessly.

Do you support private AWS ECR image repositories?

ECR support is available for customers who upgrade to self-hosted clusters! You get a fully managed, completely-owned and private experience with the self-hosted product.

Do you support access to RDS instances?

Yes, customers who upgrade to the fully-managed, privately hosted product have access to our Instant Datasets product which allows customers to have seeded or production-like databases for each environment. If you wish to use live access to an existing RDS instance we can perform integrations with other AWS services as described below.

Do you support accessing private VPCs, other AWS services, and so forth in my AWS account?

Customers who upgrade to the fully-managed, privately-hosted product can have access to other assets and services and networks (like VPCs, security groups, RDS instances, Kinesis etc.) in their accounts with some caveats and exceptions. To be safe and sane, we keep our EKS managed cluster and software running in a separate VPC. We do support peering, using Transit Gateway, RDS proxy, and Private Link integrations but these integrations are not stock or off the shelf and require some setup, configuration, documentation, and so forth that could be very unique to each scenario.

Thus, although we can support such integrations, you need to work with us on a close basis to plan and implement it so that it will work properly for your scenario. Most customers in this scenario would probably sign a working relationship contract and support contract to cover these integrations fully.

Do you support private NPM libraries during build?

Yes, but it might require some additional work on your part. Please read this excellent article for all the technical details which will be described briefly below.

  1. Add a .nprmrc file to your code repository with the contents that look something like //${NPM_TOKEN} Do not actually fill in your token here! Use the variable which will be substituted later (this file is safe to check in to your code version system).

  2. Add a Build Argument to your Dockerfile, preferably somewhere near the top (add a comment so you can remember why you put it there too!) The line looks like ARG NPM_TOKEN

  3. Add a copy command so the file is copied into your docker container right below the argument, but above the npm install command that you use. The line looks like COPY .npmrc .npmrc

  4. Push your changes to Github or Bitbucket on a branch.

  5. Make sure you generate (or use an existing) token that is READ-ONLY and can be revoked safely without affecting your other pipelines as best practice. Anyone who is an owner of your account can see and change these build arguments.

  6. Now add a Build Argument in the account settings in the builds tab and add your token to the build arguments. This looks like the next screen:

Once you've done these steps, your build should use the NPM token you supplied to pull private libraries. If it works, merge your changes to the default or main development branch for use with your Release process.

NPM install works as you described, what about YARN?

The instructions seem to be the same for NPM as described above, but have one extra step to add an additional .yarnrc file for the private repository. Please see this discussion for more details. Please let us know if this works or the documentation can be improved!